Why do C to Z80 compilers produce poor code? (2018)

As noted in the first post, the Z80 is still much easier to generate code for than the 6502.<p>I see everyone there seems to be referring to free&#x2F;open-source compilers, but I know of one commercial compiler for Z80 (IAR) whose output is quite good, and I have linked to in this previous comment I made on a different article about Z80 C compilation:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18902501" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18902501</a><p>If one didn&#x27;t know better, it would look almost like handwritten Asm.<p>On the topic of architectures which are difficult to compile C to, I can also think of several more: 8051, low-end PIC series, and these: <a href="https:&#x2F;&#x2F;cpldcpu.wordpress.com&#x2F;2019&#x2F;08&#x2F;12&#x2F;the-terrible-3-cent-mcu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cpldcpu.wordpress.com&#x2F;2019&#x2F;08&#x2F;12&#x2F;the-terrible-3-cent...</a><p>...and most of those have C (or at least C-subset) compilers too.

The accepted answer is somewhat true but also has some glaring inaccuracies.<p>The fact is that there are&#x2F;were some very effective C compilers for Z80, none of them free and far from it. By the time compiler technology advanced through the 80s and 90s the market for a non commercial optimizing compiler for the Z80 and 6502 rapidly diminished. gcc has <i>never</i> in its history been a fantastic 8 or 16 bit compiler. By the time egcs was merged even 68k was rapidly losing relevance.<p>It is totally possible with modern techniques to make a very effective optimizing C compiler for Z80, but who’s going to do it? There are very few hobbyists with both the chops <i>and</i> the time for something with little commercial value.<p>The answer is correct in implying that the PDP was better suited as a CISC target for C when optimization is not done.

I see a lot of Z80 enthusiasm on the web, is there a good forum&#x2F;website to talk to the hard core? I just finished porting the classic Sargon Z80 chess program to run on x86, <a href="https:&#x2F;&#x2F;github.com&#x2F;billforsternz&#x2F;retro-sargon" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;billforsternz&#x2F;retro-sargon</a> . One of the side effects of the project is Sargon in real Z80 assembly language, rather than the weird 8080 hybrid it was originally coded and published in, and I am sure there will be a hard core Z80 fan or two who would appreciate that.

So if C paradigm doesn&#x27;t fit the Z80 architecture, does anyone know if there&#x27;s a language (other than Z80 assembler) that <i>does</i>. Or do Z80 enthusiasts generally just write everything in asm?

Goddammerung, I cannot find my Lisp interprete&#x2F;compiler source code for Z80. Especially from time before I constructed the external memory bank. There was nothing comparable anywhere until Turbo-Pascal came to be. It was originally Forth-like stack machine, but then I implemented another stack, the &quot;execution stack&quot;. &quot;(&quot; and and &quot;)&quot; symbols were push&#x2F;pops on that stack and thus &quot;(+ 1 2)&quot; was directly executable in my Forth. OTH in this machine the &quot;compiling&quot; was just replacing symbolic linked lists with a sequence of direct subroutine calls. <a href="https:&#x2F;&#x2F;timonoko.github.io&#x2F;Nokolisp.htm" rel="nofollow">https:&#x2F;&#x2F;timonoko.github.io&#x2F;Nokolisp.htm</a>

Nice to see this here, yes in what concerned the 8 bit world and the 16 bit home micros (PC, Amiga, Atari) C compilers just sucked.<p>Anyone that was writing code where performance mattered was using Assembly.<p>Even on 16 bit platforms, although high level languages were already quite common, in what concerns games (or demoscene), they were our &quot;Unity&quot;.<p>Good enough for prototyping, but also full of inline assembly.<p>I once saw a game submission to a Portuguese newspaper (for a MS-DOS game), which the only C that it had were data structures and function declarations, the bodies were 100% inline Assembly.<p>And by the time Pentium arrived, unless one was buying Watcom, there wasn&#x27;t a good C &#x2F; C++ compiler that could take advantage of the pipelines and instruction scheduling in a proper way, as described by Abrash books.

Well, while certainly imperfect, some like SDCC are good enough to write some games with nontrivial logic.<p>Here’s an open source game (disclosure: I wrote it) that compiles with SDCC and runs a game involving a flood fill algorithm, a tiny GUI with checkboxes and buttons and only one assembly routine, all running on the Amstrad CPC464 and above: <a href="https:&#x2F;&#x2F;github.com&#x2F;cpcitor&#x2F;color-flood-for-amstrad-cpc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cpcitor&#x2F;color-flood-for-amstrad-cpc</a><p>It’s much easier to write and much faster (and probably smaller) to run than the same in BASIC.

I think one solution would be to have another language that&#x27;s a bit more abstract than ASM maybe with some variables and register spilling and some macros, so you can write ASM more easily. That language could be transpiled into ASM, but would need to be debugged as ASM as well then, so you still need to know assembler very well.<p>I tried to do that a couple years ago with little success (readme and feature list missing, sorry but maybe you get the idea from the repo): <a href="https:&#x2F;&#x2F;github.com&#x2F;NanoWar&#x2F;FunkCompiler" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;NanoWar&#x2F;FunkCompiler</a>

They produce about as good code as can be produced for any 8-bit (accumulator size) processor (there are some 16-bit instructions for some registers). The PDP-11, for which C was designed, has a 16-bit register architecture for all registers.