Hacker News Reader

Comment by FullyFunctional | Hacker News Reader

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.

View on HN

Some of that can be gleaned from this benchmark, published in Byte, in 1981: 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/...

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

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.

Wow, I didn't realise there was a project to add a 6502 target to LLVM. Now to get Rust working...

https://github.com/mrk-its/rust-mos

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.

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.

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).

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.

Perfect system == 6809 + SIO from the Atari800 + C64 SID + IBM PC keyboard + C64 VIC or maybe V9938.

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.

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.

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.

> 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.

SDCC 4.2.0, released Mar 8, 2022.

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.

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.

Someone needs to write a WASM VM for it.

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.

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.

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.

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.

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.

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.

These processors were designed for assembly programming, hence their very CISC-y ISA. Some 8-bitters designed for compiled languages would be the AVR family.

That's too generous. They were primarily designed for what was easy to implement and what _could_ be handled in assembly. Also, 8080 was an evolution of the 4040 (and that owed much to the 4004). Z80 had to be compatible with the 8080... I know less of 6502 but most of them were designed about what could be done, not what would be easy to program.

I actually only recently learned that the 8008/8080 was in fact not based on the 4004/4040 instruction set. They used the same numbering system, but the ISA has little to nothing in common with it and in fact the 8008 project was in started before the 4004:

https://sites.google.com/site/microprocessorintel4004/8008-8...

Thanks I might misremember. Regradless, 8080 is still awful and they could have sone better with more foresight (which is easy to say so many decades later).

C compiled for the 6502 would use the zero page (first 256 bytes of RAM) as registers, and use the actual registers just to run instructions of a higher-level abstract machine that, e.g., understood 16-bit numbers. Kind of like Xerox Alto, in that particular way; on the Alto, only device drivers were coded native.

There was a C compiler that kept one of the 6502 index registers zero at all times, just to have a zero handy.

This use of a little interpreter to provide a higher-level instruction architecture to program to was really, really common in the 50s and 60s. The Apollo AGC computer that landed on the moon was mostly programmed that way. It seems surprising that with memory so tight, they would use up so much of it for the virtual machine interpreter, but instructions for that could be much more compact than native code. It made a slow computer even slower, but they all felt fast back then.

Steve Wozniak burned a little interpreter like that into the Apple ][ ROM, just smart enough for dumb jobs like copying blocks of memory. It used a reserved fragment of the zero page as its registers.

Reply on news.ycombinator.com