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

[Harley Laue <losinggeneration@gmail.com>]

On 02/27/2012 12:52 PM, David Given wrote:
> Brad Normand wrote:
> [...]
>> What scares me there is writing a whole toolchain isn't trivial.  In
>> college, I took a class where we wrote the most basic of basic
>> compilers in java (using a nice grammar parsing library), reading in a
>> simplified ALGOL and targeting mips and doing no optimization or real
>> register allocation at all.
> I've been doing stuff with compilers for years (ask me about my C to
> Perl compiler!), and this is so true. C compilation is painful. Doing C
> compilation *well* is a life's work. You *seriously* don't want to write
> one from scratch.
My thoughts exactly. I have to admit that I actually laughed a bit when 
it was suggested.
> If you want to do an 8086 C compiler, I'd strongly recommend looking at
> LLVM --- it's apparently got a really nice backend model, although the
> documentation isn't brilliant. Better still, it may be possible to start
> with the excellent 386 backend and cut it down, which should be a much
> easier job than building one from scratch.
I said this before and I'll say it again, I think SDCC or LLVM will 
likely be the best options to look into. The advantage SDCC has is that 
the retarget would likely be accepted upstream where-as the 8086 target 
for LLVM would live on its own (not necessarily a bad thing.)
> Other compiler backends I know about:
>
> - gcc: unspeakable.
>
> - Sparse: the engine behind the Linux kernel linter, which I used for
> the above C to scripting engine compiler. It's not really intended as a
> code generator but actually does a reasonable job.
>
> - vbcc: I did a Z-machine backend for this; it's got a very nice
> architecture, and is simple to work with and produces reasonable code,
> but has a painful source-available-but-not-open-source license.
>
> - the ACK: has the advantage of being a complete turnkey toolchain and
> compiler, including assembler, linker, librarian, libc, etc, *and* it
> already supports the 8086, but doesn't produce great code and is tough
> to work on.
I was barely able to even get this one to compile on my host machine. It 
seems they don't have very good support for 64bit Linux. Once it was 
compiled the ack command (for instance) had no usage help message as far 
as I could tell. Overall, it didn't leave a very good taste in my mouth.
>
> - tcc: very very very fast. Produces very very very crap code. It
> started life as an IOCCC entry, and boy does it show.
>
> Then there's TenDRA, which I've never had anything to do with but which
> seems to have vanished. And there are C and C++ parsing libraries like
> Elkhound which I've tried to look at but have been unable to get started
> with.
>