> 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.
It's a nice idea, but our complexity budget is already quite high.
If you're interested in nonzero remainders, perhaps you should manage
every byte yourself? Before considering such an addition to C--,
I'd want to see some convincing use cases.
N.B. The align directive exists to begin with because almost all
hardware militates toward remainder 0 mod N for loads of size N.
I'm unaware of a similar justification for nonzero remainders.
> 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.
You must then plan to extend this scheme to dynamic memory allocation
as well.
> 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.
As we learned to our sorrow---I worked for IBM during the transition
from 370 to 370-XA. It cost IBM many millions to eliminate this
particular quirk of the hardware.
> 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.
If I extrapolate, it seems as if you're really asking for a full-blown
1960's style assembler, with all the powerful facilities for laying
out memory that such assemblers used to provide. What Digital (I think)
called ".org" would probably suit most of your needs. Today's tools
are very much grounded in the 64K PDP-11, with a corresponding loss of
expressive power.
> 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.
What C-- provides, like all assemblers, is a way of reserving and
initializing memory and a way of defining labels. It looks like you
want something else, but I'm not willing to throw features at the
existing design. On the other hand, I'd be happy to entertain a full,
complete, and coherent proposal. If you write the manual, we can
probably build it for you.
Norman
_______________________________________________
Cminusminus mailing list
[email protected]
https://cminusminus.org/mailman/listinfo/cminusminus
