83/95 issue, bad code or compiler bug

83/95 issue, bad code or compiler bug

[Jeff Creem]

I am trying to port some code from an Ada 83 compiler to an Ada 95
compiler and I have hit a problem that I am trying to figure out.


This is similar to the 'size discussion that we going on a few weeks
back but slightly different.


I have some code that essentially looks like : <same code warning, type
warnings in effect>



type My_Integer_Type is range -2**31 .. 2**31-1;
for My_Integer_Type'size use 32;


subtype My_Subtype is My_Integer_Type range 0 .. 255;


type My_Record is
  record
    My_Field    : My_Subtype;
    Other_Field : My_Integer_Type;
  end record;

for My_Record use
  record
    My_Field    at 0 range 0 .. 31;
    Other_Field at 4 range 0 .. 31; 
  end record;

for My_Record'size use 2 * 32;



with the old compiler the My_Subtype was still using all 32 bits so
that if we had a record with My_Field := 1 and Other_Field := 2 and
we looked at the bytes in memory associated with this record we would see


00 00 00 01
00 00 00 02

But with this new compiler (happens to be ada 95) I get

01 00 00 00
00 00 00 02

I suspect that the compiler is seeing that the 'size of My_Subtype is 8 and
so then even though I have the record rep-spec it does not feel constrained to
put this 8 bit value in any particular place in the 32 bits I have given it
since the field is larger than the subtype requires. 


Yuck.

So the question is:

Is this due to the Ada 83 code being written in a poor totally unportable way,
or is this permitted and expected in Ada 95 or is this a compiler bug (GNAT
does not exhibit this "bad" behaviour on my code but it certainly could
be that the code as written will have implementation defined results).


Thanks,
Jeff

Re: 83/95 issue, bad code or compiler bug

[Tom Moran]

I recently ran into what appears to be the same problem with OA 7.1.2
and sent it in as a bug report - no response yet.  It seems to be
doing over-agressive optimization which is bad if you are dealing with
a data structure passed to/from the outside world.  

Re: 83/95 issue, bad code or compiler bug

[Tucker Taft]

Jeff Creem (jeffrey.m.creem@lmco.com) wrote:


: type My_Record is
:   record
:     My_Field    : My_Subtype;
:     Other_Field : My_Integer_Type;
:   end record;

: for My_Record use
:   record
:     My_Field    at 0 range 0 .. 31;
:     Other_Field at 4 range 0 .. 31; 
:   end record;

: for My_Record'size use 2 * 32;



: with the old compiler the My_Subtype was still using all 32 bits so
: that if we had a record with My_Field := 1 and Other_Field := 2 and
: we looked at the bytes in memory associated with this record we would see


: 00 00 00 01
: 00 00 00 02

: But with this new compiler (happens to be ada 95) I get

: 01 00 00 00
: 00 00 00 02

: I suspect that the compiler is seeing that the 'size of My_Subtype is 8 and
: so then even though I have the record rep-spec it does not feel constrained to
: put this 8 bit value in any particular place in the 32 bits I have given it
: since the field is larger than the subtype requires. 


: Yuck.

This is a bug.  You should ask your compiler vendor whether a fix
is available.  The repclause clearly indicates that My_Field should occupy
4 bytes, and that means it should not just be using the high 8 bits of
the word.

: Thanks,
: Jeff

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: 83/95 issue, bad code or compiler bug

[Corey Ashford]

Tucker Taft <stt@houdini.camb.inmet.com> wrote in message news:F2ozE4.FLJ.0.-s@inmet.camb.inmet.com...
>Jeff Creem (jeffrey.m.creem@lmco.com) wrote:
[snip]
>: with the old compiler the My_Subtype was still using all 32 bits so
>: that if we had a record with My_Field := 1 and Other_Field := 2 and
>: we looked at the bytes in memory associated with this record we would see
>
>
>: 00 00 00 01
>: 00 00 00 02
>
>: But with this new compiler (happens to be ada 95) I get
>
>: 01 00 00 00
>: 00 00 00 02
[snip]

>This is a bug.  You should ask your compiler vendor whether a fix
>is available.  The repclause clearly indicates that My_Field should occupy
>4 bytes, and that means it should not just be using the high 8 bits of
>the word.


If this is a little-endian machine, then I would think that the
latter representation shown above is correct and expected.

- Corey

Re: 83/95 issue, bad code or compiler bug

[Corey Ashford]

Corey Ashford <corey@remove.these.four.words.rational.com> wrote in message news:732veo$aga$1@usenet.rational.com...
>
>Tucker Taft <stt@houdini.camb.inmet.com> wrote in message news:F2ozE4.FLJ.0.-s@inmet.camb.inmet.com...
>>Jeff Creem (jeffrey.m.creem@lmco.com) wrote:
>[snip]
>>: with the old compiler the My_Subtype was still using all 32 bits so
>>: that if we had a record with My_Field := 1 and Other_Field := 2 and
>>: we looked at the bytes in memory associated with this record we would see
>>
>>
>>: 00 00 00 01
>>: 00 00 00 02
>>
>>: But with this new compiler (happens to be ada 95) I get
>>
>>: 01 00 00 00
>>: 00 00 00 02
>[snip]
>
>>This is a bug.  You should ask your compiler vendor whether a fix
>>is available.  The repclause clearly indicates that My_Field should occupy
>>4 bytes, and that means it should not just be using the high 8 bits of
>>the word.
>
>
>If this is a little-endian machine, then I would think that the
>latter representation shown above is correct and expected.
>
>- Corey

