comp.lang.ada
 help / color / mirror / Atom feed
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Telesoft Unchecked_Conversion
Date: Tue, 06 May 2008 22:40:18 -0700
Date: 2008-05-06T22:40:18-07:00	[thread overview]
Message-ID: <87ve1qu0xp.fsf@kvetch.smov.org> (raw)
In-Reply-To: 0e4e0940-3495-40fb-bd9f-0c05e7a67f9e@d1g2000hsg.googlegroups.com

"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"



      reply	other threads:[~2008-05-07  5:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-07  1:10 Telesoft Unchecked_Conversion jason.height
2008-05-07  5:40 ` Keith Thompson [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox