4 ms·
The "zero-page", the low 256 bytes, amounted to a big register bank; compilers for 6502 used it that way. The hardware stack was for return addresses only, and
by angiosperm 3y ago
The "zero-page", the low 256 bytes, amounted to a big register bank; compilers for 6502 used it that way. The hardware stack was for return addresses only, and was plenty; a zero-page pair pointed to the stack for arguments and locals. The designer of the ARM noted that her programs ran faster on 6502 than when ported to early 8086, largely because the latter was relatively so inefficient.
- kjs3 3y ago6502 fanbois like to pretended the zero page was registers because they had no choice and every since have tried to convince people that a weakness is a virtue. Better architectures don't have to pretend. And no one was talking about the 8086; most people who try to drag in an irrelevant processor to 'prove' 6502 superiority go 'but Z80!', so cudos for some originality. But it is now as it has always been: when you call someones pet processor ugly, you'll get all the specious arguments you can stomach.
- angiosperm 3y agoI never programmed 6502. But Sophie Wilson, who designed the ARM, and coded Acorn's BASIC interpreter, and shipped Acorns that could operate different CPUs on the same bus running her interpreter (ported), was in a better position to know than anybody else I know of. It is easy to confuse a more convenient programming model with more efficient operation.
- kjs3 3y agoI never programmed 6502. I did. I'm not cherry picking things I found on Google to try and be right.
- cmrdporcupine 3y agoThe # of clock cycles to access zero page on 6502 is still higher than from the register set. I forget the exact amount, but it's certainly not another register, from a pure efficiency POV. If I recall it's at least one more cycle. Adds up quite a bit if you're doing things like shuffling in and out of the (single) accumulator. The TMS9900 took this further, and had no onboard registers (other than PC & status register). Everything was in RAM. That model only made sense until RAM became slower than the bus speed (late 80s). The zero page in the 6800 and 6502 not being relocatable also sucked. Something fixed in the 6809 and 65816 respectively. I suspect the lessons Sophie Wilson learned from the 6502 were... cycle efficiency and minimalism. The 6502 was super responsive to interrupts precisely because it was so sparse on features.
- actionfromafar 3y agoThe zero page was faster than regular RAM access though, it's gotta count for something.
- angiosperm 3y agoMemory was one cycle, zero-page or not. Indirect through zero page was 3 cycles after the instruction fetch, the first two to collect the address, the third to use it. The other chips with 16-bit index registers should have had a huge advantage, but they spent lots of cycles doing nothing visible from the outside.
- jacquesm 3y agoIn an 8 bit environment, to shave off one cycle and a byte in the program ROM is a big enough advantage that the zero page concept made good sense just from that point of view. Motorola took further advantage of it by allowing the zeropage to be moved around which could be used to give the effect of a rather primitive context switch between tasks, and coupled with position independent code made multi tasking even more feasible. The reason the 16 bit index register indirect fetches were so slow is that they did a useless 'add' of 0 to the index register prior to the fetch. They also had an offset option and I guess letting it do it's usual thing with an offset of 0 made the silicon a bit simpler at the expense of a bit of efficiency.
- tenebrisalietum 3y agoRegister-register or immediate ops are 2 cycles (e.g. TXA, LDA #imm). Register-ZP ops are 3 cycles. Register-absolute (full 16-bit address) are 4 cycles. Indirect lookups add a cycle, indexed adds a cycle. There is some weirdness - e.g. pushing A to the stack is 3 cycles, but pulling it back is 4 cycles. And LSR/ASL start at 5 cycles for ZP access (6 for absolute) and you would think bit shifting would be super fast.
- jacquesm 3y agoThey are super fast, but they are a load, modify, store operation, hence the large number of cycles.
- jacquesm 3y agoCan we please talk about something as settled as decades old CPUs without resorting to name calling?