Re: Ada Portability... NOT!

[kst@alsys.com (Keith Thompson)]

In <3alalm$9di@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
> It is probably a reasonable implementation choice to restrict reals to be
> on a properly aligned boundary, since it is an annoying amount of fiddling
> to deal with unaligned floating-point stuff, and yes, of course most 
> processors *do* require floating-point values to be aligned. When you use
> rep clauses you are definitely wandering into the area of implementation
> dependent non-portable constructs (most appropriately, since one of the
> functions of rep clauses is to deal with special target dependent
> requirements).
> 
> There is certainly no *requirement* that an implementation reject these
> declarations on a RISC machine, the code generator could generate the
> code to fiddle around and copy the value. Is it a good idea to do this
> behind the scenes? Not clear. Suppose a user just casually wrote rep
> clauses to pack the data in a way that worked fine on one machine but
> generated long inefficient sequences of code on another, do you want
> to be allowed or stopped? Either answer is possible.

I've just thought of a couple of ways an implementation could handle
this that might have some chance of satisfying everybody.

1. By default, provide a "reasonable" level of support for representation
   clauses.  For example, one might allow a floating-point component
   to be aligned on any boundary that allows it to be accessed with a
   single instruction (4 or 8 bytes).  Alignments that require fancier
   access code (e.g,. loading the value a byte at a time into a register
   or using bit-shifting) would be rejected -- unless a special pragma is
   given to allow it.  It occurs to me that such a pragma already exists:
   pragma Pack.

   For example:

      type Rec1 is
	 record
	    ...
	    F: Float;
	 end record;
      for Rec1 use
	 record
	    ...
	    F at 1 range 0 .. Float'Size - 1;	-- byte-aligned, rejected
	 end record;

      type Rec2 is
	 record
	    ...
	    F: Float;
	 end record;
      pragma Pack(Rec2);			-- permit tighter packing
      for Rec2 use
	 record
	    ...
	    F at 1 range 0 .. Float'Size - 1;	-- byte-aligned, permitted
	 end record;

   One could argue that this is an abuse of the semantics of pragma Pack,
   but I *think* the current definition is vague enough to allow it.

2. Similar to the above, but the compiler issues a warning (or
   informational message) for representations that require fancy
   access code.  The addition of a pragma Pack might suppress the
   warning message, reduce its severity from warning to informational,
   or whatever.

I don't know of any existing compiler that does this, including ones
I've worked on.

I've also often thought it would be nice if pragma Pack took an optional
second argument to specify how enthusiastically the compiler should
perform packing.  For example, pragma Pack(Some_Type) might ask the
compiler to pack to byte alignment, while pragma Pack(Some_Type, Dammit),
might ask it to pack to bit alignment.  (Note that an implementation
may not legally add arguments to an existing language-defined pragma.)

Whaddya think?

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)