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

[Lucas Redding <lucas.redding@gmail.com>]

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