11 ms·

With the optics of _compiled_ code, how do the various 8-bitters stack up? (6809/6811, 65C02, Z80, H8, ...)? One would have to account for the frequency allowe

With the optics of _compiled_ code, how do the various 8-bitters stack up? (6809/6811, 65C02, Z80, H8, ...)? One would have to account for the frequency allowed by the ISA at iso-technologies (which makes including AVR somewhat tricky). I only have experience with Z80 and 65C02 and I believe the consensus is that a 4 MHz Z80 beats a 2 MHz 65C02, but neither is a particularly nice compiler target.

crest 4y ago
The 6809 had two 16 bit index registers, PC-relative addressing, and upper half of the stack and data page address was taken from special purpose registers instead of hardwired. It should be a fairly straight forward compiler target. On the other hand it was late to the game, expensive and not (much) faster than 8bit microprocessors. The 6502 very cheap, fast enough when it came out, but a really annoying compiler target.
- PaulHoule 4y ago
  I had a TRS-80 Color Computer when I was kid which had one major drawback: it could only display 32 characters across the screen compared to 40 characters for the Apple ][, C64 and most others at the time. The Coco could run an operating system called OS-9 which was Unix-influenced and came with a good C compiler and also a bytecode interpreted structure basic called BASIC09. I know C compilers were really popular among CP/M users running the Z-80 and 8080 chips and also on the IBM PC which had a segmentation system to reach beyond 64k that I thought felt really elegant in assembly language but was awkward for compilers. Where OS-9 had all the above beat was that it was a real multitasking OS and I had two terminals plugged into my coco in addition to the TV console and could use it like a minicomputer. When I switched to an IBM PC AT compatible my favorite programming language was Turbo Pascal which adds everything missing from Pascal to do systems programming. I switched to C when I went to college because that was supported on the the various UNIX workstations they had.
  - jhallenworld 4y ago
    The 6809 was nice, but I think the CoCo otherwise was crap. Aside from the 32 column display and awful color scheme, the built-in serial port was bit-banged. This meant that floppy drive and serial access could not happen at the same time. This is very relevant when trying to use OS-9. There was an external serial port as an option, but there was only one slot. So you also had to buy a slot expander (a Multi-Pak).
    - PaulHoule 4y ago
      I had the multi pak and the external uart. The entry level price of the coco was low but I think I got most of the peripherals available for it, particularly the disks were crazy expensive. Adding it all up I must have spent more than I spent on the AT clone that replaced it ($1200) In most ways the C-64 was a great machine but boy was the disk drive slow.
      - jhallenworld 4y ago
        Perfect system == 6809 + SIO from the Atari800 + C64 SID + IBM PC keyboard + C64 VIC or maybe V9938.
        ddingus 4y ago
        That would be fun! I would add the MMU from the CoCo 3, so one can bank in lots of RAM with only minor league fuss.
    - PaulHoule 4y ago
      Note that hardware flow control makes the bit banger a lot more reliable than it would be otherwise. I had the bit banger connected to a compact printing terminal from DEC that ran at 300 baud and had an acoustic coupler so you could log into 300 baud services with nothing but the terminal. There was not a lot of risk that this device would overflow your buffers.
self 4y ago
Some of that can be gleaned from this benchmark, published in Byte, in 1981: https://en.wikipedia.org/wiki/Byte_Sieve https://en.wikipedia.org/wiki/Byte_Sieve Results for a few 8/16 bit processors are here (and on subsequent pages): https://archive.org/details/byte-magazine-1981-09/page/n193/mode/1up https://archive.org/details/byte-magazine-1981-09/page/n193/...
- FullyFunctional 4y ago
  Very cool. While obviously not ideal, the results are probably accurate within a small factor. Unfortunately there's no assembly version for 65C02 but Z80 does surprisingly well in this test. I muse what could be done with modern cross-compiler (SAT solving for optional code sequences?) A llvm backend for Z80 has recently kicked back into gear: https://github.com/jacobly0/llvm-project https://github.com/jacobly0/llvm-project
- mysterymath 4y ago
  I ran the C version of this benchmark using llvm-mos's Clang for the 6502. The results: 21.4 seconds 5793 bytes Which is middle of thepack for the Z80 benchmarks, but well below the 6502 ones. We're also using a slightly tweaked embedded printf written in C, so this could probably be improved somewhat there, sans any compiler changes.
  - bpye 4y ago
    Wow, I didn't realise there was a project to add a 6502 target to LLVM. Now to get Rust working...
    - mysterymath 4y ago
      https://github.com/mrk-its/rust-mos https://github.com/mrk-its/rust-mos
cmrdporcupine 4y ago
I just don't think any of the 8-bits made good compiler targets. At least not C compilers. Not enough registers, even in the 6809.
- PaulHoule 4y ago
  When you’ve got hardly any registers you don’t have any choices how to allocate them. What’s maddening is a chip like the 8086 where you have enough registers that how you allocate them matters, but still very little space to work in. You are left working hard on a register allocator that is still not going to be very food.
- hashmash 4y ago
  In theory, a smart compiler could make heavy use of the DP register (6809 feature) and then local variables within a compiled function could access these "fast" global variables instead. This was a common pattern when coding in assembly, and it's much faster than accessing variables off the stack. The function wouldn't be reentrant, but a compiler pragma could be used to enable/disable the DP mode. Declaring the local variables as static should be sufficient, however.
  - jhallenworld 4y ago
    I wrote a multi-tasking OS for the 6809 and used the DP to hold the current task ID: task local variables would be in the direct page.
  - cmrdporcupine 4y ago
    The WDC C compiler for the 65816 takes advantage of this (relocatable direct page). And the relocatable stack. In fact I believe what it does is relocate the stack to at least partially overlap the direct page. It's still an awkward target though.
  - ncmncm 4y ago
    Back then, memory was only one cycle away, so was practically registers. This is why the 6502 zero page was so important. 6502 instructions took very few cycles, so you could move a zero-page byte to the accumulator in 3 cycles, sometimes 2, and is why a $25 6502 could match a $200 Z80. Z80 had a faster clock, but instructions took loads of cycles. Nowadays that is OK, but Z80 did not pipeline. It had fancy looping instructions, but they ran slower than the loop would have.
deleted 4y ago
[deleted]
Gordonjcp 4y ago
The 6809 is ridiculously suitable for running Forth, because you've got two stacks, a 16-bit accumulator, and you can implement NEXT in two instructions taking about three clocks each.
- cmrdporcupine 4y ago
  Someone needs to write a WASM VM for it.
klodolph 4y ago
Just for modern perspective... you can use SDCC. It's an open-source optimizing C compiler targeting small microprocessors like the Z80 and various others. The project itself is terribly run--the maintainers recently pushed out an ABI change which broke everyone's code, but released it as a minor version bump. This ABI change did speed up the code, but that's small consolation to anyone who ended up with broken code. IMO the Z80 is a lot nicer compiler target than the 6502, because the stack pointer is 16-bit and it's much easier to use the stack in general. There are a couple C compilers for 6502 (like cc65 and WDC's C compiler) but they're not quite as good as SDCC, as far as I can tell. They're also not as actively maintained.
- davidgould 4y ago
  > The project itself is terribly run--the maintainers recently pushed out an ABI change which broke everyone's code, but released it as a minor version bump. When was this? What version? Thanks.
  - klodolph 4y ago
    SDCC 4.2.0, released Mar 8, 2022.
    - davidgould 4y ago
      I don't think your comment about a breaking abi change on a minor point release is fair. Perhaps you have misunderstood the release number scheme? Every year around the first quarter they have one major release, ie 3.9, 4.0, 4.1, and now 4.2. A minor release would be like 4.2.1. There is no significance to the major digit, ie 4.0 was just the release a year after 3.9 and not otherwise special. I'm not affiliated with the project, but I think would be unfortunate if someone was turned away using or contributing to the best or only opensource tool chain for a number of processors (eg the paduak family) because someone claimed the project was terribly run. Please consider updating your comment.

crest 4y ago

The 6809 had two 16 bit index registers, PC-relative addressing, and upper half of the stack and data page address was taken from special purpose registers instead of hardwired. It should be a fairly straight forward compiler target. On the other hand it was late to the game, expensive and not (much) faster than 8bit microprocessors. The 6502 very cheap, fast enough when it came out, but a really annoying compiler target.

PaulHoule 4y ago
I had a TRS-80 Color Computer when I was kid which had one major drawback: it could only display 32 characters across the screen compared to 40 characters for the Apple ][, C64 and most others at the time. The Coco could run an operating system called OS-9 which was Unix-influenced and came with a good C compiler and also a bytecode interpreted structure basic called BASIC09. I know C compilers were really popular among CP/M users running the Z-80 and 8080 chips and also on the IBM PC which had a segmentation system to reach beyond 64k that I thought felt really elegant in assembly language but was awkward for compilers. Where OS-9 had all the above beat was that it was a real multitasking OS and I had two terminals plugged into my coco in addition to the TV console and could use it like a minicomputer. When I switched to an IBM PC AT compatible my favorite programming language was Turbo Pascal which adds everything missing from Pascal to do systems programming. I switched to C when I went to college because that was supported on the the various UNIX workstations they had.
- jhallenworld 4y ago
  The 6809 was nice, but I think the CoCo otherwise was crap. Aside from the 32 column display and awful color scheme, the built-in serial port was bit-banged. This meant that floppy drive and serial access could not happen at the same time. This is very relevant when trying to use OS-9. There was an external serial port as an option, but there was only one slot. So you also had to buy a slot expander (a Multi-Pak).
  - PaulHoule 4y ago
    I had the multi pak and the external uart. The entry level price of the coco was low but I think I got most of the peripherals available for it, particularly the disks were crazy expensive. Adding it all up I must have spent more than I spent on the AT clone that replaced it ($1200) In most ways the C-64 was a great machine but boy was the disk drive slow.
    - jhallenworld 4y ago
      Perfect system == 6809 + SIO from the Atari800 + C64 SID + IBM PC keyboard + C64 VIC or maybe V9938.
      - ddingus 4y ago
        That would be fun! I would add the MMU from the CoCo 3, so one can bank in lots of RAM with only minor league fuss.
  - PaulHoule 4y ago
    Note that hardware flow control makes the bit banger a lot more reliable than it would be otherwise. I had the bit banger connected to a compact printing terminal from DEC that ran at 300 baud and had an acoustic coupler so you could log into 300 baud services with nothing but the terminal. There was not a lot of risk that this device would overflow your buffers.

self 4y ago

Some of that can be gleaned from this benchmark, published in Byte, in 1981: https://en.wikipedia.org/wiki/Byte_Sieve https://en.wikipedia.org/wiki/Byte_Sieve Results for a few 8/16 bit processors are here (and on subsequent pages): https://archive.org/details/byte-magazine-1981-09/page/n193/mode/1up https://archive.org/details/byte-magazine-1981-09/page/n193/...

FullyFunctional 4y ago
Very cool. While obviously not ideal, the results are probably accurate within a small factor. Unfortunately there's no assembly version for 65C02 but Z80 does surprisingly well in this test. I muse what could be done with modern cross-compiler (SAT solving for optional code sequences?) A llvm backend for Z80 has recently kicked back into gear: https://github.com/jacobly0/llvm-project https://github.com/jacobly0/llvm-project
mysterymath 4y ago
I ran the C version of this benchmark using llvm-mos's Clang for the 6502. The results: 21.4 seconds 5793 bytes Which is middle of thepack for the Z80 benchmarks, but well below the 6502 ones. We're also using a slightly tweaked embedded printf written in C, so this could probably be improved somewhat there, sans any compiler changes.
- bpye 4y ago
  Wow, I didn't realise there was a project to add a 6502 target to LLVM. Now to get Rust working...
  - mysterymath 4y ago
    https://github.com/mrk-its/rust-mos https://github.com/mrk-its/rust-mos

cmrdporcupine 4y ago

I just don't think any of the 8-bits made good compiler targets. At least not C compilers. Not enough registers, even in the 6809.

PaulHoule 4y ago
When you’ve got hardly any registers you don’t have any choices how to allocate them. What’s maddening is a chip like the 8086 where you have enough registers that how you allocate them matters, but still very little space to work in. You are left working hard on a register allocator that is still not going to be very food.
hashmash 4y ago
In theory, a smart compiler could make heavy use of the DP register (6809 feature) and then local variables within a compiled function could access these "fast" global variables instead. This was a common pattern when coding in assembly, and it's much faster than accessing variables off the stack. The function wouldn't be reentrant, but a compiler pragma could be used to enable/disable the DP mode. Declaring the local variables as static should be sufficient, however.
- jhallenworld 4y ago
  I wrote a multi-tasking OS for the 6809 and used the DP to hold the current task ID: task local variables would be in the direct page.
- cmrdporcupine 4y ago
  The WDC C compiler for the 65816 takes advantage of this (relocatable direct page). And the relocatable stack. In fact I believe what it does is relocate the stack to at least partially overlap the direct page. It's still an awkward target though.
- ncmncm 4y ago
  Back then, memory was only one cycle away, so was practically registers. This is why the 6502 zero page was so important. 6502 instructions took very few cycles, so you could move a zero-page byte to the accumulator in 3 cycles, sometimes 2, and is why a $25 6502 could match a $200 Z80. Z80 had a faster clock, but instructions took loads of cycles. Nowadays that is OK, but Z80 did not pipeline. It had fancy looping instructions, but they ran slower than the loop would have.

deleted 4y ago

[deleted]

Gordonjcp 4y ago

The 6809 is ridiculously suitable for running Forth, because you've got two stacks, a 16-bit accumulator, and you can implement NEXT in two instructions taking about three clocks each.

cmrdporcupine 4y ago
Someone needs to write a WASM VM for it.

klodolph 4y ago

Just for modern perspective... you can use SDCC. It's an open-source optimizing C compiler targeting small microprocessors like the Z80 and various others. The project itself is terribly run--the maintainers recently pushed out an ABI change which broke everyone's code, but released it as a minor version bump. This ABI change did speed up the code, but that's small consolation to anyone who ended up with broken code. IMO the Z80 is a lot nicer compiler target than the 6502, because the stack pointer is 16-bit and it's much easier to use the stack in general. There are a couple C compilers for 6502 (like cc65 and WDC's C compiler) but they're not quite as good as SDCC, as far as I can tell. They're also not as actively maintained.

davidgould 4y ago
> The project itself is terribly run--the maintainers recently pushed out an ABI change which broke everyone's code, but released it as a minor version bump. When was this? What version? Thanks.
- klodolph 4y ago
  SDCC 4.2.0, released Mar 8, 2022.
  - davidgould 4y ago
    I don't think your comment about a breaking abi change on a minor point release is fair. Perhaps you have misunderstood the release number scheme? Every year around the first quarter they have one major release, ie 3.9, 4.0, 4.1, and now 4.2. A minor release would be like 4.2.1. There is no significance to the major digit, ie 4.0 was just the release a year after 3.9 and not otherwise special. I'm not affiliated with the project, but I think would be unfortunate if someone was turned away using or contributing to the best or only opensource tool chain for a number of processors (eg the paduak family) because someone claimed the project was terribly run. Please consider updating your comment.