From 16 bit to 32

From 16 bit to 32

[Scott Loyd]

Hi all, 
This is probably a silly question but I have to ask. I have a large legacy application written primarily in Ada with some machine code for interfacing with an old 16 bit 1750A processor. I would like to take this code and execute it on 32 bit linux. I know that the machine code must be replaced. My question is for references to address types in the Ada code, is there a way to get around manually fixing all the record layout specifications and the like using a compiler configuration or pragma or (other)? Can I save a little work or do I need to brute force recode everything?

type A is record
   Address : System.Address;
end record;

for type A use record
   -- Change this???
   --Address at 0 range 0..15;
   Address at 0 range 0..31
end record;

Re: From 16 bit to 32

[Adam Beneschan]

On Monday, January 14, 2013 12:21:38 PM UTC-8, Scott Loyd wrote:
> Hi all, 
> 
> This is probably a silly question but I have to ask. I have a large legacy application written primarily in Ada with some machine code for interfacing with an old 16 bit 1750A processor. I would like to take this code and execute it on 32 bit linux. I know that the machine code must be replaced. My question is for references to address types in the Ada code, is there a way to get around manually fixing all the record layout specifications and the like using a compiler configuration or pragma or (other)? Can I save a little work or do I need to brute force recode everything?
> 
> 
> 
> type A is record
>    Address : System.Address;
> end record;
> 
> for type A use record
>    -- Change this???
>    --Address at 0 range 0..15;
>    Address at 0 range 0..31
> end record;

I don't think you'll be able to get around changing everything.  If you give a representation clause for a record component that isn't big enough to hold the component, the program won't compile.  Maybe there's an Ada compiler with an option to ignore representation clauses, but I don't know of any.

The question I think you should ask, though, is: why do you need a representation clause?  Representation clauses are useful if the type will be communicated with the "outside" world--e.g. if it will be passed to a library routine not written in Ada, or perhaps written to a file where the format of the file is dictated by some other specification.  But if your program is doing that, then changing from a 16- to a 32-bit address type will cause other problems, since you'll be violating the specifications or the expectations of other programs or libraries that look at that record.  If those other programs or libraries, or outside specifications, have also changed, then it shouldn't be surprising that you'd need to change all the representation clauses.

On the other hand, if there aren't any "outside" programs or libraries or specifications dictating the format of the record, then maybe there's no good reason to have a representation clause, and you should consider just deleting them instead of changing them.  I really don't know.  I'd have to know more about the application, and I could have missed some reasons why a representation clause might be needed.

                         -- Adam 

Re: From 16 bit to 32

[Scott Loyd]

I think the representation clauses were originally used as a debugging aid so they knew where all the right bits were instead of worrying about how pragma pack would arrange things, and I think the addresses were grouped in as a matter of completeness. 

I don't see any reason to keep them around from where I am standing either so I may just remove them all as you suggested.

Re: From 16 bit to 32

[Georg Bauhaus]

Adam Beneschan <adam@irvine.com> wrote:

> I don't think you'll be able to get around changing everything.  If you
> give a representation clause for a record component that isn't big enough
> to hold the component, the program won't compile.  Maybe there's an Ada
> compiler with an option to ignore representation clauses, but I don't know of any.

-gnatI is it for GNAT. Caveats apply.

Re: From 16 bit to 32

[Adam Beneschan]

On Monday, January 14, 2013 4:14:26 PM UTC-8, Georg Bauhaus wrote:

> 
> > I don't think you'll be able to get around changing everything.  If you
> > give a representation clause for a record component that isn't big enough
> > to hold the component, the program won't compile.  Maybe there's an Ada
> > compiler with an option to ignore representation clauses, but I don't know of any.
> 
> -gnatI is it for GNAT. Caveats apply.

(The last letter is upper-case I, for those who are reading this in a font that makes it look exactly like lower-case L.)

Yes, I wasn't aware of that.  It looks like something the OP could use--*temporarily*.  It still means using non-standard Ada, in effect, so even if this helps compile and test some stuff in the short term, I'd still recommend modifying or removing the rep clauses.

                               -- Adam

Re: From 16 bit to 32

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:d3fc4db9-a940-47c2-91c3-84b457d733a4@googlegroups.com...
...
>I don't think you'll be able to get around changing everything.  If you 
>give a representation
>clause for a record component that isn't big enough to hold the component, 
>the program
>won't compile.  Maybe there's an Ada compiler with an option to ignore 
>representation clauses,
>but I don't know of any.

