Ada Plattform Independence

Ada Plattform Independence

[patrick.gunia]

Hi all,

I´m currently working on an analysis of an Ada-System with focus on
the current state of plattform-independence. As my experiences wirh
porting Ada-software to different operating system is limited and
close to zero, I´d like to ask, which conecpts of the langiage might
cause problems. I don´t mean aspects like including plattform-
dependent libraries or calling system-functions from Ada-Code. I know
that this will lead to portation problems. I´m more interested in
problems with the Ada language itself. For example use of
represantation clauses or I/O statements. I´ve been searching a while
to find a listing of parts of the Ada standard which might cause
problems, but didn´t succeed. So I hope, that you can help.

Thanks,
Patrick

Re: Ada Plattform Independence

[Jean-Pierre Rosen]

patrick.gunia@googlemail.com a �crit :
> Hi all,
> 
> I�m currently working on an analysis of an Ada-System with focus on
> the current state of plattform-independence. As my experiences wirh
> porting Ada-software to different operating system is limited and
> close to zero, I�d like to ask, which conecpts of the langiage might
> cause problems. 

Ada allows writing portable programs, however it does not guarantee in
itself that programs will be portable. The language purposedly allowed
to depend on the peculiarities of the target. Care is still needed to
achieve portable code. Common difficulties include:

-Relying on the characteristics of predefined types (Integer and Duration)

-Differences on the implementation of Address. Some compilers (mainly
Ada83) defined Address as an integer type, while current common practice
is to make it private, which causes problems if people are doing
(uncontrolled) address arithmetic

-Representation clauses. Compilers vary in their support of
representation clauses, sometimes for good reasons: some representation
clauses that are acceptable on some targets would lead to unreasonable
code on a different hardware. Representation clauses may also depend on
predefined types; f.e., if you have a record field of type Duration, you
may have problems when moving a program from an implementation where
Duration is 32 bits to one where Duration is 64 bits

-Outrageously wrong code written by people who write "C-in-Ada", with
lots of unchecked conversions between pointers and addresses.

In practice, most portability problems are rooted in insufficient
training of the people who wrote the code initially.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada Plattform Independence

[patrick.gunia]

On 11 Mrz., 16:37, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> patrick.gu...@googlemail.com a écrit :
>
> > Hi all,
>
> > I´m currently working on an analysis of an Ada-System with focus on
> > the current state of plattform-independence. As my experiences wirh
> > porting Ada-software to different operating system is limited and
> > close to zero, I´d like to ask, which conecpts of the langiage might
> > cause problems.
>
> Ada allows writing portable programs, however it does not guarantee in
> itself that programs will be portable. The language purposedly allowed
> to depend on the peculiarities of the target. Care is still needed to
> achieve portable code. Common difficulties include:
>
> -Relying on the characteristics of predefined types (Integer and Duration)
>
> -Differences on the implementation of Address. Some compilers (mainly
> Ada83) defined Address as an integer type, while current common practice
> is to make it private, which causes problems if people are doing
> (uncontrolled) address arithmetic

I also thought of this aspect. I have the big advantage that the
software is only executed on a very limited range of hardware
configurations. Using the same compiler implementation for different
plattforms (for example GNAT) would solve this problem?

> -Representation clauses. Compilers vary in their support of
> representation clauses, sometimes for good reasons: some representation
> clauses that are acceptable on some targets would lead to unreasonable
> code on a different hardware. Representation clauses may also depend on
> predefined types; f.e., if you have a record field of type Duration, you
> may have problems when moving a program from an implementation where
> Duration is 32 bits to one where Duration is 64 bits

Same aspect as above, when I use GNAT on GNU/Linux and Windows to
compile this code, it should use the same implementation of Duration?

> -Outrageously wrong code written by people who write "C-in-Ada", with
> lots of unchecked conversions between pointers and addresses.

The code uses unchecked_conversions to call imported C-functions. I don
´t think that I can avoid this problem. Though the software is always
executed on 32-Bit systems, thus this should also work out, or am I
getting something terribly wrong here?

