[Closed] Fastest cycles/byte memory write rate : answer 2µs per byte with PUSH.

[cpcitor]

Hello,

Programming:Filling memory with a byte - CPCWiki documents the long-known fact that PUSH instruction writes more byte-per-cycle than e.g. LDIR.

I remember (from 20 years ago) that plain Z80 doc read "PUSH takes 10 cycles, POP takes 11" (because I found strange that they took different time, and why POP slower that PUSH). At the same era, I read that LDIR took 21 cycles per byte.

Actual CPC timings seem indeed rounded at next multiple of 4 cycles if we believe in documentations:devices:z80 [Grimware].

There I read that LDIR speed is 6 nops per byte.

Question 1 : What is the actual speed PUSH-based memory fill ? (partial answer given)

Example code is given in section Using the stack .


push hl -> 3 nops
dnjz PUSHLOOP -> 4 nops while in loop (3 at end)


That makes 7 nops per 2-bytes.

It is already twice as fast as LDIR !

This estimate is good for big areas to fill. For small ones, setup cost is not negligible

Has anyone made a complete analysis ?

Question 2 : Can we do better ?

Yes. We can partially unroll the loop.

There are variants. The actual speed will be closer to 3 nops per 2 bytes, again twice as fast as before.

This is about 4 times faster then LDIR !

* If always the same length to write, just put many PUSH in a row.
* If that takes too much memory, just unroll partially, like 256 PUSH in a row. The loop will only be called 1 time out of 256 PUSH, that is not often.

* If length is to be variable and not too long, you can jump in the middle of the list of PUSH. For example, in pseudo-code :


If nbytes_to_write is odd, write extra byte, DEC nbytes_to_write.
Compute adress to jump to (it is PC + nbytes_to_write)
Jump
PUSH HL ;area with many PUSH HL
Figure out if we should continue


* If length is to be variable and long, things can be combined.

Wiping the CPC screen requires 16000 bytes (if optimizing to not write invisible scroling area). That would take 8000 PUSH or 24000 NOPS. A full screen retrace is about 20000 NOPS, see Frame flyback and interrupts .

That means, if we reduce a little the screen area, a CPC *can* write full screen memory in a single frame.

Question 3 : does an instruction exist on CPC that can write with an average speed of better than 3 nops per 2 bytes ?

EDIT : Changed title to close the topic.

[Optimus]

Iirc PUSH takes 4 NOPs. It's POP that takes 3 NOPs.


19968 NOPs per VBL. PUSH can write 2 bytes, so 2 NOPs per byte. That's 9984 bytes at best. 62.4% of CPC fullscreen.
Still, 25 fps are not bad for Sub Hunter parallax scrolling where this technique is used.

And problem with PUSH is that you can't just copy any arbitrary graphics just as in LDI. You have to preload as many regs as you can with your graphics before. Usually, it's just the same repeating pattern on the screen (like the repeating clouds on Sub Hunter) or just the same color, useful maybe for filling flat polygons (I tried it recently in my rasterizer, 4 mode 0 pixels in one go, but I had to also write edge pixels at left and right of scanline with some not very optimal code and lost the cycles I was hoping to gain except if polygon was very wide ).

[cpcitor]

Thank you for the information. How do you know they used that PUSH trick ? Which variant ? Unrolled loops ?

Writing even a constant value may be useful to clear area to prepare next frame, for example in space simulations (starion, starglider, elite, 3D starstrike), flight simulators, or similar (e.g. Stunt Car Racer that last one is better technically than pleasing to the eye).

CPC GAME REVIEWS - S
CPC GAME REVIEWS - S

[TFM]

Yes, you an be more quick that 1.5 ys. (BTW Optimus is surely right about the 2 ys/byte when using PUSH).
 
Now how to get more quick... Take a look at the CPCWiki, search for the 6 MHz CPC. I did create such a machine in the 90ies and it does run like hell That way you my achieve about 1.3 ys.

[Axelay]

Thank you for the information. How do you know they used that PUSH trick ? Which variant ? Unrolled loops ?

See for yourself.    Starts from the label ".PrintScroll", about halfway down the source file.

[TFM]

Well, that way works for smaller screens perfectly. But for bigger screens real scrolling using the CRTC saves a lot of CPU time.

[cpcitor]

Yes, you an be more quick that 1.5 ys.

Technically you're right. I only used µs because grimware does.
You know I meant NOPs.

(BTW Optimus is surely right about the 2 ys/byte when using PUSH).

So http://www.grimware.org/doku.php/documentations/devices/z80#stack.operations is wrong ?
There only IX IY related PUSH/POP are 4 NOPs, normal ones are 3 NOPS.

Now how to get more quick... Take a look at the CPCWiki, search for the 6 MHz CPC. I did create such a machine in the 90ies and it does run like hell That way you my achieve about 1.3 ys.

I've seen that already long before registering here. Is the MTBF impacted ?
Too bad it can't read normal disks... But it can read tapes, can't it ?

See for yourself.    Starts from the label ".PrintScroll", about halfway down the source file.

Smart code indeed.
Let's see what lines appear at least 10 times in that source code :

$ sort <SubHunter_Scroll.asm  | uniq -c | sort -rn | grep -v '^      '
    224     push de
    192     push bc
    104     inc l <-- cheaper than inc HL, yes
     88     exx  <-- wow, yes allows 4 different 16-bit values for texture. Smart !
     61
     31     dec a <-- primary counter
     18     ld h,a
     18     ld e,(hl)
     18     ld d,(hl)
     16     ld c,(hl)
     16     ld b,(hl)
     15 ;
     14     ld a,2
     12     ex af,af'

[TFM]

So http://www.grimware.org/doku.php/documentations/devices/z80#stack.operations is wrong ?

Yes, that's wrong. POP is 3 ys and PUSH is 4 ys (for AF, BC, DE, HL).
 
Just program an test program and let it run on a REAL CPC.

[db6128]

No need:
Unofficial Amstrad WWW Resource
Tested and verified on real hardware by Kevin (arnoldemu) and Richard (Executioner).

[cpcitor]

Ok, so it seems more or less proven that PUSH is the instruction with the highest throughput (lowest number of cycle per byte written) on the CPC.
Thanks for your hints.

[TFM]

Haha! In a theoretical way yes... but for drawing my sprites I use a way that needs only 2 ys per byte too and I don't have to deal with PUSH associated problems (DI, reset SP etc.). It's the good old LD (HL),R instruction where R is A, B, C, D, E, H or L.
 

[db6128]

Do you load those registers from memory or from the stack?
 
And I guess you make sure HL doesn’t overflow onto another page, and use INC L instead of INC HL.

[TFM]

- right, inc l only (fine in 256*256 screens without leaving borders)
- preload registers b, c, d, e before plotting sprites
- use ld (hl),&nn when other bytes are needed.
 
But it's amazing how much you can print with only preloading b, c, d and e.
 
 
Oh... and you don't load from stack or memory. YOU create a single routine for every sprite itslef! That makes it quick (else I would POP data from stack).