Re: A C compiler written in C targeting C (Peter W. Gillgasch)
16 May 1999 15:31:11 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: A C compiler written in C targeting C (Nick Shaffner) (1999-03-28)
Re: A C compiler written in C targeting C (1999-03-28)
Re: A C compiler written in C targeting C (1999-03-28)
Re: A C compiler written in C targeting C (1999-03-28)
Re: A C compiler written in C targeting C (1999-04-01)
Re: A C compiler written in C targeting C (1999-04-03)
Re: A C compiler written in C targeting C (1999-05-16)
| List of all articles for this month |

From: (Peter W. Gillgasch)
Newsgroups: comp.compilers
Date: 16 May 1999 15:31:11 -0400
Organization: Metal Goth Hippies Adrenaline Logic
References: 99-03-067
Keywords: C, storage, design

David Given <> wrote:

> Yes, I know it's an odd request.
> 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.
> 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.
> What I want to do is write a C compiler that changes the pointer
> semantics of the program, emitting another program that I can feed
> into GEOS' odd C compiler.
> I'm currently playing with lcc, and have a fair amount of success; I
> have a back end that generates more-or-less correct C code, and
> pointer dereferences are correctly wrapped, but the output code is
> still going to be dire. I can't get lcc to let me handle switch
> statements, for example, and since I can't use jump tables it's going
> to produce a sequence of if...goto pairs.
> Are there any compilers (lcc, gcc) around that have C back ends? Are
> there any type analysis tools around that can be modified to write out
> the code once they've read it in (because I don't need a fully fledged
> code generator)? Am I going at this in completely the wrong way?


I have read the answers that you were getting and I feel that
either I grossly misinterpret your problem or all answers I read
so far are missing the point completely.

It is my understanding that GEOS allocates by default handles but
you can lock and unlock them manually via documented API calls.

As I said, I may grossly misunderstand the problem, but all you
need to do is to replace the OS specific memory request and release
routines in your __standard library__ along the lines of:

char * __get_memory_from_os(long inBytes)
    char ** myHandle = NULL;
    char * myResult = NULL;
  if (inBytes > 0) {
      myHandle = GEOS_AllocHandle(inBytes);
  if (myHandle) {
      int myOSErr = GEOS_Lock(myHandle);
      if (myOSErr = noErr)
          myResult = * myHandle;
  return myResult;

(this assumes that your malloc/free implementation requests large
pools of memory from the OS and serves incoming requests by allocating
and freeing space in __that__ pools, like it is usually done on the
MacOS and most unix memory allocation libraries I am aware of).

The only problem I can see if GEOS (or you ;) wants/needs explicit
GEOS calls to release allocated handles at program termination.
In that case, you need to keep track of the handle base addresses
of the allocated memory pools, which is fairly easy (one handle
of a vector of handle base addresses for the pools is needed then).

In any case I don't see why any 'C' program should then need
modification on your target or why something like a "normal 'C'"
to "handle based 'C'" compiler is required.

Sounds a lot of easier than what you originally wanted to pull off 8^)

Of course, I could have misinterpreted your problem...


-- Peter (among other things a MacOS programmer 8^)

Post a followup to this message

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