On Thu, 08 Jan 2009 12:46:50 -0500, Norman Ramsey wrote:
>> 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.
I'm quite aware of the need to not implement things, believe me. I
suspect you'll find that having a remainder on 'align' is orthogonal to
everything else. I could be wrong, but it seems to be orthogonal in the
systems I've built.
Aside from the conceptual integrity of the nice idea, the question is
whether the extra effort is worth the occasional few bytes saved. That
depends on whether the saved bytes are replicated massively at run time,
about which I have few statistics.
> If
> you're interested in nonzero remainders, perhaps you should manage every
> byte yourself?
Of course, Except there will be a few bytes lost at the start of a data
or stack segment because I can't specify the detailed alignment at the
start of the segment -- or any place where I may have lost track of the
current alignment. In any case, managing the bytes myself does end up
being what I'm doing anyway for other reasons.
> 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.
And N is usually a power of two.
>
> > 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.
of course. But if you want to build this on top of, say, malloc, you
allocate a bit more than needed. memory block overhead is already bigger
than most alignment wastage, so it's probably not worth worrying about it
on a per-allocation basis. But the savings can be substantial when we're
talking about arrays -- arays of oddly aligned structs can often be
stored a lot smaller than C is able to pack them -- with no additional
run-time access cost.
> > 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.
I always wondered how they maintained any kind of binary compatibility
with this transition.
>
> > 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.
I've done this in a Lisp system a long time ago. I never noticed any
help from the assembler.
> 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.
This isn't a big item on my wish list; it *is* possible to keep the front
and back ends in sync, after all. But I do have experience with dead
reckoning being bug-prone, and prefer to avoid it if possible. Sometimes
it isn't.
-- hendrik
_______________________________________________
Cminusminus mailing list
[email protected]
https://cminusminus.org/mailman/listinfo/cminusminus
