From: Paul S. <pm...@gm...> - 2013-05-11 12:29:26
|
Hello, 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. This work is available in this branch: https://github.com/pfalcon/sdcc/commits/icode-output Based on that branch, there's another branch https://github.com/pfalcon/sdcc/commits/icode-input which provides (initial so far) iCode parsing support. After considering how I can add support for iCode parsing grammar, I went with the solution as described here: http://stackoverflow.com/questions/16452737/is-it-possible-to-call-one-yacc-parser-from-another-to-parse-specific-token-subs 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; int foo() { return a & b; } ======== is compiled into external iCode representation as: ======== defvar a{int fixed as=data} defvar b{int fixed as=data} defvar c{int fixed as=data} _entry: proc foo{int ( ) fixed as=code} iTemp0{int fixed as=data} = a{int fixed as=data} & b{int fixed as=data} ret iTemp0{int fixed as=data} _return: eproc foo{int ( ) fixed as=code} ======== 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?) -- Best regards, Paul mailto:pm...@gm... |