RE: Zero_Fill pragma, other proposition

RE: Zero_Fill pragma, other proposition

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Nick Roberts [mailto:nick.roberts@acm.org]
..
|     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;
 
Its a better syntax, as it doens't require a field name, but the "all" does
not fit well with random value.

So why not directly a numeric literal?
 
for Message use record
   Id           at 0 range 0 .. 7;
   2#1011_1010# at 0 range 8 .. 15;
   Data         at 0 range 16 .. 65;
end record;

That's pretty clear, isn't it?

-- 
Lionel Draghi

RE: Zero_Fill pragma, other proposition

[Lionel.DRAGHI]

| -----Message d'origine-----
...
| > 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;
| >
...........................................................
| package P is
|    type Message is record
|       Id   : Message_ID;
|       Data : Byte_Stream;
|    end record;
| 
|    -- Primitive operations of Message go here
| private
|    type Representation is record
|       Id    : Message_ID;
|       Spare : Eight_Bits;
|       Data  : Byte_Stream;
|    end record;
| 
|    for Representation use record
|       Id    at 0 range 0 .. 7;
|       Spare at 0 range 8 .. 15;
|       Data  at 0 range 16 .. 65;
|    end record;
|    
|    function To_Rep (M : in Message) return Representation;
|    function To_Message (R : in Representation) return Message;
| end P;
| 
| 
| package body P is
|    function To_Rep (M : in Message) return Representation is
|    begin
|       return (Id => M.Id, Spare => 0, Data => R.Data);
|    end To_Rep;
| 
|    function To_Message (R : in Representation) return Message is
|    begin
|       return (Id => R.Id, Data => R.Data);
|    end To_Message;
| 
|    -- Primitive operations of Message convert to 
| Representation whenever
|    -- interfacing to hardware
| end P;
| 
| I realise that your proposal reduces the amount of work required to
| achieve this, but the current language does allow you to do what you
| want.
Yes, and the problem is not so common.
 
On the other hand:
- even on this small example, there is a big difference in required work
(about 1 line vs 20), and a body is required, 
- it betters representation details encapsulation,
- it's not a big deal to implement... OK, I don't know about this, but I
bet!

-- 
Lionel Draghi

RE: Zero_Fill pragma, other proposition

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Jean-Pierre Rosen [mailto:rosen@adalog.fr]
...
| OTOH, I suspect that very few types would need
| that pragma (as you describe, a couple of types very strongly 
| connected to hardware), so writing more fields is not really a
| problem.
In our case, it's a common problem : we have lots of messages with spare
fields, and setting them to 0 for out going messages is a requirement.
(On the other hand, even without this requirement, it would ease regression
testing.
Simple regression test tools based on diff raise false alarm because spare
fields may be whatever on each run).

So, our current policy is to explicitly state each spare. I don't feel
confortable with this because the low level representation emerge in the
definition.
I don't want users to access the spare fields.
I don't event want users to see the spare fields.

What could be a good deal is to allows spare fields to appear in the
representation clause.

Kind of :

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;

This way, representation stuff don't emerge in the "user's" view, but spares
are explicit in the "coder's" view.

-- 
Lionel Draghi

Re: Zero_Fill pragma, other proposition

[Ludovic Brenta]

Lionel Draghi writes:
> | De: Jean-Pierre Rosen ...
> | OTOH, I suspect that very few types would need
> | that pragma (as you describe, a couple of types very strongly 
> | connected to hardware), so writing more fields is not really a
> | problem.
> In our case, it's a common problem : we have lots of messages with spare
> fields, and setting them to 0 for out going messages is a requirement.
> (On the other hand, even without this requirement, it would ease regression
> testing.
> Simple regression test tools based on diff raise false alarm because spare
> fields may be whatever on each run).
>
> So, our current policy is to explicitly state each spare. I don't feel
> confortable with this because the low level representation emerge in the
> definition.
> I don't want users to access the spare fields.
> I don't event want users to see the spare fields.
>
> What could be a good deal is to allows spare fields to appear in the
> representation clause.
>
> Kind of :
>
> 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;
>
> This way, representation stuff don't emerge in the "user's" view,
> but spares are explicit in the "coder's" view.

Even though I like your proposal, I'm not sure that a new language
construct is required.  You can use encapsulation to prevent users
from seeing the spare fields, like this:

package P is
   type Message is record
      Id   : Message_ID;
      Data : Byte_Stream;
   end record;

   -- Primitive operations of Message go here
private
   type Representation is record
      Id    : Message_ID;
      Spare : Eight_Bits;
      Data  : Byte_Stream;
   end record;

   for Representation use record
      Id    at 0 range 0 .. 7;
      Spare at 0 range 8 .. 15;
      Data  at 0 range 16 .. 65;
   end record;
   
   function To_Rep (M : in Message) return Representation;
   function To_Message (R : in Representation) return Message;
end P;


package body P is
   function To_Rep (M : in Message) return Representation is
   begin
      return (Id => M.Id, Spare => 0, Data => R.Data);
   end To_Rep;

   function To_Message (R : in Representation) return Message is
   begin
      return (Id => R.Id, Data => R.Data);
   end To_Message;

   -- Primitive operations of Message convert to Representation whenever
   -- interfacing to hardware
end P;

I realise that your proposal reduces the amount of work required to
achieve this, but the current language does allow you to do what you
want.

-- 
Ludovic Brenta.

Re: Zero_Fill pragma, other proposition

[Nick Roberts]

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

Re: Zero_Fill pragma, other proposition

[Wes Groleau]

Lionel.DRAGHI@fr.thalesgroup.com wrote:
> I don't want users to access the spare fields.
> I don't event want users to see the spare fields.

Good choice.  I can imagine some cowboy writing

   -- maintain my miracle worker reputation ....
   Message.Spare := My_Secret_Data;

and on the other side

   -- they'll never figure out how I made this work
   Contraband := Message.Spare;


-- 
Wes Groleau
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^  A UNIX signature isn't a return address, it's the ASCII equivalent ^
^  of a black velvet clown painting.  It's a rectangle of carets      ^
^  surrounding a quote from a literary giant of weeniedom like        ^
^  Heinlein or Dr. Who.                                               ^
^                                -- Chris Maeda                       ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^