5 ms·

I've been working for the last two months in a personal project to build a 8-bit microcomputer based on AVR MCUs. Because these MUCs use a Harvard architecture

by reidrac 12y ago

I've been working for the last two months in a personal project to build a 8-bit microcomputer based on AVR MCUs. Because these MUCs use a Harvard architecture I implemented a 6502 VM to run programs from external SRAM. But I digress; the relevant bits for this story are that I'm using CC65, a compiler for the 6502, so I can write programs in C for my toy computer. It's impressive the amount of stuff CC65 does in its runtime just to implement C. Sure the 6502 is a beautiful processor (I loved implementing the VM!), but it is also very limited. Just an example: C65 implements its own stack in regular memory space because the actual stack of the 6502 is limited to 256 bytes! Every time you pass a pointer as a parameter in a function call the compiler loads the 16 bit address in A and X and pushes it into its own stack, where the the destination will access to it as needed. Look at the pushax implementation here: https://github.com/cc65/cc65/blob/master/libsrc/runtime/pushax.s https://github.com/cc65/cc65/blob/master/libsrc/runtime/push... All that just to "push value in a/x onto the stack". Amazing :) EDIT: typo

6502nerdface 12y ago
The cc65 project also has a very excellent 6502 assembler, ca65, which I find quite nice when writing assembly by hand. Together with ld65 it implements a full unix-style module/library-archive stack for 6502 object code. The assembler's macro system is quite well developed, as well, to the point that I prefer using it over cpp.
- JoachimS 12y ago
  Do you prefer it over KickAssembler? http://www.theweb.dk/KickAssembler/Main.php http://www.theweb.dk/KickAssembler/Main.php
- reidrac 12y ago
  ca65 is the only 6502 assembler I've used, but I have experience with other CPUs assemblers and I must say I like ca65's macros a lot.
antimagic 12y ago
Hah, my first though on reading this was that the software stack implementation must slow the machine down horribly. Then I remembered that this was back in the day before cache memory and other optimisations existed, making the technique close to comparable to using the hardware-implemented stack.
- blt 12y ago
  Caches existed, just not in microprocessors. The IBM 360 model 85 introduced caches in 1968 [1]. The DEC PDP-11/70 had one in 1975 [2], the same year the 6502 debuted. The Motorola 68020 was the first Motorola microprocessor with a cache in 1984, and the 386DX was Intel's first in 1985 [Wikipedia]. I agree, it's kind of shocking to read about the designs people could get away with before caches became important. It also illustrates why it's so important to continually re-evaluate any programming doctrine related to performance and data organization. [1] http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360..., see references to "buffer storage" [2] http://www.pdp-11.nl/pdp11-70startpage.html http://www.pdp-11.nl/pdp11-70startpage.html
- to3m 12y ago
  Not so - this routine actually takes a long time by comparison, and I've no doubt the execution will be shamefully slow :) To push 16 bits to the hardware stack on the standard 6502 takes 8 or 9 cycles (depending how you retrieve the second byte); this routine takes 50 (as a round trip including the JSR).
userbinator 12y ago
Just an example: C65 implements its own stack in regular memory space because the actual stack of the 6502 is limited to 256 bytes! 256? That's twice as much as all of a standard 8051's RAM, which is only 128 bytes! The 8051 is probably the other 8-bit Harvard MCU that's still in widespread use, and compilers have managed to make C run on it; external stack emulation is one of the things they do too. It also happens to be one of the very few architectures with an upward-growing stack (a push increments the stack pointer.)
- klibertp 12y ago
  > still in widespread use Wait, where, how? And why? (Honestly curious!)
  - jhallenworld 12y ago
    There are many 8051 clones available.. it's one of the cheapest microcontrollers you can buy, but popular no doubt due to installed base plus tools from Keil. But it's certainly not the only Harvard architecture processor still in use. Microchip's PIC is the other big one- in fact it predates the 8051, having been available from General Instruments since 1976.
  - rlonstein 12y ago
    I'm finding 8051 variants integrated into SOC's for capacitive touch screens, RFID readers, and even in contactless "smart" cards.
- reidrac 12y ago
  The 8051 is an MCU, the 6502 is not! May be my comment was confusing: I'm implementing a 6502 VM in an ATmega MCU; but my comment was about 6502's limitations and that I can relate to Wozniak's frustrations dealing with 16 bit data.

by reidrac 12y ago

6502nerdface 12y ago

The cc65 project also has a very excellent 6502 assembler, ca65, which I find quite nice when writing assembly by hand. Together with ld65 it implements a full unix-style module/library-archive stack for 6502 object code. The assembler's macro system is quite well developed, as well, to the point that I prefer using it over cpp.

JoachimS 12y ago
Do you prefer it over KickAssembler? http://www.theweb.dk/KickAssembler/Main.php http://www.theweb.dk/KickAssembler/Main.php
reidrac 12y ago
ca65 is the only 6502 assembler I've used, but I have experience with other CPUs assemblers and I must say I like ca65's macros a lot.

antimagic 12y ago

Hah, my first though on reading this was that the software stack implementation must slow the machine down horribly. Then I remembered that this was back in the day before cache memory and other optimisations existed, making the technique close to comparable to using the hardware-implemented stack.

blt 12y ago
Caches existed, just not in microprocessors. The IBM 360 model 85 introduced caches in 1968 [1]. The DEC PDP-11/70 had one in 1975 [2], the same year the 6502 debuted. The Motorola 68020 was the first Motorola microprocessor with a cache in 1984, and the 386DX was Intel's first in 1985 [Wikipedia]. I agree, it's kind of shocking to read about the designs people could get away with before caches became important. It also illustrates why it's so important to continually re-evaluate any programming doctrine related to performance and data organization. [1] http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360..., see references to "buffer storage" [2] http://www.pdp-11.nl/pdp11-70startpage.html http://www.pdp-11.nl/pdp11-70startpage.html
to3m 12y ago
Not so - this routine actually takes a long time by comparison, and I've no doubt the execution will be shamefully slow :) To push 16 bits to the hardware stack on the standard 6502 takes 8 or 9 cycles (depending how you retrieve the second byte); this routine takes 50 (as a round trip including the JSR).

userbinator 12y ago

Just an example: C65 implements its own stack in regular memory space because the actual stack of the 6502 is limited to 256 bytes! 256? That's twice as much as all of a standard 8051's RAM, which is only 128 bytes! The 8051 is probably the other 8-bit Harvard MCU that's still in widespread use, and compilers have managed to make C run on it; external stack emulation is one of the things they do too. It also happens to be one of the very few architectures with an upward-growing stack (a push increments the stack pointer.)

klibertp 12y ago
> still in widespread use Wait, where, how? And why? (Honestly curious!)
- jhallenworld 12y ago
  There are many 8051 clones available.. it's one of the cheapest microcontrollers you can buy, but popular no doubt due to installed base plus tools from Keil. But it's certainly not the only Harvard architecture processor still in use. Microchip's PIC is the other big one- in fact it predates the 8051, having been available from General Instruments since 1976.
- rlonstein 12y ago
  I'm finding 8051 variants integrated into SOC's for capacitive touch screens, RFID readers, and even in contactless "smart" cards.
reidrac 12y ago
The 8051 is an MCU, the 6502 is not! May be my comment was confusing: I'm implementing a 6502 VM in an ATmega MCU; but my comment was about 6502's limitations and that I can relate to Wozniak's frustrations dealing with 16 bit data.