> In practice, most portability problems are rooted in insufficient
> training of the people who wrote the code initially.
> --
> ---------------------------------------------------------
>            J-P. Rosen (ro...@adalog.fr)
> Visit Adalog's web site athttp://www.adalog.fr

Last but not least,
thanks for your answer!
Patrick

Re: Ada Plattform Independence

[Martin]

On Mar 11, 2:04 pm, "patrick.gu...@googlemail.com"
<patrick.gu...@googlemail.com> wrote:
> Hi all,
>
> I´m currently working on an analysis of an Ada-System with focus on
> the current state of plattform-independence. As my experiences wirh
> porting Ada-software to different operating system is limited and
> close to zero, I´d like to ask, which conecpts of the langiage might
> cause problems. I don´t mean aspects like including plattform-
> dependent libraries or calling system-functions from Ada-Code. I know
> that this will lead to portation problems. I´m more interested in
> problems with the Ada language itself. For example use of
> represantation clauses or I/O statements. I´ve been searching a while
> to find a listing of parts of the Ada standard which might cause
> problems, but didn´t succeed. So I hope, that you can help.
>
> Thanks,
> Patrick


Hi Patrick,

I've ported Ada code from 68k to i386 from no-OS to VxWorks to Win32
and in each case the biggest hurdle has been 'how good is the original
code'.

Assumptions on the sizes and ranges, esp. of the prefined types (esp.
Integer), can cause problems.

Fixed-point numbers are different between revisions of the language
(e.g. Ada83 v Ada95 v Ada2005) but should be portable enough between
different ports using the same language. Providing your not dependent
on a particular underlying representation being used.

The 'favourite' gotcha is usually using non-standard additions to
standard packages. E.g. XD-Ada extended the contents of package
'System' to include 8/16/32-bit signed/unsigned integer. Easy to deal
with - just define a package called 'XDAda_System' and defines
subtypes of the types in Interfaces in it. Then do a globel find/
replace for all occurences of 'with System' (and 'use'!) and you're
90% there.

I ported 45kSLOC from no-OS XD-Ada to GNAT GPL 2008 Wintel in an hour
the other week**.

Cheers
-- Martin

** Where 'ported' means getting a clean compilation / link and not
actually running it!

Re: Ada Plattform Independence

[Jean-Pierre Rosen]

patrick.gunia@googlemail.com a �crit :
>> -Differences on the implementation of Address. Some compilers (mainly
>> Ada83) defined Address as an integer type, while current common practice
>> is to make it private, which causes problems if people are doing
>> (uncontrolled) address arithmetic
> 
> I also thought of this aspect. I have the big advantage that the
> software is only executed on a very limited range of hardware
> configurations. Using the same compiler implementation for different
> plattforms (for example GNAT) would solve this problem?
AFAIK, GNAT (and presumably most Ada95 compilers, since it is
implementation advice) define Address as private

>> -Representation clauses. Compilers vary in their support of
>> representation clauses, sometimes for good reasons: some representation
>> clauses that are acceptable on some targets would lead to unreasonable
>> code on a different hardware. Representation clauses may also depend on
>> predefined types; f.e., if you have a record field of type Duration, you
>> may have problems when moving a program from an implementation where
>> Duration is 32 bits to one where Duration is 64 bits
> 
> Same aspect as above, when I use GNAT on GNU/Linux and Windows to
> compile this code, it should use the same implementation of Duration?
This might depend on the target. But why are you asking? Just try it!
(i.e. if there is a problem, it won't compile; no risk at run-time)

>> -Outrageously wrong code written by people who write "C-in-Ada", with
>> lots of unchecked conversions between pointers and addresses.
> 
> The code uses unchecked_conversions to call imported C-functions. I don
> �t think that I can avoid this problem. Though the software is always
> executed on 32-Bit systems, thus this should also work out, or am I
> getting something terribly wrong here?
Unchecked_Conversion was commonly used in Ada83. Using pragma Import and
Interfaces.C is preferred since Ada95. I would suggest migrating the
code to use these features.


-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr