From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ccbe747051ad7991 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!newsfeed.freenet.de!newsfeed0.kamp.net!newsfeed.kamp.net!newsfeed.straub-nv.de!aioe.org!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: Telesoft Unchecked_Conversion Date: Tue, 06 May 2008 22:40:18 -0700 Organization: None to speak of Message-ID: <87ve1qu0xp.fsf@kvetch.smov.org> References: <0e4e0940-3495-40fb-bd9f-0c05e7a67f9e@d1g2000hsg.googlegroups.com> NNTP-Posting-Host: aVIvKdUSjN4PsAbmZ6BGcQ.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@aioe.org Cancel-Lock: sha1:DHVMjVMFYqQE126ivDKDjuOscW0= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Xref: g2news2.google.com comp.lang.ada:5731 Date: 2008-05-06T22:40:18-07:00 List-Id: "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) Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"