Zero_Fill pragma

Zero_Fill pragma

[Nick Roberts]

Am I too late to make a proposal for a new pragma for
the Ada 2005 Amendment?

It would have the syntax:

    pragma Zero_Fill(simple_name);

It would be applicable to an object or a subtype, and it
would operate on all objects of the given subtype, or on
the given object. The object must be of a composite type.

It would have the effect of causing all the bits in the
object which are unused to have a default initialisation
of 0.

I think the definition of 'in the object' would be any
bit numbered 0 to n-1, where n is the object's size (as
the Size attribute would report).

I think the definition of 'unused' would be any bit
which is not in any of the object's components. If the
place of the component is defined by a record
representation clause, that will define the bits used
by the component, otherwise the bits used by a component
will be chosen by the compiler.

For records, the effect can be achieved by introducing
'dummy' components, but this is a pain and can degrade
readability. For arrays, the effect cannot be achieved
by standard means (other than perhaps adding components
to the array's component subtype, if it is a record
subtype, to bulk the record up to the size of an
integral number of allocation units, and then using
pragma Pack).

Either way, I think the pragma would be useful in real
programs, and that it would be useful for the pragma to
be defined by the language standard. I'm a little
surprised existing compilers don't provide something
like this.

-- 
Nick Roberts

RE: Zero_Fill pragma

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Nick Roberts [mailto:nick.roberts@acm.org]
...
| Am I too late to make a proposal for a new pragma for
| the Ada 2005 Amendment?
| 
| It would have the syntax:
| 
|     pragma Zero_Fill(simple_name);
...
| It would have the effect of causing all the bits in the
| object which are unused to have a default initialisation
| of 0.

I agree, this would be of immediate use here.

-- 
Lionel Draghi         http://webshop.ffii.org/

Re: Zero_Fill pragma

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]


"Nick Roberts" <nick.roberts@acm.org> a �crit dans le message de news:opsbf2fpb0p4pfvb@bram-2...
> Am I too late to make a proposal for a new pragma for
> the Ada 2005 Amendment?
Yes

> It would have the syntax:
>
>     pragma Zero_Fill(simple_name);
>[...]
> Either way, I think the pragma would be useful in real
> programs,
I would not think so.
1) There is nothing special with the value 0 in Ada. You can have (easily) types where value 0 does not belong to the type,
therefore 0 would not be better than any random value.
2) An uninitialized variable is a bug. This would help hiding bugs, not finding them.
3) Because of 2), there is already pragma Initialize_Scalars, which purposedly initializes all scalars to an *invalid* value (if
possible). Therefore, you'll get Constraint_Error during the first tests, not in production use. Much better.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Zero_Fill pragma

[Nick Roberts]

On Tue, 20 Jul 2004 19:37:18 +0200, Jean-Pierre Rosen <rosen@adalog.fr>  
wrote:

> "Nick Roberts" <nick.roberts@acm.org> a �crit dans le message de  
> news:opsbf2fpb0p4pfvb@bram-2...

>> Am I too late to make a proposal for a new pragma for
>> the Ada 2005 Amendment?

> Yes

Well that makes the matter moot anyway, I suppose.

>> It would have the syntax:
>>
>>     pragma Zero_Fill(simple_name);
>> [...]
>> Either way, I think the pragma would be useful in real
>> programs,

> I would not think so.
> 1) There is nothing special with the value 0 in Ada. You can
> have (easily) types where value 0 does not belong to the
> type, therefore 0 would not be better than any random value.

Jean-Pierre, I suspect you did not understand the intended
meaning of this pragma. Perhaps I described it badly (sorry).

The pragma is not intended to affect any of the bits that are
used to represent a value. In a composite type, you sometimes
get 'gaps' in between components (or possibly at the edges),
of 'unused' bits. The pragma is intended to cause these
unused bits to be initialised to 0 whenever the composite
object as a whole is initialised. It is not intended to affect
the initialisation (or reading or updating) of any of the
components.

The purpose of the pragma is for use in interfacing, either
with hardware or with data in any externally defined format.

It is quite often the case, when doing this, that a composite
value has gaps which (according to the hardware design or data
definition) must be kept 0.

Although this can be done explicitly using 'dummy' components,
it is a pain doing so, and I think it can reduce the
readability and maintainability of code. I think the suggested
pragma would be better.

Suppose we wished to declare a record to represent the EFLAGS
register of the IA-32:

    type Flags_32 is
       record
          C:    Boolean; -- carry
          P:    Boolean; -- parity
          A:    Boolean; -- auxiliary carry
          Z:    Boolean; -- zero
          S:    Boolean; -- sign
          T:    Boolean; -- trap
          I:    Boolean; -- interrupt
          D:    Boolean; -- direction
          O:    Boolean; -- overflow
          IOPL: Privilege_Level; -- I/O privilege level
          NT:   Boolean; -- nested task
          RF:   Boolean; -- resume
          VM:   Boolean; -- virtual mode
          AC:   Boolean; -- alignment check
       end record;

    for Flags_32 use
       record
          C    at 0 range  0 ..  0;
          P    at 0 range  2 ..  2;
          A    at 0 range  4 ..  4;
          Z    at 0 range  6 ..  6;
          S    at 0 range  7 ..  7;
          T    at 0 range  8 ..  8;
          I    at 0 range  9 ..  9;
          D    at 0 range 10 .. 10;
          O    at 0 range 11 .. 11;
          IOPL at 0 range 12 .. 13;
          NT   at 0 range 14 .. 14;
          RF   at 0 range 16 .. 16;
          VM   at 0 range 17 .. 17;
          AC   at 0 range 18 .. 18;
       end record;

    for Flags_32'Size use 32;

It is important that the 17 bits not defined by the above
representation clause are initialised to 0 in objects of this
type. It would be truly yukky to have to declare another 17
dummy booleans to achieve this effect. It would surely be much
preferable to be able to just declare:

    pragma Zero_Fill(Flags_32);

-- 
Nick Roberts

Re: Zero_Fill pragma

[Jacob Sparre Andersen]

Nick Roberts wrote:

> The pragma is not intended to affect any of the bits that are used
> to represent a value. In a composite type, you sometimes get 'gaps'
> in between components (or possibly at the edges), of 'unused'
> bits. The pragma is intended to cause these unused bits to be
> initialised to 0 whenever the composite object as a whole is
> initialised. It is not intended to affect the initialisation (or
> reading or updating) of any of the components.
> 
> The purpose of the pragma is for use in interfacing, either with
> hardware or with data in any externally defined format.
> 
> It is quite often the case, when doing this, that a composite
> value has gaps which (according to the hardware design or data
> definition) must be kept 0.
> 
> Although this can be done explicitly using 'dummy' components, it is
> a pain doing so, and I think it can reduce the readability and
> maintainability of code. I think the suggested pragma would be
> better.

I disagree.

Although I can see that it is a bit of work to declare the parts of
the object that have to have a fixed value (it could also be 1 for
some hardware), but I still believe that it is better to do it
explicitly.

Jacob
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: Zero_Fill pragma

[Frank]

Hi
Why a pragma? Why not use e.g the for-construction to say something like
"others => False"

Frank

Re: Zero_Fill pragma

[Georg Bauhaus]

Nick Roberts <nick.roberts@acm.org> wrote:
: It is important that the 17 bits not defined by the above
: representation clause are initialised to 0 in objects of this
: type. It would be truly yukky to have to declare another 17
: dummy booleans to achieve this effect. It would surely be much
: preferable to be able to just declare:
: 
:    pragma Zero_Fill(Flags_32);

Hm. Provided the "default status" of unused bits is 0?

How many (non-limited) objects of type Flags_32 would you need?
(so that an explicit initialisation function for a per-process (?)
object is not acceptable)?


(There has once been a suggestion to have a rep clause

  for X use all
   record
   ...
   end record;

or similar, I don't remember exactly.)

Re: Zero_Fill pragma

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]


