Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

Hi

I was wondering how the addressing mechanism works in GNAT Ada? Is it so vastly different to Object Ada? Is there a way I can tailor the GNAT addressing mechanism to follow that of Object Ada?

I have a program that runs perfectly in Object Ada. The program relies heavily on "USE AT" clauses together with 'SIZE on underlying type definition. This is in order to map directly and deterministically to memory with bit precision. The data is independently produced so this is very important.

I have compiled the program is GNAT Ada but I am getting run time errors such as "misaligned address value". More worryingly, any data read from memory that relies on the addressing mechanisms described above is incoherent.

I am interested in moving to GNAT Ada because I believe the accompanying toolset is much richer and therefore more productive but I am beginning to wonder whether this is too onerous task?

Any help is greatly appreciated.

Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding wrote:
> Hi
> 
> I was wondering how the addressing mechanism works in GNAT Ada? Is it so vastly different to Object Ada? Is there a way I can tailor the GNAT addressing mechanism to follow that of Object Ada?
> 
> I have a program that runs perfectly in Object Ada. The program relies heavily on "USE AT" clauses together with 'SIZE on underlying type definition. This is in order to map directly and deterministically to memory with bit precision. The data is independently produced so this is very important.
> 
> I have compiled the program is GNAT Ada but I am getting run time errors such as "misaligned address value". More worryingly, any data read from memory that relies on the addressing mechanisms described above is incoherent.
> 
> I am interested in moving to GNAT Ada because I believe the accompanying toolset is much richer and therefore more productive but I am beginning to wonder whether this is too onerous task?
> 
> Any help is greatly appreciated.
> 
> Lucas

Hi, 

I forgot to say that platform is Windows 7 (64 bit if that matters) and the data is in S_RECORD format (With correct ENDIANISM).

Any help is greatly appreciated.

Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[G.B.]

On 07.09.15 13:54, Lucas Redding wrote:
> On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding wrote:
>> Hi
>>
>> I was wondering how the addressing mechanism works in GNAT Ada? Is it so vastly different to Object Ada? Is there a way I can tailor the GNAT addressing mechanism to follow that of Object Ada?
>>
>> I have a program that runs perfectly in Object Ada. The program relies heavily on "USE AT" clauses together with 'SIZE on underlying type definition. This is in order to map directly and deterministically to memory with bit precision. The data is independently produced so this is very important.
>>
>> I have compiled the program is GNAT Ada but I am getting run time errors such as "misaligned address value". More worryingly, any data read from memory that relies on the addressing mechanisms described above is incoherent.
>>
>> I am interested in moving to GNAT Ada because I believe the accompanying toolset is much richer and therefore more productive but I am beginning to wonder whether this is too onerous task?
>>
>> Any help is greatly appreciated.
>>
>> Lucas
>
> Hi,
>
> I forgot to say that platform is Windows 7 (64 bit if that matters) and the data is in S_RECORD format (With correct ENDIANISM).
>
> Any help is greatly appreciated.

In case you haven't already found it, a look at GNAT
chosen representation is possible when translating
with the -gnatR?[s] options. I also assume you have
been specifying alignment of types/objects? Maybe
also including fields for padding?

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 3:04:43 PM UTC+1, G.B. wrote:
> On 07.09.15 13:54, Lucas Redding wrote:
> > On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding wrote:
> >> Hi
> >>
> >> I was wondering how the addressing mechanism works in GNAT Ada? Is it so vastly different to Object Ada? Is there a way I can tailor the GNAT addressing mechanism to follow that of Object Ada?
> >>
> >> I have a program that runs perfectly in Object Ada. The program relies heavily on "USE AT" clauses together with 'SIZE on underlying type definition. This is in order to map directly and deterministically to memory with bit precision. The data is independently produced so this is very important.
> >>
> >> I have compiled the program is GNAT Ada but I am getting run time errors such as "misaligned address value". More worryingly, any data read from memory that relies on the addressing mechanisms described above is incoherent.
> >>
> >> I am interested in moving to GNAT Ada because I believe the accompanying toolset is much richer and therefore more productive but I am beginning to wonder whether this is too onerous task?
> >>
> >> Any help is greatly appreciated.
> >>
> >> Lucas
> >
> > Hi,
> >
> > I forgot to say that platform is Windows 7 (64 bit if that matters) and the data is in S_RECORD format (With correct ENDIANISM).
> >
> > Any help is greatly appreciated.
> 
> In case you haven't already found it, a look at GNAT
> chosen representation is possible when translating
> with the -gnatR?[s] options. I also assume you have
> been specifying alignment of types/objects? Maybe
> also including fields for padding?

Hi GB

Yes I have included alignment of types and objects. I have not explicitly specified the padding gaps. In object Ada, this is not necessary provided the type specifications are explicitly size constrained and the object fits in between its address and the next objects address. In other words if there is a gap between the end of one object and the beginning of the next object, the data is read correctly (if the size of the type is explicitly constrained). 