GNAT has (or had?) such an option. (I saw it Friday when I was looking 
through the list of GNAT options to see what options I need to compile with 
on my new server. Let's see, I only have an older GNAT manual on this 
computer, and it says -gnatI means "Ignore representation clauses". I'd 
check that out on your own copy of GNAT before using, but it might be a good 
way for the OP to determine what other things that they need to change.

It specifically exists for a case like the OP's. According to the 
documentation:

-gnatI
Ignore representation clauses. When this switch is used, all representation 
clauses are treated as comments. This is useful when initially porting code 
where you want to ignore rep clause problems, and also for compiling foreign 
code (particularly for use with ASIS).

You could ask why your compiler and my compiler don't have such a useful 
switch. :-) But surely there is a compiler than has it.

                                                  Randy.

Re: From 16 bit to 32

[Jeffrey Carter]

On 01/14/2013 05:34 PM, Adam Beneschan wrote:
>
> Yes, I wasn't aware of that.  It looks like something the OP could
> use--*temporarily*.  It still means using non-standard Ada, in effect, so
> even if this helps compile and test some stuff in the short term, I'd still
> recommend modifying or removing the rep clauses.

Even being able to ignore the representation clauses, the OP still has the 
problem of why there are addresses in the code. The use of addresses is likely 
to be a much more difficult portability issue than unnecessary representation 
clauses.

-- 
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Re: From 16 bit to 32

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> It specifically exists for a case like the OP's. According to the 
> documentation:
>
> -gnatI
> Ignore representation clauses. When this switch is used, all representation 
> clauses are treated as comments. This is useful when initially porting code 
> where you want to ignore rep clause problems, and also for compiling foreign 
> code (particularly for use with ASIS).

You can use it for experiments, but it's a dangerous switch.  If you
have nonportable code that you need to port, it's better to dig in
and fix it.  I rewrote the above documentation a while back, to make
it sound a bit less appealing.  The latest version says:

 `-gnatI'
      Ignore representation clauses. When this switch is used,
      representation clauses are treated as comments. This is useful
      when initially porting code where you want to ignore rep clause
      problems, and also for compiling foreign code (particularly for
      use with ASIS). The representation clauses that are ignored are:
      enumeration_representation_clause, record_representation_clause,
      and attribute_definition_clause for the following attributes:
      Address, Alignment, Bit_Order, Component_Size, Machine_Radix,
      Object_Size, Size, Small, Stream_Size, and Value_Size.  Note that
      this option should be used only for compiling - the code is likely
      to malfunction at run time.

We sometimes use it when running CodePeer, for example -- that's what
"only for compiling" means.

I also fixed some bugs.  I think it was ignoring things like
"for T'Write use...", which makes even less sense.  Or something
like that.

- Bob

Re: From 16 bit to 32

[Scott Loyd]

I am stuck with gnatmake 4.1.2 right now which doesn't seem to have the switch. I may be able to upgrade at some point to a more recent version and try it out, but I am going to press with removing the rep clauses for now. Thanks for the help everyone!

Re: From 16 bit to 32

[J-P. Rosen]

Le 15/01/2013 16:47, Scott Loyd a �crit :
> I am stuck with gnatmake 4.1.2 right now which doesn't seem to have
> the switch. I may be able to upgrade at some point to a more recent
> version and try it out, but I am going to press with removing the rep
> clauses for now. Thanks for the help everyone!
> 
Note that AdaControl comes with a sed script to comment out repr.
clauses. You can pick it from Sourceforge, or I'll send it to you.

In the context of AdaControl, we use it when the code is compiled with
another compiler, but we need a quick port to Gnat to be able to use
AdaControl. Except for rules that relate to repr. clauses, it has no effect.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: From 16 bit to 32

[Stephen Leake]

Scott Loyd <loyd.scott@gmail.com> writes:

> I think the representation clauses were originally used as a debugging
> aid so they knew where all the right bits were instead of worrying
> about how pragma pack would arrange things, and I think the addresses
> were grouped in as a matter of completeness.

If you have to worry about "where the bits are", you must be sharing
those bits with something outside Ada.

> I don't see any reason to keep them around from where I am standing
> either so I may just remove them all as you suggested.

This is not consistent with what you said above!

Unless the original authors were worrying for no reason, always
possible.

-- 
-- Stephe