oops... never mind.  It's obviously not a little-endian machine because
of the representation of the integer 2.

Sorry for the confusion.

- Corey

Re: 83/95 issue, bad code or compiler bug

[Matthew Heaney]

In article <jeffrey.m.creem-1911981641480001@ljd155.sanders.lmco.com>,
jeffrey.m.creem@lmco.com (Jeff Creem) wrote:

>type My_Integer_Type is range -2**31 .. 2**31-1;
>for My_Integer_Type'size use 32;

Please use the types in package Interfaces; either Interfaces.Integer_32 or
Interfaces.Unsigned_32.  

>subtype My_Subtype is My_Integer_Type range 0 .. 255;
>
>
>type My_Record is
>  record
>    My_Field    : My_Subtype;
>    Other_Field : My_Integer_Type;
>  end record;
>
>for My_Record use
>  record
>    My_Field    at 0 range 0 .. 31;
>    Other_Field at 4 range 0 .. 31; 
>  end record;
>
>for My_Record'size use 2 * 32;
>

This is bad style.  For low-level I/O --here, meaning anything that appears
as the component of a record with a rep clause-- all scalar types should
have no constraints.  In your example, My_Field should be of type
My_Interger_Type (Interfaces.Integer_32), not My_Subtype.

>Is this due to the Ada 83 code being written in a poor totally unportable way,
>or is this permitted and expected in Ada 95 or is this a compiler bug (GNAT
>does not exhibit this "bad" behaviour on my code but it certainly could
>be that the code as written will have implementation defined results).

Don't mix rep clauses and types-with-constraints.

Re: 83/95 issue, bad code or compiler bug

[Tom Moran]

>Don't mix rep clauses and types-with-constraints.
Why not?
  Certainly if it's an input record the usual caveats about not
relying on correctness apply, but for an output record I see no
problem.  I've also used the component form
  Fixed_Thing : Integer range 10 .. 10 := 10;
when the Fixed_Thing component of an output record is required to have
a particular, fixed value (eg the record size in some Windows API
calls).

Re: 83/95 issue, bad code or compiler bug

[Tom Moran]

The OA 7.1.2 Release/Installation Notes say:
>Even though an object has a 16-bit representation clause, the compiler may still 
>treat it as an 8-bit object if it thinks the true object can fit in only 8-bits.
I guess the moral is "read the Release Notes - often". #.#

Re: 83/95 issue, bad code or compiler bug

[dewarr]

In article <3654cef4.21572221@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> The OA 7.1.2 Release/Installation Notes say:
> >Even though an object has a 16-bit representation
clause, the compiler may still
> >treat it as an 8-bit object if it thinks the true object
can fit in only 8-bits.
> I guess the moral is "read the Release Notes - often".
#.#
>
>


I think you misunderstand this. The compiler is indeed free
to only access 8 bits in a case like this, and indeed this
need not really be mentioned, it is obviously correct.

But the above cannot account for the clear bug that was
reported in the start of this thread (using the wrong 8
bits of a 32-bit repped field).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: 83/95 issue, bad code or compiler bug

[Tom Moran]

>I think you misunderstand this. The compiler is indeed free
>to only access 8 bits in a case like this, and indeed this
>need not really be mentioned, it is obviously correct.
Do you mean that you understand 
   for X use at 0 range 0 .. 15;
to mean that the compiler may not use *more* than 16 bits for X, but
is perfectly free to use *less*?  I would find that interpretation
bizarrely anti-useful and am certainly glad Gnat does not seem to do
things that way.

Re: 83/95 issue, bad code or compiler bug

[dewarr]

In article <36587057.292493@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >I think you misunderstand this. The compiler is indeed f
> >free to only access 8 bits in a case like this, and
> >indeed this
> >need not really be mentioned, it is obviously correct.

> Do you mean that you understand
>    for X use at 0 range 0 .. 15;

> to mean that the compiler may not use *more* than 16 bits
> for X, but
> is perfectly free to use *less*?  I would find that
> interpretation
> bizarrely anti-useful and am certainly glad Gnat does not
> seem to do
> things that way.


Yes, that interpretation *is* bizarrely anti-useful, and
also has nothing to do with my statement. Reread the above
quote more carefully. I said *access*!

Of course the compiler must allocate the number of bits
specified, but in the above case, since the number is known
to be in the range 0..15, it is fine for the generated code
to load only the low order byte. The only time this would
make a difference is if the value was abnormal. Note that
one exception is that a 'Valid test must load all 16-bits!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: 83/95 issue, bad code or compiler bug

[Tom Moran]

>since the number is known
>to be in the range 0..15, it is fine for the generated code
>to load only the low order byte
How about store?  eg, if the RAM containing the two bytes initially
contained 2#0101010101010101# would it be permissible, do you think,
for  Rec.X := 7;  to result in  2#0101010101010111#  or
2#0101010100000111#?  And what if we are talking about memory mapped
IO, where an access is important, even if what is being stored is a
zero.