Many thanks for that pointerto the -gnatR option. Being a novice to the compiler there are so many options to get to grips with. I am also using GPS, and toggling all the tick boxes did not produce this switch.

I am off to the GNAT RM to read about this switch, and will report back.

Thanks again
Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Anh Vo]

On Monday, September 7, 2015 at 9:02:48 AM UTC-7, Lucas Redding wrote:
> On Monday, September 7, 2015 at 3:04:43 PM UTC+1, G.B. wrote:
> > On 07.09.15 13:54, Lucas Redding wrote:
> 
> Yes I have included alignment of types and objects. I have not explicitly specified the padding gaps. In object Ada, this is not necessary provided the type specifications are explicitly size constrained and the object fits in between its address and the next objects address. In other words if there is a gap between the end of one object and the beginning of the next object, the data is read correctly (if the size of the type is explicitly constrained). 
> 
> Many thanks for that pointerto the -gnatR option. Being a novice to the compiler there are so many options to get to grips with. I am also using GPS, and toggling all the tick boxes did not produce this switch.
 
When compiled with GNAT, did GNAT spit out any Warnings at all? I would suspect misaligned address value during run time should have warned during compilation.

Anh Vo

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 5:28:39 PM UTC+1, Anh Vo wrote:
> On Monday, September 7, 2015 at 9:02:48 AM UTC-7, Lucas Redding wrote:
> > On Monday, September 7, 2015 at 3:04:43 PM UTC+1, G.B. wrote:
> > > On 07.09.15 13:54, Lucas Redding wrote:
> > 
> > Yes I have included alignment of types and objects. I have not explicitly specified the padding gaps. In object Ada, this is not necessary provided the type specifications are explicitly size constrained and the object fits in between its address and the next objects address. In other words if there is a gap between the end of one object and the beginning of the next object, the data is read correctly (if the size of the type is explicitly constrained). 
> > 
> > Many thanks for that pointerto the -gnatR option. Being a novice to the compiler there are so many options to get to grips with. I am also using GPS, and toggling all the tick boxes did not produce this switch.
>  
> When compiled with GNAT, did GNAT spit out any Warnings at all? I would suspect misaligned address value during run time should have warned during compilation.
> 
> Anh Vo

Indeed Anh Vo

That would have been very useful. Unfortunately warnings are not being issued during the compilation stages.

I shall check the level of warnings in the compiler options just in case I have missed something. Any pointers greatly appreciated.

LR

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Anh Vo]

On Tuesday, September 8, 2015 at 12:30:57 AM UTC-7, Lucas Redding wrote:
> On Monday, September 7, 2015 at 5:28:39 PM UTC+1, Anh Vo wrote:
> > On Monday, September 7, 2015 at 9:02:48 AM UTC-7, Lucas Redding wrote:
> > > On Monday, September 7, 2015 at 3:04:43 PM UTC+1, G.B. wrote:
> > > > On 07.09.15 13:54, Lucas Redding wrote:
> > > 
> > > Yes I have included alignment of types and objects. I have not explicitly specified the padding gaps. In object Ada, this is not necessary provided the type specifications are explicitly size constrained and the object fits in between its address and the next objects address. In other words if there is a gap between the end of one object and the beginning of the next object, the data is read correctly (if the size of the type is explicitly constrained). 
> > > 
> > > Many thanks for that pointerto the -gnatR option. Being a novice to the compiler there are so many options to get to grips with. I am also using GPS, and toggling all the tick boxes did not produce this switch.
> >  
> > When compiled with GNAT, did GNAT spit out any Warnings at all? I would suspect misaligned address value during run time should have warned during compilation.
> > 
> > Anh Vo
> 
> Indeed Anh Vo
> 
> That would have been very useful. Unfortunately warnings are not being issued during the compilation stages.
> 
> I shall check the level of warnings in the compiler options just in case I have missed something. Any pointers greatly appreciated.

I would suggest to look at difference address alignment between the two where OA may patch it by default while GNAT does not. The worst case is that you need to post part of the codes. So, we can test it if needed.

AV

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jeffrey R. Carter]

On 09/08/2015 12:30 AM, Lucas Redding wrote:
> 
> That would have been very useful. Unfortunately warnings are not being issued
> during the compilation stages.
> 
> I shall check the level of warnings in the compiler options just in case I
> have missed something. Any pointers greatly appreciated.

You might want to use -gnatwa (all warnings).

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Pascal Obry]

Le lundi 07 septembre 2015 à 04:54 -0700, Lucas Redding a écrit :
> I forgot to say that platform is Windows 7 (64 bit if that matters)
> and the data is in S_RECORD format (With correct ENDIANISM).

Probably the issue. You are now targeting a 64bit platform and I bet
that since your program is old it was a 32bit Windows at the time.

So, it may turn out that this is not a GNAT vs ObjectAda issue at all
but a 32bit vs 64bit one.

