3 ms·

It's even much worse than that ;) The fastest Z80 instructions are 4 clock cycles, at least 7 clock cycles if they also need to load or store an 8-bit value fr

It's even much worse than that ;) The fastest Z80 instructions are 4 clock cycles, at least 7 clock cycles if they also need to load or store an 8-bit value from/to memory, and at least 10 clock cycles for instructions that load or store a 16-bit value. I did a little deep dive into Z80 timings a little while ago using the Z80 netlist simulation from visual6502.org: https://floooh.github.io/2021/12/06/z80-instruction-timing.html https://floooh.github.io/2021/12/06/z80-instruction-timing.h... But for BASIC programs those timings don't matter much, since BASIC on 8-bit home computers was easily 100x times slower than assembly code doing the same thing (the difference is probably less though when floating point math is involved, since this also needs to be 'software-emulated' in assembly).

teaearlgraycold 3y ago
Damn, we’re in CPI territory
- mbitsnbites 3y ago
  Yup. Everything pre-RISC was CPI (Cray doesn't count - it was effectively RISC, and way too expensive anyway).
abecedarius 3y ago
To grasp the interpreter speed you need to remember how memory was even more of a constraint than CPU. BASIC had to hold your code in RAM in way that's source-editable and runnable and compact, and process it using interpreter code that's also squeezed for its space. Any obvious optimization you just assume for a speed demon like Python nowadays, you might be surprised about when it comes to those 8-bit Basics.
crq-yml 3y ago
I've been working with eZ80 on Agon Light and the performance ceiling is considerably different. Both the clocks and the instruction timings are more generous owing to a three-stage pipeline, so while interpretation is still slow, and it's got a clear preference for either 8 or 24-bit(in ADL mode), it is now a Z80 that can be applied productively to high-level code operating over 32-bit values... ...except that the BBC BASIC was giving me Heisenbugs, so I had to give up on it. So I'm on Forth now, and immediately found that Forth is a more productive environment than an early BASIC anyway. Linenums add a killer amount of bookkeeping.

teaearlgraycold 3y ago

Damn, we’re in CPI territory

mbitsnbites 3y ago
Yup. Everything pre-RISC was CPI (Cray doesn't count - it was effectively RISC, and way too expensive anyway).

abecedarius 3y ago

To grasp the interpreter speed you need to remember how memory was even more of a constraint than CPU. BASIC had to hold your code in RAM in way that's source-editable and runnable and compact, and process it using interpreter code that's also squeezed for its space. Any obvious optimization you just assume for a speed demon like Python nowadays, you might be surprised about when it comes to those 8-bit Basics.

crq-yml 3y ago

I've been working with eZ80 on Agon Light and the performance ceiling is considerably different. Both the clocks and the instruction timings are more generous owing to a three-stage pipeline, so while interpretation is still slow, and it's got a clear preference for either 8 or 24-bit(in ADL mode), it is now a Z80 that can be applied productively to high-level code operating over 32-bit values... ...except that the BBC BASIC was giving me Heisenbugs, so I had to give up on it. So I'm on Forth now, and immediately found that Forth is a more productive environment than an early BASIC anyway. Linenums add a killer amount of bookkeeping.