How much benefit should be expected on a more advanced compiler for z80/r800 based computers?

Question

I am self studying about compilers, and get hands on very good textbooks about the subject. I am thinking in develop a compiler using the almighty llvm infrastructure to cross compile to old computers, initially MSX ones. The thing is, i can't get an impression on how much benefit one could get on using this approach, over what is already on old compilers.

Obviously, the possibility to reuse code over different platforms is one, if a common compiler is to be developed, but the idea is getting the most of such processors, using modern optimization.

I understand that some obviously don't apply, like scheduling, but there is a lot of things that are done before code generation, and will be beneficial to every backend. The question i make is, how beneficial it will be to deliver such tool, compared to what is already on legacy compilers, and to modern ones too (sdcc and others). Also, how much this kind of effort could be beneficial to ease multi platform development (Uzix and the like) considering the severe restrictions on those platforms?

EDIT: I changed the subject of the question to reflect only MSX, to adjust the scope that was too broad.

Answer 1

Places where LLVM will provide no benefit, and may reduce performance:

• The Z80 has no CPU cache, accessing memory directly instead. Any optimizations based around increasing cache efficiency (eg. aligning sequentially-accessed data to fit in a single cache line, or re-ordering instructions to group common execution paths together) will have, at best, no effect.
• The Z80 is a strictly in-order CPU with just a single execution unit. Optimizations such as instruction re-ordering to permit out-of-order or parallel execution will have no effect.
• The Z80 has a shallow-to-nonexistent pipeline and no speculative execution. Optimizations based around branch prediction or preventing pipeline stalls will have no effect.
• The Z80 is often paired with a small amount of RAM. Many optimizations (such as loop unrolling or function inlining) make the program larger, and can't be used if the program would no longer fit in RAM.

Places where LLVM will shine:

• Anything based on abstract analysis of the code, such as constant folding or common-subexpression elimination. Many of these techniques were developed long after the original Z80 compilers.
• Register allocation: The Z80 has approximately 17 registers (depending on how you count), with complex rules about how you can use them. LLVM's design can draw on 30-40 years of research in this area that older compilers can't.

The improvement in abstract-analysis techniques in the past 40 years is huge. Even in the absence of hardware-specific optimizations, I'd expect LLVM-generated code to be much faster than that from older compilers, and competitive with all but the best hand-optimized assembly.

Answer 2

Z88DK is a suite of development tools for Z80 targets that includes a couple of different C compilers (one a variant of Small C and one a patched version of SDCC) and an assembly-level optimizer that is run as a post-filter on the output of these compilers. It also has a highly hand-optimized library.

They've published a set of benchmarks versus some older Z80 compilers (e.g. HISOFT-C and SDCC without their updates/optimizer) that depending on application show gains from 15% (Dhrystone) to 300% (Pi calculation). At the same time they show gains in code size varying from 7% to about 90% (I presume due to elimination of large chunks of duplicate code). Floating point performance is lower than some of the older compilers however - but that's because they're using higher-precision 48-bit floats rather than the 32-bit floats used by the older compilers.

It is able to target a variety of platforms including MSX, CP/M, and many of the early 80s home computers that used Z80 CPUs.

Answer 3

i can't get an impression on how much benefit one could get on using this approach, over what is already on old compilers.

If that were true, then old games would be developed using those old compilers, instead of hand-coded assembly. Old compilers were, mostly, very naive in terms of code optimization due to they being executing in the very same system they are producing code for, thus suffering from severe lack of precious RAM that would be needed to implement more sophisticated optimization techniques.

Answer 4

regular user of the MSX-C compiler here. MSX-C is a rebranded version of the LSI-C 80 compiler bundled with an MSX-specific library. It comes with the same limitations and benefits:

• PRO: When calling functions, MSX-C passes arguments on the CPU registers instead of the stack (as SDCC or Hitech-C do). This results in a big performance improvement in programs that do a lot of function calling.

• CON: The compiler doesn't do any memory switching during the compile process. This means that you run out of memory quickly when developing complex programs. This forces the developer to split the program in smaller units and compile/link per parts.

• CON: MSX-C only understands K&R C. SDCC and Hitech-C support more modern dialects of C.

• PRO: MSX-C runs natively on the MSX. There's no need to waste time compiling under Linux/Windows and moving the binary to the MSX.

In my opinion, just writing a compiler for MSX able to use the memory mapper would be a huge improvement. Running out of memory is the biggest annoyance I've found so far.

Answer 5

I would reply in a more cagey fashion. It would certainly be useful to have a better C compiler for Z80 - the existing ones are not producing very good code. It is also clear that a number of people are experimenting, even with these not very good compilers, and end up creating new and useful software. Some of these software are definitely not bad. My real concerns are as follows:

• It is clear that you ought to be able to write a better compiler than the existing ones. It is not clear if you can write a really good compiler - the one that would tempt asm coders to switch, because the gap between a good asm code and a good compiled code on Z80 platforms at the moment is massive.
• Part of the problem is to do with the fact that C was not really designed with 8-bit platforms in mind. The vast majority of the code assumes at least 16-bit int; the local variables cannot be efficiently allocated on stack and addressed on Z80, which makes implementation of function parameters very painful, especially with recursion allowed. It can all be supported, of course, but at the cost of writing significantly less efficient code. To address this things properly you would need to make changes to the language itself, and that will put a lot of people off.
• To make matters worse, a lot of paradigms for efficient Z80 coding are really not fitting into C. Things like movable stack pointers, self-modifying code, partial loop unrolling are just not catered for. Just like every Z80 coder, I would love to see a compiler with a bit of intuition for the use of Z80 registers, but I do not hold much hope.