At least check this...

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Pascal Obry]

Le lundi 07 septembre 2015 à 04:54 -0700, Lucas Redding a écrit :
> I forgot to say that platform is Windows 7 (64 bit if that matters)
> and the data is in S_RECORD format (With correct ENDIANISM).

Hum... probably read to fast. You said Windows 64bit not GNAT 64bit :)
Is that the case or not?

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

Yes Pascal. Windows 64bit. Gnat 64bit is too ambitious for now. Nonetheless thanks for your observation and for making me aware of what lies ahead.

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Niklas Holsti]

On 15-09-07 14:54 , Lucas Redding wrote:
> On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding
> wrote:
>> Hi
    ...
>> I have a program that runs perfectly in Object Ada. The program
>> relies heavily on "USE AT" clauses together with 'SIZE on
>> underlying type definition. This is in order to map directly and
>> deterministically to memory with bit precision. The data is
>> independently produced so this is very important.
>>
>> I have compiled the program is GNAT Ada but I am getting run time
>> errors such as "misaligned address value". More worryingly, any
>> data read from memory that relies on the addressing mechanisms
>> described above is incoherent.
    ...
> I forgot to say that platform is Windows 7 (64 bit if that matters)
> and the data is in S_RECORD format (With correct ENDIANISM).

That sounds a bit confusing; S-record format is an ASCII (hex) text 
file. You probably mean that you read the S-record data and convert from 
ASCII hex to an octet array, octet per octet, and then you access that 
octet array using the "use at" mechanism.

I'm not surprised that you get errors -- this sounds very unportable to 
me (because of the "use at"). I understand that you have an existing 
program that you want to port, preferably without a lot of changes, but 
is it really worthwhile to port it from its old unportable form into a 
new and different unportable form?

For this problem, I would use the Ada Stream feature, either to read the 
S-record text directly into my data structure (i.e. the variables for 
which you use "use at", but which I would fill with Stream Read), or by 
converting the ASCII S-records into an octet array, and then viewing 
that octet array as an indexable in-memory Stream and using Stream Read 
to access the data objects within the octet array.

Just a suggestion, of course.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 10:02:37 PM UTC+1, Niklas Holsti wrote:
> On 15-09-07 14:54 , Lucas Redding wrote:
> > On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding
> > wrote:
> >> Hi
>     ...
> >> I have a program that runs perfectly in Object Ada. The program
> >> relies heavily on "USE AT" clauses together with 'SIZE on
> >> underlying type definition. This is in order to map directly and
> >> deterministically to memory with bit precision. The data is
> >> independently produced so this is very important.
> >>
> >> I have compiled the program is GNAT Ada but I am getting run time
> >> errors such as "misaligned address value". More worryingly, any
> >> data read from memory that relies on the addressing mechanisms
> >> described above is incoherent.
>     ...
> > I forgot to say that platform is Windows 7 (64 bit if that matters)
> > and the data is in S_RECORD format (With correct ENDIANISM).
> 
> That sounds a bit confusing; S-record format is an ASCII (hex) text 
> file. You probably mean that you read the S-record data and convert from 
> ASCII hex to an octet array, octet per octet, and then you access that 
> octet array using the "use at" mechanism.
> 
> I'm not surprised that you get errors -- this sounds very unportable to 
> me (because of the "use at"). I understand that you have an existing 
> program that you want to port, preferably without a lot of changes, but 
> is it really worthwhile to port it from its old unportable form into a 
> new and different unportable form?
> 
> For this problem, I would use the Ada Stream feature, either to read the 
> S-record text directly into my data structure (i.e. the variables for 
> which you use "use at", but which I would fill with Stream Read), or by 
> converting the ASCII S-records into an octet array, and then viewing 
> that octet array as an indexable in-memory Stream and using Stream Read 
> to access the data objects within the octet array.
> 
> Just a suggestion, of course.
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Thanks Niklas,

That is indeed what we are already doing, re converting the SRECORD hex into octets and then mapping the stream to memory. 

LR

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jeffrey R. Carter]

On 09/07/2015 04:39 AM, Lucas Redding wrote:
> 
> I have a program that runs perfectly in Object Ada. The program relies
> heavily on "USE AT" clauses together with 'SIZE on underlying type
> definition. This is in order to map directly and deterministically to memory
> with bit precision. The data is independently produced so this is very
> important.

"Use at" is the Ada-83 mechanism for specifying an object's address; since Ada
95 the form

for V'Address use A;

is preferred, and "use at" is considered obsolete. I would guess, then, that
this program has been around for quite a while, having originally been Ada 83,
and that there has been on-going effort to port it to new hardware, OS versions,
and compilers to keep it available.

Addresses are something that are platform and compiler dependent. It probably
took a fair amount of effort to understand how Object Ada lays things out in
memory to get to the version you currently have. A similar amount of effort
should be expected to understand GNAT's approach to these things and to modify
the representation clauses to achieve the same representation as OA. You've
already found that GNAT wants to align things differently from OA, so specifying
non-default alignments may be necessary.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 4:49:01 PM UTC+1, Jeffrey R. Carter wrote:
> On 09/07/2015 04:39 AM, Lucas Redding wrote:
> > 
> > I have a program that runs perfectly in Object Ada. The program relies
> > heavily on "USE AT" clauses together with 'SIZE on underlying type
> > definition. This is in order to map directly and deterministically to memory
> > with bit precision. The data is independently produced so this is very
> > important.
> 
> "Use at" is the Ada-83 mechanism for specifying an object's address; since Ada
> 95 the form
> 
> for V'Address use A;
> 
> is preferred, and "use at" is considered obsolete. I would guess, then, that
> this program has been around for quite a while, having originally been Ada 83,
> and that there has been on-going effort to port it to new hardware, OS versions,
> and compilers to keep it available.
> 
> Addresses are something that are platform and compiler dependent. It probably
> took a fair amount of effort to understand how Object Ada lays things out in
> memory to get to the version you currently have. A similar amount of effort
> should be expected to understand GNAT's approach to these things and to modify
> the representation clauses to achieve the same representation as OA. You've
> already found that GNAT wants to align things differently from OA, so specifying
> non-default alignments may be necessary.
> 
> -- 
> Jeff Carter
> "Why, the Mayflower was full of Fireflies, and a few
> horseflies, too. The Fireflies were on the upper deck,
> and the horseflies were on the Fireflies."
> Duck Soup
> 95

Thanks Jeff. 

Good guess. Yes it has been around quite long.

You confirmed my worst fears, re Addressing is compiler dependent. I knew I had read that somewhere but I did not expect there to be such a big difference if you had made full use of the language facilities which on their own seem to specify a great deal of precision in mapping to memory. 

I need to draw a balance between the effort of porting the application and the gain in productivity after porting it. After all, it works on OA with no extra effort (only without the richness of the features offered by GNAT) The more effort it takes to port it the weaker the attraction.

I have tried the -gnatR that GB kindly suggested. I am now studying the information to measure the amount of effort required to port. I am still hoping my expectations are somehow correct (re make full use of the language facilities for mapping on to memory makes the mapping precise).

I shall report back when I have made a decsion.

Thanks agaion

LR

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Markus Schöpflin]

Well, we're using GNAT on Linux (32 & 64 Bit) and do a lot of binary record 
layout fiddling, and never had any problems.

For example, our layout specifications (for a variant record in this case) 
look like this:

  for RECORD_T use record at mod 2;
    A1 at 0 range 0 .. 0;
    A2 at 0 range 1 .. 7;
    B  at 2 range 0 .. B_SIZE*8-1;
    C  at 2 range 0 .. C_SIZE*8-1;
  end record;

I guess yours are looking similar?

Markus

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Tuesday, September 8, 2015 at 8:12:57 AM UTC+1, Markus Schöpflin wrote:
> Well, we're using GNAT on Linux (32 & 64 Bit) and do a lot of binary record 
> layout fiddling, and never had any problems.
> 
> For example, our layout specifications (for a variant record in this case) 
> look like this:
> 
>   for RECORD_T use record at mod 2;
>     A1 at 0 range 0 .. 0;
>     A2 at 0 range 1 .. 7;
>     B  at 2 range 0 .. B_SIZE*8-1;
>     C  at 2 range 0 .. C_SIZE*8-1;
>   end record;
> 
> I guess yours are looking similar?
> 
> Markus

Yes Markus,

Ours are similar. There is no problem when using Object Ada, but we are having a problem with GNAT. The issue is that each compiler behaves differently as AMHo has pointed out.

Thanks nonetheless.

LR

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 7, 2015 at 12:39:35 PM UTC+1, Lucas Redding wrote:
> Hi
> 
> I was wondering how the addressing mechanism works in GNAT Ada? Is it so vastly different to Object Ada? Is there a way I can tailor the GNAT addressing mechanism to follow that of Object Ada?
> 
> I have a program that runs perfectly in Object Ada. The program relies heavily on "USE AT" clauses together with 'SIZE on underlying type definition. This is in order to map directly and deterministically to memory with bit precision. The data is independently produced so this is very important.
> 
> I have compiled the program is GNAT Ada but I am getting run time errors such as "misaligned address value". More worryingly, any data read from memory that relies on the addressing mechanisms described above is incoherent.
> 
> I am interested in moving to GNAT Ada because I believe the accompanying toolset is much richer and therefore more productive but I am beginning to wonder whether this is too onerous task?
> 
> Any help is greatly appreciated.
> 
> Lucas

Thanks Everybody.

Although I still have not completely resolved the issue, by analysing the output from -gnatR I can see the issue is with the alignment of underlying type and object specifications. The original code has no alignment clauses at all. 

We know that all the objects (memory input to the application) are mapped to memory so that everything is aligned at 1. 

I deduce that this means that OA by default aligns objects to 1 since the objects are being read without any alignment clauses. 

On the other hand, GNAT aligns each object to a boundary of a power of 2 and adjusts this based on the component size.

Here lies the issue.

I need to change the alignment of each underlying type mapped into memory. I am hoping the combination of explicit alignments and precise rep clauses (size etc.) should make the code portable between compilers.

Fingers crossed while I go and do the work and will report back when I finish (or if I get stuck).

Many thanks for all your help.

Much appreciated.

Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[G.B.]

On 10.09.15 12:47, Lucas Redding wrote:
> I need to change the alignment of each underlying type mapped into memory. I am hoping the combination of explicit alignments and precise rep clauses (size etc.) should make the code portable between compilers.

You are certainly aware of mappings that can be effected
by just using a type conversion? This way, some of the less
portable representations can be stashed away.

package P is

    type T1 is range 1 .. 10;
    type T2 is range -1_000 .. +1_000;

    type Internal is record
       A : T1;
       B : T2;
    end record;

    type Mapped is new Internal;

    for Mapped'Size use 32;
    for Mapped'Alignment use 1;
    for Mapped use record
       A at 0 range 0 .. 7;
       B at 0 range 11 .. 30;
    end record;

end P;

with P;
procedure Test_P is
    Z : P.Mapped;
    pragma Volatile (Z);

    procedure Place (Value : P.Internal) is
    begin
       Z := P.Mapped (Value);
       pragma Inspection_Point (Z);
    end Place;

