Re: Need an interesting topic for an undergraduate project on Compilers

On 8/31/2011 10:41 AM, BGB wrote:
> On 8/27/2011 8:30 AM, Joe keane wrote:
>> Volker Birk<bumens@dingens.org> writes:
>>> If you want to compile a programming language to assembler code
>>
>> I'm not sure why anyone would want to do this; if you have another
>> language you can convert it to C code, and concentrate on what you are
>> doing. If you find that the C->assembly step can be improved that is
>> also useful.
>
> there are a few drawbacks to compiling to C though:
> one can only compile to C in contexts where they have a C compiler,
> which largely rules out things like JIT compilers;
> the time-to-comile may be somewhat worse (in cases where this is important);
> some language features are difficult to implement effectively in C (and
> standard C is annoyingly lacking in reflection features);
> ...
>
> so, it is not so clear-cut that one wouldn't want to compiler to ASM (or
> to some bytecode, which is run through a JIT).


> [Do you mean compiling to assembler, or compiling to machine code? They're
> different. -John]


ok, fair enough...


pardon my very ambiguous/imprecise wording...




in my project, I first compile to ASM, and then feed this though an
in-program assembler, and feed the output from this into an in-program
linker (links the code against/into the running program image).


in this case, one produces assembly code, and gets machine code.


in my brevity I had sort of glossed over this detail.




notably though, the size, complexity, and performance overhead of an
assembler is generally small enough that one can ignore that this stage
exists.


mine can (depending on settings and usage patter), pull off assembling
up to around 10-20MB/s of ASM code on an AthlonII at 2.8GHz. in
practice, this is likely more than enough to be needed for most cases.




OTOH, a C compiler can be a good deal more expensive than an assembler,
both in terms of size and implementation complexity, and in terms of
performance (what may take, say, 10ms to compile/assemble directly,
could take several seconds or more to compile in a C compiler).


also, where the assembler may need very little memory for internal
state, whereas a C compiler may end up including several MB worth of
header contents, and use up many 10s of MB worth of memory (parsed
header contents and internal structures, ...).




these (among many other reasons) were why I eventually came to the
opinion that while C is fairly good as a statically compiled language,
it is not nearly so good of a choice as a scripting language. and isn't
really as-is suitable for interactive entry (by the time one has
interactive entry, the language is no longer strictly C either).


using it as the intermediate form for another scripting language would
likely be a good deal worse.




yes, I am ignoring here the possibility of invoking GCC or MSVC via
"system();" or similar, and fetching/loading the results, which is a
fairly simple option, but it is problematic due to both target
portability issues, requiring the compiler to be available and in the
path (a much bigger issue on Windows), and still does really not really
address the "time to compile" issue.




but, as noted, if one just wants to statically compile something, and
has no good reason to worry about compiler performance, well then, using
C as an IL makes a fair amount of sense.




there is also LLVM/Clang, but I haven't really messed with it enough to
really provide an accurate opinion on it (I don't personally use it, as
there isn't really a whole lot in common between my projects and LLVM,
technically or goal-wise).

Return to the comp.compilers page.
Search the comp.compilers archives again.