On Wed, 07 Jan 2009 21:13:12 -0500, Norman Ramsey wrote:
>> Is it true that the only types on C-- are the bits8, bits16, etc., up
>> to
> > some small limit? (although they may be given new names by a type
> > definition)
> >
> > That it recognises nothing like C's structs and unions and so forth,
> > and that that is entirely the job of the front end, which will likely
> > be generating code containing a lot of numerical constants for field
> > offsets and the like?
>
> Yes, that's exactly right.
Good. I've already started rewriting a code generator based on that
assumption. I think it's the right design, unless you are striving for
truly machine-independent intermediate code. It's easier to calculate
with integers than with symbolic expressions in the front-end code
generator. And most back-end designs lack the operations you might want
for calculating storage allocations.
Still, there's one or two things in this vein I miss. First, a
recognition that an alignment is not just a modulus, but a modulus and a
remainder. This the 'align' datum should provide the next location whose
address yields a particular remainder when divided by the mudulus.
I prefer to treat the shape of a type as a size, a modulus, and a
remainder. It gives better space consumption on types like struct{byte,
float, byte}. Assuming one-byte alignment for byte, and four-byte
alignment for float, this can be packed into 6 bytes quite comfortably,
with the structure's alignment being 3 mod 4.
Even hardware has this kind of constraint. The ancient IBM 360 has 24-
bit addresses, and the alignment of an address was 1 mod 4. The OSes on
that system made heavy uise of the fact; OS data structures often stuck
other data in what would have been the high-order byte of a 32-bit
address.
The other thing I miss is the ability to explicitly specify positioning
of values in a data segment, be it on the stack or not. Something like
foo: int16;
foo+3: int 8;
I could even imagine
align 1 mod 4;
foo-1: int8;
foo: addr;
foo addr;
for a Lisp cell prefixed with an extra byte indicating its type.
This is probably the wrong syntax. The same could be done with compile-
time calculation of suitable padding, but it feels like dead reckoning
to me, hoping that the front and back end are perfectly in sync.
-- hendrik
_______________________________________________
Cminusminus mailing list
[email protected]
https://cminusminus.org/mailman/listinfo/cminusminus
