Re: Pros and cons of high-level intermediate languages

kanze@us-es.sel.de
Tue, 4 Aug 1992 13:39:36 GMT

          From comp.compilers

Related articles
[18 earlier articles]
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-07-27)
Re: Pros and cons of high-level intermediate languages gat@forsight.jpl.nasa.gov (1992-07-29)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-30)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-07-30)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-08-02)
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-08-04)
Re: Pros and cons of high-level intermediate languages kanze@us-es.sel.de (1992-08-04)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-08-03)
Re: Pros and cons of high-level intermediate languages rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-08-04)
Re: Pros and cons of high-level intermediate languages optima!kwalker@cs.arizona.edu (1992-08-04)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-04)
Re: Pros and cons of high-level intermediate languages nfsun!gchamber@uunet.UU.NET (1992-08-04)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-08-05)
[3 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: kanze@us-es.sel.de
Organization: Compilers Central
Date: Tue, 4 Aug 1992 13:39:36 GMT
References: 92-08-004
Keywords: storage, optimize

Graham Matthews writes:
|> (Eliot Moss) writes:
|> >Suppose we have something like the following code:
|> > int *p, *q;
|> > int i;
|> > for (i = 0; i < 100; i++)
|> > p[i] = q[i];
|> >[C can promote p or q to a register and fail if the garbage collector
|> >moves the data that one of them points to]
|>
|> [generate this C code instead:]
|>
|> for( i = 0; i < 100; i++ )
|> object_access(p)[i] = object_access(q)[i];
|>
|> where object_access() is a function returning a pointer to the storage
|> space for the array. The C compiler will not optimise this code (you may
|> have problems with global inter-procedural optimisations here but you can
|> usually turn them off).


Why do you need to call a function?


If garbage collection is present, I would implement pointers as a
struct, so:


        struct HilevelPtr
        {
                void * ptr ;
                struct HilevelPtr * next ;
        } ;


You pay a time penalty on creation, as you have to chain the pointer into
the list, but it provides a simple solution to the problem of finding all
of the pointers. (A double linked list might be better if things go out
of existance in a random order.) I have been experimenting with something
like this as a C++ class, but have not had the time to really get anything
working.


Note that the C compiler may very well optimize the pointer into a
register, even with this. If garbage collection is only triggered by
internal events (memory allocation, etc.) in the generated program (or its
associated libraries), the compiler should know how to cope. (If not,
this is a compiler bug.) If, on the other hand, garbage collection may
come and modify the pointer in an asynchronous manner (say from a timer
interrupt), then neither calling a sub-routine, nor using the volatile
keyword will help.


(Can any language accept garbage collection at a totally arbitrary point
without special hardware support? At a machine level, on most machines,
the pointer will be loaded into a register to dereference it. If the
garbage collection is somehow activated between the load of the pointer,
and its use, the pointer in the register will no longer be valid at the
time of the access.)
--
James Kanze GABI Software, Sarl.
email: kanze@us-es.sel.de 8 rue du Faisan
                                                                        67000 Strasbourg
                                                                        France
[Some languages have conventions that some registers always contain pointers
and other registers never do, so pointer registers are fixed up if a GC
happens at an inconvenient point. Or one could use a GC that doesn't move
stuff. -John]
--


Post a followup to this message

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