"Nick Roberts" <nick.roberts@acm.org> a �crit dans le message de news:opsbgc51fxp4pfvb@bram-2...
> >> Am I too late to make a proposal for a new pragma for
> >> the Ada 2005 Amendment?
>
> > Yes
>
> Well that makes the matter moot anyway, I suppose.
The latest deadline for submissions was dec 31, 2003. The general scope of the amendment has been approved by WG9 in June. Although
the ARG can decide to make new amendment AIs, it is highly unlikely to do it at this point in the game.

> Jean-Pierre, I suspect you did not understand the intended
> meaning of this pragma. Perhaps I described it badly (sorry).
Yes, I completely misunderstood the intent, sorry.

So, now I have mixed feelings about it. Yes, it would make things simpler to write. 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. And you are trading explicit description for (easier) implicit behaviour. And a good Unchecked_Conversion can easily reset
all bits to 0 (and YES, I claim Unchecked_Conversion is the precise tool for doing that!).

In short: there is value in what you are proposing, I am not convinced that the value is worth the cost.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Zero_Fill pragma

[Martin Dowie]

Nick Roberts wrote:
> The pragma is not intended to affect any of the bits that are
> used to represent a value. In a composite type, you sometimes
> get 'gaps' in between components (or possibly at the edges),
> of 'unused' bits. The pragma is intended to cause these
> unused bits to be initialised to 0 whenever the composite
> object as a whole is initialised. It is not intended to affect
> the initialisation (or reading or updating) of any of the
> components.

What about hardware/interface specs that require '1' not '0'?.. ;-)

RE: Zero_Fill pragma

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Martin Dowie [mailto:martin.dowie@baesystems.com]
...
| 
| What about hardware/interface specs that require '1' not '0'?.. ;-)
Refer to my proposal :-)

Re: Zero_Fill pragma

[Marin David Condic]

Isn't there something in the "Safety" annex about initialization of 
scalars? Can't remember off the top of my head, but I think I bumpped 
into it at some point. Would that be useful in this context?

MDC


Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
> | -----Message d'origine-----
> | De: Nick Roberts [mailto:nick.roberts@acm.org]
> ...
> | Am I too late to make a proposal for a new pragma for
> | the Ada 2005 Amendment?
> | 
> | It would have the syntax:
> | 
> |     pragma Zero_Fill(simple_name);
> ...
> | It would have the effect of causing all the bits in the
> | object which are unused to have a default initialisation
> | of 0.
> 
> I agree, this would be of immediate use here.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

RE: Zero_Fill pragma

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Marin David Condic [mailto:nobody@noplace.com]
...
| Isn't there something in the "Safety" annex about initialization of 
| scalars? Can't remember off the top of my head, but I think I bumpped 
| into it at some point. Would that be useful in this context?

Not really : what would be useful here is initialization *between* scalars
;-)

-- 
Lionel Draghi

Re: Zero_Fill pragma

[Marin David Condic]

I think I meant more "contextually"... There is some prescident for 
stipulating you want things initialized a certain way to guarantee 
conditions for safety and predictability. Would this be the appropriate 
area of the ARM on which to focus if someone wants a pragma to 
initialize unused bits? Would a proposal presumably want to do things in 
a similar way to what already exists?

I'm not convinced yet of the utility of it, but if someone is making a 
proposed language extension, its nice to be sure its at least focused in 
the right area of the ARM...

MDC


Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
> | -----Message d'origine-----
> | De: Marin David Condic [mailto:nobody@noplace.com]
> ...
> | Isn't there something in the "Safety" annex about initialization of 
> | scalars? Can't remember off the top of my head, but I think I bumpped 
> | into it at some point. Would that be useful in this context?
> 
> Not really : what would be useful here is initialization *between* scalars
> ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Zero_Fill pragma

[Dale Stanbrough]

In article <40FE611A.5000003@noplace.com>,
 Marin David Condic <nobody@noplace.com> wrote:

> Isn't there something in the "Safety" annex about initialization of 
> scalars? Can't remember off the top of my head, but I think I bumpped 
> into it at some point. Would that be useful in this context?


pragma Normalize_Scalars - sets them to out of range values if
possible.

dale

-- 
dstanbro@spam.o.matic.bigpond.net.au