At 6:33 PM +0000 1/8/09, Hendrik Boom wrote:
>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, too, have wished for the more general alignment semantics that
Hendrik proposes.
Note that, if the alignment modulus is restricted to be a power of
two (as it usually is, in my experience), then the modulus and
remainder can be combined (by simple addition) into a single
(machine-word-width) integer. Separating them back out involves
locating the highest-order "one" bit. To me, this representation has
a cute sort of low-level elegance, as it uses all the values of a
machine integer, excepting zero.
>
>>
>> > 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
