ANSI alignment discussion 
Author Message
 ANSI alignment discussion

I don't know if this has been discussed as of yet but I have gotten requests
from people to be able to align different sized objects to different boundries
for some machines.  For example: chars -- 1 byte boundry, shorts -- 2 bytes,
longs 4 bytes,  double longs 8 byte boundries, etc...  I do not remember
the machine that required this but I could even see some advantages in
using it for machines that didn't (i.e. i[3-4]86's not allowing 32 bit
ints to straddle 4 byte addresses thus requiring an extra bus cycle).

Had the TC considered passing a parameter to ALIGN that is the size of
the object to be aligned.  It could easily be ignored for those who didn't
need it but it might be a lifesaver for those who do (or at least a memory
saver by not having to align everything to the largest possible boundry).

Anyone have any feedback on this?

Thanks,

-Kevin

-------
There are no complex problems; only complex solutions!
-------
Bureaucracy:  The process of turning energy into solid waste.



Thu, 26 Oct 1995 03:05:25 GMT  
 ANSI alignment discussion
Kevin Haddock asks if alignment of different sized objects has been
discussed and considered by the TC.

The current dpANS contains an alignment operator for each fundamental
data type upon which operations are defined; specifically, cells,
floating, and double floating via ALIGN, FALIGN, and DFALIGN.  The
reason for including these was to pemit the defined operators on these
storage types to be implemented efficiently on hardware where alignment

be a way in which applications can guarantee that such addresses will
be available.  This is a *compelling* need for such a word... without
it there would be serious problems.

CALIGN is absent because no one was able to present a plausible
scenario in which it would actually be necessary, i.e. in which
the tradeoffs would justify cluttering programs up with it.

The other data types mentioned such as "short" (Half?) and
"double long" have no intrinsic meaning either within the context
of the dpANS or within the context of hardware in general.  Since
any dependency on such data types would be a creation of the application,
it is perfectly reasonable for the application to supply any further
alignment operators for its special data types.

Applications compliant with dpANS may still do address arithmetic,
after all, so alignment operators of that sort are certainly OK.

    Greg Bailey    |  ATHENA Programming, Inc  |  503-621-3215  |
  ---------------  |  24680 NW Dixie Mtn Road  |  fax 621-3954  |



Thu, 26 Oct 1995 08:42:02 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Discussion Notes from 9/92 ANSI meeting

2. Discussion notes from ANSI meeting 11

3. Espace de discussion Python francophone / French speaking place for Python discussions

4. OEM to ANSI / ANSI to OEM function

5. Most ANSI Critics Haven't Read and Used ANSI Documents

6. Most ANSI Critics Haven't Read and Used ANSI Documents

7. Most ANSI Critics Haven't Read and Used ANSI Documents

8. Ansi-74 and Ansi-85

9. TextEdit right alignment...

10. TextEdit alignment and DateToText yearPivot

11. instruction alignment and DIAG

12. Filling the spaces and retain original characters alignment

 

 
Powered by phpBB® Forum Software