Re: Zero_Fill pragma, other proposition

["Nick Roberts" <nick.roberts@acm.org>]

On Wed, 21 Jul 2004 11:20:32 +0200, <Lionel.DRAGHI@fr.thalesgroup.com>  
wrote:

> type Message is record
>    Id   : Message_Id;
>    Data : Byte_Stream;
> end record;
>
> for Message use record
>    Id    at 0 range 0 .. 7;
>    Spare at 0 range 8 .. 15 := 0; --> ADDED
>    Data  at 0 range 16 .. 65;
> end record;

A slight variation on this idea is:

    type Message is record
       Id   : Message_Id;
       Data : Byte_Stream;
    end record;

    for Message use record
       Id    at 0 range 0 .. 7;
       all 0 at 0 range 8 .. 15;
       Data  at 0 range 16 .. 65;
    end record;

However, this requires a change to the language syntax. I'm sure that it  
is too late to make any such drastic proposals for the Amendment now. It  
might also be argued that this syntax confuses record layout issues with  
initialisation issues (but I think that would be too finicky).

I had intended to implement a Zero_Fill pragma for the AdaOS compiler  
(ECLAT), regardless of whether this pragma were accepted for the  
Amendment. It would then be an implementation defined pragma, and not in  
violation of the standard.

I must add, if we are going to suggest alterations to the record  
representation clause, there are at a couple of other things it would be  
'nice to have'.

Quite often a single scalar component is broken into two or more pieces in  
a machine representation; it would be nice to have a way to tell the  
compiler where these pieces are, and to stitch them together when reading  
the component and split them up when updating it. A good example is the  
32-bit segment descriptor layout of the IA-32, where the offset field is  
broken into three separate pieces.

Quite often a component fits exactly into one storage element. It is then  
pointless (if harmless) to have to express the 'range ...' part.

For example:

    -- assuming System.Storage_Unit = 16

    type Call_Gate_Descriptor is
       record
          Num_Param:  Parameter_Count;
          DPL:        Privilege_Level;
          Present:    Boolean;
          Segment:    Selector_Number;
          Offset:     Offset_32;
       end record;

    type Call_Gate_Descriptor is
       record
          Num_Param   at 2 range  0 ..  4;
          all 0       at 2 range  5 ..  9;
          all 1       at 2 range 10 .. 11;
          all 0       at 2 range 12 .. 12;
          DPL         at 2 range 13 .. 14;
          Present     at 2 range 15 .. 15;
          Segment     at 1 range  0 .. 15;
          Offset     (range  0 .. 15 => at 0 range 0 .. 15,
                      range 16 .. 31 => at 3 range 0 .. 15);
       end record;

    for Call_Gate_Descriptor'Size use 64;

This is, of course, a realistic example (taken from the IA-32). Assuming a  
storage element is 16 bits, it would be nice if the three occurrances of  
"range  0 .. 15" in this example could be omitted.

I rather cheekily feel that I could get away with putting these extensions  
into the compiler, since they are compatible with standard Ada, and I  
can't see anyone actually complaining (unless they write something in  
ECLAT and then try to port it).

I feel this is the sort of facility that some Ada compilers should  
support. I can see that imposing it on all compilers is likely to be seen  
as draconian. It is said that the Ada 95 revision is what put the final  
nail in the coffin of DEC Ada.

The above doesn't solve the problem of telling the compiler to zero out  
the gaps between components in an array.

-- 
Nick Roberts