|Compiling records by treating them as collections of variables email@example.com (1996-02-21)|
|Re: Compiling records by treating them as collections of variables cwilson@Xenon.Stanford.EDU (1996-02-23)|
|Compiling records by treating them as collections of variables firstname.lastname@example.org (Dave Lloyd) (1996-02-23)|
|From:||Dave Lloyd <email@example.com>|
|Date:||23 Feb 1996 18:22:58 -0500|
> Does anyone know of a compiler, which would treat records simply as
> syntactic sugar for a collection of variables? ....
One of the design decisions early in our compiler was just
such. Primarily because we expected programmers to use the highly
structured facilities available in the language (Algol 68), in
particular using a single structure rather than a dust of scalar
variables. One of our prime goals is to compile high-level constructs
as efficiently as low-level constructs so that the programmer need no
fear great inefficiency just from writing the program in a clean and
As well as structured datatypes, some of the type constructors in
Algol 68 need to be represented by a descriptor (arrays, unions and
procedures) and efficient handling of array descriptors in particular
is vital for Algol and Fortran code.
This method can produce very nice code - in particular no special
handling is needed for complex arithmetic, e.g.,
COMPL z = CONJ (3 I 4) * (4 I 0)
COMPL z = (12 I -4)
just by expanding the complex operators and letting the constant
folding on reals do the job. It is also occasionally neat to see some
fields within a structure stacked, while others survive in registers
and others never exist ('cos you never got round to referring to
I warn you that the management of all this can get quite hairy because
while it suffices to treat a structure as a collection of scalars in
operations when a single field has been selected, if the structure is
to be passed to a procedure or pointed to by a reference the compiler
must fall back and stack the lot if it wants a pointer to the
structure as a whole.
One of my decisions with which I was never entirely satisfied was
whether the internal representation should preserve the hierarchical
structure - we flatten everything to one long record of scalars. This
has advantages in some places but also proves awkward in others. We
also give each record a 'cover' which represents the virtual block
that the structure spans and this is what is used when the structure
is manipulated as an encapsulated block.
But I don't think I would do this as a source or construct-tree
transformation. This technique needs (or at least greatly benefits
from) feedback from the code-generator.
One day soon we shall do the same for array elements (at least those
derived from fixed length row-displays or similar sources).
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
Return to the
Search the comp.compilers archives again.