3 ms·

I 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 t

I 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 ago
I never programmed 6502. I did. I'm not cherry picking things I found on Google to try and be right.
cmrdporcupine 3y ago
The # 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 ago
  The zero page was faster than regular RAM access though, it's gotta count for something.
  - angiosperm 3y ago
    Memory 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 ago
      In 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 ago
  Register-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 ago
    They are super fast, but they are a load, modify, store operation, hence the large number of cycles.
- jacquesm 3y ago
  In modern parlance I think the best way to think of the zero page is as a primitive form of 'nearby' memory, we'd do this transparently through a cache. Some processors extended this 'register file in RAM' concept considerably, for instance the https://en.wikipedia.org/wiki/TMS9900 https://en.wikipedia.org/wiki/TMS9900 TMS9900 with it's workspace register. All of these concepts, register file, cache, context memory were quite fluid at the time and not yet settled in the way we see them today so it isn't surprising to see one party refer to the 6502 zero page (or the 6809 direct page) as an extension of the register file in the CPU and another to see it as a cache, a task context or more efficient bit of memory. All of these can be right, it's just a POV difference.
  - kjs3 3y ago
    I don't disagree that there was significant malleability in nomenclature, but the idea that zero-pages or 9900-style workspaces were register equivalents was in the most charitable sense was never anything but marketing, and never by anyone who honestly did the math. Even the 9900 folks pretty quickly stopped trying to convince us they had 'registers' and moved to how quickly they could change contexts and mitigate the speed asymmetries between on and off chip memory.
  - cmrdporcupine 3y ago
    I absolutely agree, I don't think I would contradict that in any way, I just think the above exchange I was replying to was silly on both fronts and dunno why it got heated but wanted to provide more tempered POV on the utility of the zero page as a set of registers. You can frame it that way, and compilers often do, but it's honestly stretching the "truth" a bit. And for that I got downvoted. Huh.

kjs3 3y ago

I never programmed 6502. I did. I'm not cherry picking things I found on Google to try and be right.

cmrdporcupine 3y ago

The # 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 ago
The zero page was faster than regular RAM access though, it's gotta count for something.
- angiosperm 3y ago
  Memory 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 ago
    In 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 ago
Register-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 ago
  They are super fast, but they are a load, modify, store operation, hence the large number of cycles.
jacquesm 3y ago
In modern parlance I think the best way to think of the zero page is as a primitive form of 'nearby' memory, we'd do this transparently through a cache. Some processors extended this 'register file in RAM' concept considerably, for instance the https://en.wikipedia.org/wiki/TMS9900 https://en.wikipedia.org/wiki/TMS9900 TMS9900 with it's workspace register. All of these concepts, register file, cache, context memory were quite fluid at the time and not yet settled in the way we see them today so it isn't surprising to see one party refer to the 6502 zero page (or the 6809 direct page) as an extension of the register file in the CPU and another to see it as a cache, a task context or more efficient bit of memory. All of these can be right, it's just a POV difference.
- kjs3 3y ago
  I don't disagree that there was significant malleability in nomenclature, but the idea that zero-pages or 9900-style workspaces were register equivalents was in the most charitable sense was never anything but marketing, and never by anyone who honestly did the math. Even the 9900 folks pretty quickly stopped trying to convince us they had 'registers' and moved to how quickly they could change contexts and mitigate the speed asymmetries between on and off chip memory.
- cmrdporcupine 3y ago
  I absolutely agree, I don't think I would contradict that in any way, I just think the above exchange I was replying to was silly on both fronts and dunno why it got heated but wanted to provide more tempered POV on the utility of the zero page as a set of registers. You can frame it that way, and compilers often do, but it's honestly stretching the "truth" a bit. And for that I got downvoted. Huh.