begin
    Place( P.Internal'(A => 3, B => 42) );
end Test_P;

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Thursday, September 10, 2015 at 1:34:17 PM UTC+1, G.B. wrote:
> On 10.09.15 12:47, Lucas Redding wrote:
> > I need to change the alignment of each underlying type mapped into memory. I am hoping the combination of explicit alignments and precise rep clauses (size etc.) should make the code portable between compilers.
> 
> You are certainly aware of mappings that can be effected
> by just using a type conversion? This way, some of the less
> portable representations can be stashed away.
> 
> package P is
> 
>     type T1 is range 1 .. 10;
>     type T2 is range -1_000 .. +1_000;
> 
>     type Internal is record
>        A : T1;
>        B : T2;
>     end record;
> 
>     type Mapped is new Internal;
> 
>     for Mapped'Size use 32;
>     for Mapped'Alignment use 1;
>     for Mapped use record
>        A at 0 range 0 .. 7;
>        B at 0 range 11 .. 30;
>     end record;
> 
> end P;
> 
> with P;
> procedure Test_P is
>     Z : P.Mapped;
>     pragma Volatile (Z);
> 
>     procedure Place (Value : P.Internal) is
>     begin
>        Z := P.Mapped (Value);
>        pragma Inspection_Point (Z);
>     end Place;
> 
> begin
>     Place( P.Internal'(A => 3, B => 42) );
> end Test_P;

Thanks GB,

In fact I am stumbling on portability of the rep clauses. But I think more importantly I am led to feel that GNAT is not enforcing the strong typing and thus the "Deterministic" properties that Ada boasts. 

I have the following type specifications which map onto an input source we have no control over:

type sixteen_bits is range 0..(2**16)-1 ;
type fourteen_bits is range 0..(2**14)-1;
type ten_bits is range 0..(2**10)-1;

type rec is record 
   a: fourteen_bits ;
   b: ten bits ;
end rec ;

for rec use 
   a at 0 range 0..13 ;
   b at 0 range 14..23 ;
end rec ;

for rec'size use 32;
for rec'alignment use 1;

I declare the variable 
VAR_REC : rec ;
for VAR_REC;'Address use Mapped_input_item'Address ;

We would like to copy the information once to a byte aligned record to hopefully speed up access to this item because it is accessed internally a large number of times.

so our local type specification is 
subtype local_fourteen_bits is sixteen_bits range 0..(2**14)-1;
subtype local_ten_bits is sixteen_bits range (2**16)-1;

type local_rec is record
   local_a : local_fourteen_bits ;
   local_b : local_ten_bits ;
end record;

for local_rec use
   local_a at 0 range 0..13 ;
   local_b at 2 range 0..9 ;
end record;

for local_rec'size use 32 ;
for local_rec'Alignment use 1 ;

I declare the variable 
VAR_LOCAL_REC : local_rec ;

The problem is when I copy each record component to the local copies (including the typecast) my var_local_rec.a takes on a 16 bit value and thus includes the bit values from var_rec.b ;

So if var_rec.a is 1 and var_rec.b is 2 I end up with the following in var_local_rec in GNAT Ada:

var_local_rec.a = 32769 ;
var_local_rec.b = 2 ;

Clearly this is wrong. And although I have set all checks in the compiler I don't get an overflow error which is what I would expect.

In Object Ada I get:

var_local_rec.a = 1 ; 
var_local_rec.b = 2; 

...which is what I'd expect given the strongly typed definitions.

Am I missing something here? Is there a pragma or compiler switch that enforces the strict typing regime?

Any continued help is greatly appreciated.

Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jacob Sparre Andersen]

Lucas Redding wrote:

Your examples don't compile.  Please show us the actual code.

Greetings,

Jacob
-- 
"Very small. Go to sleep" - monster (not drooling)

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 21, 2015 at 12:57:09 PM UTC+1, Jacob Sparre Andersen wrote:
> Lucas Redding wrote:
> 
> Your examples don't compile.  Please show us the actual code.
> 
> Greetings,
> 
> Jacob
> -- 
> "Very small. Go to sleep" - monster (not drooling)

Hi Jacob

thanks for that. I am avoiding having to flood this with tons of code. So here is a compiled example.

package interface_p
is

   type sixteen_bits is range 0..(2**16)-1 ; 
   type fourteen_bits is range 0..(2**14)-1; 
   type ten_bits is range 0..(2**10)-1; 
   type padding_bits is range 0..(2**8)-1 ; 

   type rec is record 
      a: fourteen_bits ; 
      b: ten_bits ; 
      padding : padding_bits ;
   end record ; 

   for rec use 
   record
      a at 0 range 0..13 ; 
      b at 0 range 14..23 ; 
      padding at 0 range 24..31;
   end record ; 
   for rec'size use 32; 
   for rec'alignment use 1; 

   subtype local_fourteen_bits is sixteen_bits range 0 .. (2 ** 14)-1;
   subtype local_ten_bits is sixteen_bits range 0 .. (2 ** 10)-1; 
   type local_rec is record
      a : local_fourteen_bits ; 
      b : local_ten_bits ; 
   end record; 

   for local_rec use 
   record
      a at 0 range 0 .. 13 ; 
      b at 2 range 0 .. 9 ; 
   end record; 

   for local_rec'size use 32 ; 
   for local_rec'Alignment use 1 ; 
 
   VAR_REC : rec := (a => 1, b => 2, padding => 0 ) ; 
   
   -- I explicitly assign here but in actual application it maps onto a 32 bit 
   -- record in memory. I have deliberately changed in order to avoid adding 
   -- tons of irrelevant code.
   
   
   function READ_RECORD
   return local_rec ;

end interface_p ;

package body INTERFACE_P
is
   function READ_RECORD
   return local_rec 
   is
      VAR_LOCAL_REC : local_rec ; 
   begin 
   
      -- We would like to copy the information once to a byte aligned 
      -- record to hopefully speed up 
      -- access to this item because it is accessed internally a large 
      -- number of times. 

      VAR_LOCAL_REC.a := local_fourteen_bits(VAR_REC.a) ;
      VAR_LOCAL_REC.b := local_ten_bits(VAR_REC.b) ;
      
      -- The problem is when I copy each record component to the local copies 
      -- (including the typecast) 
      -- my var_local_rec.a takes on a 16 bit value and thus includes the bit values 
      -- from var_rec.b ;       
      
      -- So if var_rec.a is 1 and var_rec.b is 2 I end up with the following in 
      -- var_local_rec in GNAT Ada : 

      -- var_local_rec.a = 32769 ; 
      -- var_local_rec.b = 2 ; 

      -- Clearly this is wrong. And although I have set all checks in the compiler I 
      -- don't get an overflow error which is what I would expect. 

      --      In Object Ada I get : 

      --      var_local_rec.a = 1 ; 
      --      var_local_rec.b = 2; 
      return VAR_LOCAl_REC ;
      
   end READ_RECORD ;

end INTERFACE_P ;

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jacob Sparre Andersen]

Lucas Redding wrote:

> thanks for that. I am avoiding having to flood this with tons of
> code. So here is a compiled example.

You missed a test routine, so I wrote one:

with Ada.Text_IO;

with Interface_P;

procedure Use_Interface_P is
   type Word is mod 2 ** 32;
   Data   : Word with Import, Address => Interface_P.Var_Rec'Address;
   Remote : Interface_P.Rec;
   Local  : Interface_P.Local_Rec;
