Re: SDCC porting feasibility study, part 1: the assembler

So I guess the take-away I'm getting from all this is that having the
best applications running on this kind of hardware would lend itself
towards using LLVM, the best bang-for-the-buck of coding and
contributing to an existing project (with regards to the intrinsic
usefulness of the code) is probably SDCC (but in some ways this will
treat the system like a glorified microcontroller), and the most
practical and demonstratable self-supporting system would probably
lead towards TCC, but LLVM would also satisfy this very slowly on a
system with enough memory, giving at least the conceptual assurance
but without an easy way to show it off besides "come back in a few
weeks".

ACK is kind of a wildcard that might fit somewhere in-between any of
this depending on what exactly it is, but we already know it has some
issues.  It does presumably work though.

Writing our own toolchain... eech.  Might have been a neat idea back
in the 80's.

I suppose without having really dug into any of the options yet, my
tentative next move would be to look at what makes an LLVM backend.
Does such a backend include a linker?  What would be a good C library
to use with it?


Gawd, this is why I try to stick to assembler, at least then every
problem is my own fault.  Except assembler bugs (I've hit them already
with NASM running on 16 bit, rather bloated too).