Re: A C compiler written in C targeting C

dg@tao.co.uk (David Given)
1 Apr 1999 00:57:10 -0500

          From comp.compilers

Related articles
A C compiler written in C targeting C dg@tao.co.uk (1999-03-23)
Re: A C compiler written in C targeting C mikee@cetasoft.cog (1999-03-28)
Re: A C compiler written in C targeting C kadhim@lucent.com (Basim Kadhim) (1999-03-28)
Re: A C compiler written in C targeting C nshaf@intur.net (Nick Shaffner) (1999-03-28)
Re: A C compiler written in C targeting C dmk42@my-dejanews.com (1999-03-28)
Re: A C compiler written in C targeting C derek@knosof.co.uk (1999-03-28)
Re: A C compiler written in C targeting C eclectictech@usa.net (1999-03-28)
Re: A C compiler written in C targeting C dg@tao.co.uk (1999-04-01)
Re: A C compiler written in C targeting C zalman@netcom.com (1999-04-03)
Re: A C compiler written in C targeting C gillga@ilk.de (1999-05-16)
| List of all articles for this month |
From: dg@tao.co.uk (David Given)
Newsgroups: comp.compilers
Date: 1 Apr 1999 00:57:10 -0500
Organization: I'm organised? Wow!
References: 99-03-067 99-03-085
Keywords: C, architecture

mikee@cetasoft.cog (Mike Enright) writes:
[...]
> Now, the project at hand is more of a CFront-ish beast. CFront
> translated from one HLL to another HLL. gcc translates from an HLL to
> assembler, and there really is a difference between C and assembler,
> especially in its control-flow. I'd consider a translator based on an
> existing C grammar to be a better path, because you could probably
> work on switch statements as switch statements, instead of seeing them
> as "a bunch of test and jump instructions." Or, if you could get into
> the compiler at a level where, perhaps the AST still represented a
> switch statement as a switch statement, that would be reasonable.


Thank-you for all the replies I've been getting; there's a lot of good
stuff here, but they all seem to be rather heavyweight and/or
difficult to use. TenDRA looked great, but writing an installer for it
seems to be a little on the hard side. I couldn't find any decent
documentation for it, either (i.e. instructions on how to write an
installer).


I'm actually making fairly decent progress with ctree, a rather good C
parser (it was in the FAQ, which of course I read *after* I
posted...). It reads in a C file, and then emits it again through a
hacked output routine with my pointer semantic changes.


The only problem I have now is typing; ctree doesn't do type analysis,
so it doesn't know that *a = b needs to produce different code
depending on the types of a and b. I'm getting round this now by
running the result through a C++ compiler and using overloaded
functions, but that's not a particularly nice solution and I have to
generate several functions for every single type my program uses. This
produces a lot of code.


The really silly thing is that if I were using gcc, I could use
expression blocks and typeof() and everything would be great. I have
to use Borland C++ which doesn't have these.


So: anyone know of a C parser like ctree with type checking? I suppose
what I really need is a compiler front-end, with no code generation...


--
+- David Given ---------------McQ-
| Work: dg@tao-group.com
| Play: dgiven@iname.com
+- http://wired.st-and.ac.uk/~dg -





Post a followup to this message

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