begin
   for Test_Value in Word loop
      Data := Test_Value;

      Remote := Interface_P.Var_Rec;
      Local  := Interface_P.Read_Record;

      if Word (Remote.A) /= Word (Local.A) or
         Word (Remote.B) /= Word (Local.B)
      then
         Ada.Text_IO.Put_Line ("Test value:" & Data'Img);
         Ada.Text_IO.Put_Line ("A:" & Remote.A'Img & " -> " & Local.A'Img);
         Ada.Text_IO.Put_Line ("B:" & Remote.B'Img & " -> " & Local.B'Img);
         Ada.Text_IO.New_Line;
      elsif Test_Value mod 2 ** 24 = 0 then
         Ada.Text_IO.Put_Line ("Test value:" & Data'Img);
      end if;
   end loop;
end Use_Interface_P;

Compiled with

   gnatmake -gnata -gnato -fstack-check -gnat12 -gnatyO -gnatv -gnati1 -gnatf -gnatn -m -j4 use_interface_p

the program runs without any errors, so you may have misconfigured your
compiler somehow.

Greetings,

Jacob
-- 
"The point is that I am now a perfectly safe penguin!"

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Georg Bauhaus]

On 21.09.15 15:22, Lucas Redding wrote:
> On Monday, September 21, 2015 at 12:57:09 PM UTC+1, Jacob Sparre Andersen wrote:
>> Lucas Redding wrote:
>>
>> Your examples don't compile.  Please show us the actual code.
>>
>> Greetings,
>>
>> Jacob
>> --
>> "Very small. Go to sleep" - monster (not drooling)
>
> Hi Jacob
>
> thanks for that. I am avoiding having to flood this with tons of code. So here is a compiled example.
>
> package interface_p
> is
  (...)
> end INTERFACE_P ;
>

Is this happening only when you read from the shared location?
I see the output
local a:     1, local b:     2
from the following program, compiled using GNAT GPL 2014 on a Mac:

With Ada.Text_IO;
with INTERFACE_P; use INTERFACE_P;
procedure Test_Interface_P
is
    It : local_rec;
begin
    It := READ_RECORD;
    
    declare
       use Ada;
       package Xintio is new Text_IO.Integer_IO (sixteen_bits);
    begin
       Text_Io.Put ("local a:"); Xintio.Put (It.a);
       Text_Io.Put (", local b:"); Xintio.Put (It.b);
       Text_Io.New_Line;
    end;

end Test_Interface_P;

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 21, 2015 at 2:52:10 PM UTC+1, Georg Bauhaus wrote:
> On 21.09.15 15:22, Lucas Redding wrote:
> > On Monday, September 21, 2015 at 12:57:09 PM UTC+1, Jacob Sparre Andersen wrote:
> >> Lucas Redding wrote:
> >>
> >> Your examples don't compile.  Please show us the actual code.
> >>
> >> Greetings,
> >>
> >> Jacob
> >> --
> >> "Very small. Go to sleep" - monster (not drooling)
> >
> > Hi Jacob
> >
> > thanks for that. I am avoiding having to flood this with tons of code. So here is a compiled example.
> >
> > package interface_p
> > is
>   (...)
> > end INTERFACE_P ;
> >
> 
> Is this happening only when you read from the shared location?
> I see the output
> local a:     1, local b:     2
> from the following program, compiled using GNAT GPL 2014 on a Mac:
> 
> With Ada.Text_IO;
> with INTERFACE_P; use INTERFACE_P;
> procedure Test_Interface_P
> is
>     It : local_rec;
> begin
>     It := READ_RECORD;
>     
>     declare
>        use Ada;
>        package Xintio is new Text_IO.Integer_IO (sixteen_bits);
>     begin
>        Text_Io.Put ("local a:"); Xintio.Put (It.a);
>        Text_Io.Put (", local b:"); Xintio.Put (It.b);
>        Text_Io.New_Line;
>     end;
> 
> end Test_Interface_P;

Totally agree. Both you and Jacob are correct.

There must be something subtle in my definitions that I am missing.

Note the new code below which reflects the real code except the array of bytes is much larger. I hall keep digging and report back.

Thank you very much.

with SYSTEM ;
package mapping 
is

   type thirty_two_bits is range 0..(2**31)-1;
   for thirty_two_bits'size use 32 ;
   for thirty_two_bits'Alignment use 1 ;
   
   type byte_t is range 0..255 ;
   for byte_t'size use 8 ;
   for byte_t'alignment use 1 ;
   
   type byte_stream is array (0..3) of byte_t ;
   for byte_stream'Component_Size use 8 ;
   for byte_stream'Alignment use 1;
   
   MAPPED_ARRAY : byte_stream := ( 16#01#, 16#80#,16#0#, 16#0# ) ; 
   
   MAPPED_ITEM : thirty_two_bits  ;
   for MAPPED_ITEM use at MAPPED_ARRAY'Address ; 
   MAPPED_ITEM_ADDRESS : System.Address := MAPPED_ITEM'Address ;

end mapping ;

with mapping ;

package interface_p
is

   type thirty_two_bits is range 0..(2**31)-1;
   for thirty_two_bits'size use 32 ;
   for thirty_two_bits'Alignment use 1 ;

   type sixteen_bits is range 0..(2**16)-1 ;
   type fourteen_bits is range 0..(2**14)-1;
   type ten_bits is range 0..(2**10)-1;
   type padding_bits is range 0..(2**8)-1 ;

   type rec is record
      a: fourteen_bits ;
      b: ten_bits ;
      padding : padding_bits ;
   end record ;

   for rec use
   record
      a at 0 range 0..13 ;
      b at 0 range 14..23 ;
      padding at 0 range 24..31;
   end record ;
   for rec'size use 32;
   for rec'alignment use 1;

   subtype local_fourteen_bits is sixteen_bits range 0 .. (2 ** 14)-1;
   subtype local_ten_bits is sixteen_bits range 0 .. (2 ** 10)-1;
   type local_rec is record
      a : local_fourteen_bits ;
      b : local_ten_bits ;
   end record;

   for local_rec use
   record
      a at 0 range 0 .. 13 ;
      b at 2 range 0 .. 9 ;
   end record;

   for local_rec'size use 32 ;
   for local_rec'Alignment use 1 ;
   
   MAPPED_ITEM : thirty_two_bits ;
   for MAPPED_ITEM'Address use mapping.MAPPED_ITEM_ADDRESS ;

   VAR_REC : rec ;
   for VAR_REC use at MAPPED_ITEM'Address ; 

   -- I explicitly assign here but in actual application it maps onto a 32 bit
   -- record in memory. I have deliberately changed in order to avoid adding
   -- tons of irrelevant code.


   function READ_RECORD
   return local_rec ;

end interface_p ;


In the system, the mapping is to an array of bytes populated in memory and then mapped. 

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jacob Sparre Andersen]

Lucas Redding <lucas.redding@gmail.com> writes:

>    type thirty_two_bits is range 0..(2**31)-1;

I only count 31 bits...

Greetings,

Jacob
-- 
»In Ada you model the problem space, not the solution space.«
                                                     -- Robert I. Eachus

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Jacob Sparre Andersen]

