Re: A C compiler written in C targeting C

On 23 Mar 1999 00:31:55 -0500, dg@tao.co.uk (David Given) wrote:
>I have an operating system with strange memory semantics (GEOS, if
>you're interested). Blocks of memory may move at any time unless
>locked down. You're not supposed to leave blocks locked. You refer to
>blocks by their handles.


Just like Win16 and MacOS. Not THAT strange.


>So, to read from memory, you lock the handle, which gives you a
>pointer; dereference the pointer; and then unlock the handle again.
>
>This all works very nicely except that standard ANSI C programs won't
>run, because they expect fixed blocks of memory.
>
><snipped description of using a full C compiler to generate C code
><that uses handles
>
>[MacOS does sort of the same thing, maybe there's some hackery there. -John]


Historically both MacOS and Win16 programmers have simply called
functions that returned handles, and bracketed their pointer
dereferences with locking and unlocking. There was no hackery in the
compiler to support handles.


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.

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