FYI for people who may be interested in using LLVM with 8-bit CPUs.
Begin forwarded message:
Date: Sat, 11 May 2013 15:29:12 +0300
From: Paul Sokolovsky
To: [hidden email] Subject: Accepting iCode as input to SDCC
I'm interested to make SDCC accept iCode (its own intermediate
representation) as an input format. The motivation being taking
intermediate format from other compilers' frontends, which support more
languages and have better high-level optimizations, convert to iCode
and feed to SDCC for codegeneration to 8-bit microcontrollers.
The target I specifically have in mind is LLVM IR and C++. I did
initial comparison of LLVM IR and iCode and they appear to share same
level of concepts, the biggest difference I've seen so far is that LLVM
IR is SSA form, while iCode is not. I'm sure there're lots of
devils-in-details, bit I was satisfied with a quickly put Python script
to convert trivial LLVM IR program to iCode, so I proceeded with
looking how to feed iCode into SDCC in the first place.
Well, before talking about taking iCode format as an input, first iCode
format should be defined. So far, iCode is just internal SDCC data
structure, with some adhoc and verbose dumps available for that
internal structure. Actually, it's not even possible to produce iCode
for *input* C program, because even --dumpraw starts dumping after some
code transformations are started.
So, my initial steps were to add --emit-i-code switch to dump iCode
directly after construction from AST, and then try to define "external
representation" of iCode and add dumping support for it, while leaving
existing "debugging representation" mostly intact.
icode-input branch is largely work in progress, what I achieved so far
is that compiling trivial C code to iCode, and then recompiling to iCode
again produces matching output iCode's and asm's. As an example,
int a, b, c;
return a & b;
is compiled into external iCode representation as:
I would target this work to be submitted upstream, so would appreciate
comments on the idea, approach, and early implementation available so
far. Please note that branches above will be rebased as I'm striving to
provide clean patchset. (Btw, did you guys consider switching to git?)