Lucas Redding wrote:

> There must be something subtle in my definitions that I am missing.

The error could also be in your test driver, which you don't include.

Or it could be because you have forgotten to pack your byte array.

Greetings,

Jacob
-- 
Rent-a-Minion Inc. Because good help is so hard to find.

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Tuesday, September 22, 2015 at 7:45:36 PM UTC+1, Jacob Sparre Andersen wrote:
> Lucas Redding wrote:
> 
> > There must be something subtle in my definitions that I am missing.
> 
> The error could also be in your test driver, which you don't include.
> 
> Or it could be because you have forgotten to pack your byte array.
> 
> Greetings,
> 
> Jacob
> -- 
> Rent-a-Minion Inc. Because good help is so hard to find.

All,

I can report back having resolved the issue by upgrading to the GNAT 2015 toolchain, or rather after upgrading to the 2015 toolchain the problem went away.

I tried on both toolchains (2013/2015) repeatedly just in case it was me, but I am now sure that the upgrade resolves the issue.

Whether it was a subtle bug that has now been fixed I can't say. 

Many thanks to all for your time and help in resolviong the issue.

Cheers

Lucas

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Dmitry A. Kazakov]

On Mon, 21 Sep 2015 04:12:44 -0700 (PDT), Lucas Redding wrote:

> In fact I am stumbling on portability of the rep clauses.

Which is an oxymoron. Representation clauses are meant to make the code
non-portable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Lucas Redding]

On Monday, September 21, 2015 at 5:49:02 PM UTC+1, Dmitry A. Kazakov wrote:
> On Mon, 21 Sep 2015 04:12:44 -0700 (PDT), Lucas Redding wrote:
> 
> > In fact I am stumbling on portability of the rep clauses.
> 
> Which is an oxymoron. Representation clauses are meant to make the code
> non-portable.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Thanks for pointing that out Dimitri

Come to think of it you are right.

However it depends what and where you want to port.

In my case I wish to port the same application and same data to a different compiler. In this case the rep clause is essential for the port. So like life itself, it is only meaningful if within context.

;¬)

Re: Addressing in Object Ada v/s GNAT (2013) showing Vast Differences

[Randy Brukardt]

"Lucas Redding" <lucas.redding@gmail.com> wrote in message 
news:9aa08966-6072-4d35-9089-d404a5ff1a43@googlegroups.com...
>On Monday, September 21, 2015 at 5:49:02 PM UTC+1, Dmitry A. Kazakov wrote:
>> On Mon, 21 Sep 2015 04:12:44 -0700 (PDT), Lucas Redding wrote:
>>
>> > In fact I am stumbling on portability of the rep clauses.
>>
>> Which is an oxymoron. Representation clauses are meant to make the code
>> non-portable.
>...
>Thanks for pointing that out Dimitri
>
>Come to think of it you are right.
>
>However it depends what and where you want to port.

Exactly.

>In my case I wish to port the same application and same data to a different 
>compiler.
> In this case the rep clause is essential for the port. So like life 
> itself, it is only
> meaningful if within context.

Different compiler on the same target, you mean (the last part is critical). 
We used rep clauses to increase portability between Ada compilers with Claw, 
because they eliminated the differences between the compilers and ensure 
that the types actually match the Windows API.

Of course, those rep clauses aren't useful on some other target (even 64-bit 
Windows would be an issue in some cases). But then again, neither is Claw. 
:-)

                                    Randy.