Telesoft Unchecked_Conversion

Telesoft Unchecked_Conversion

[jason.height]

Ok, here goes.

I doubt that anyone can help me out here, but i am going to ask anyhow
(this is my last minute hail mary pass)

I am looking at a porting exercise moving from v1a of the Telesoft
SunOS e68k cross compiler moving to GNAT.

Things look ok EXCEPT with the messages that are sent over the LAN. I
was hoping that the ported application could be written such that it
could communicate with the older software. Unfortunately the LAN
messages are binary records which have been converted to byte arrays
using Telesofts implementation of Unchecked_Conversion.

A few of these have representation clauses which i have therefore been
able to mimic in my own procedures.

Some of these do not have any representation clause, leaving it up to
the compiler to define the layout. Which it seems to do in some non-
sensical way!

Here is my hail mary:

Does anyone have access to the algorithm that the Telesoft compiler
used to layout its records in memory when using Unchecked_Conversion?

My thinking is that it would be easier to implement the algorithm,
rather than reverse engineering each record.

Jason

Re: Telesoft Unchecked_Conversion

[Keith Thompson]

"jason.height@gmail.com" <jason.height@gmail.com> writes:
> Ok, here goes.

> I doubt that anyone can help me out here, but i am going to ask anyhow
> (this is my last minute hail mary pass)
>
> I am looking at a porting exercise moving from v1a of the Telesoft
> SunOS e68k cross compiler moving to GNAT.
>
> Things look ok EXCEPT with the messages that are sent over the LAN. I
> was hoping that the ported application could be written such that it
> could communicate with the older software. Unfortunately the LAN
> messages are binary records which have been converted to byte arrays
> using Telesofts implementation of Unchecked_Conversion.
>
> A few of these have representation clauses which i have therefore been
> able to mimic in my own procedures.
>
> Some of these do not have any representation clause, leaving it up to
> the compiler to define the layout. Which it seems to do in some non-
> sensical way!
>
> Here is my hail mary:
>
> Does anyone have access to the algorithm that the Telesoft compiler
> used to layout its records in memory when using Unchecked_Conversion?
>
> My thinking is that it would be easier to implement the algorithm,
> rather than reverse engineering each record.

As it happens, I used to work for TeleSoft (before they went through
several mergers and finally decided they were no longer in need of my
services), and I've worked on that code.  But it's been a very long
time, and I don't have access to the sources.

But as I recall, by default it would sort the record components by
alignment and then allocate them as tightly as possible subject to
their alignment constraints.  (In an early release, it used an
unstable sort, but that was changed, probably before the version you
have.)  So all components with the strictest alignment should be
allocated first, in order of declaration, followed by all components
with the next-strictest alignment, and so on.

An implementation-defined pragma Preserve_Layout would cause
components to be allocated in their declared order.

As I said, it's been a very long time since I've worked on this; I've
probably gotten some of this wrong.  You'll probably need to play
around with it a bit to make sure of all this.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"