Porting ADA source

Porting ADA source

[Giacomo Polizzi]

Hello,

I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
compiler to a Linux pc machine with gnat (gcc) compiler.

The task is to have, if possible, an unique source code compilable on both
platforms but there are the following problems:

1) some system packages that execute the same kind of operations have
different names in the two compilers

2) some system functions (for example mathematical function) have different
names in the two compilers

3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
always possible to use the same standard type (for example the long type is
64 bits on Alpha and 32 bits on pc)

4) the standard type (long long) used by gcc on pc to solve the previous
problem is not supported by the DEC ADA compiler

5) the different word length modifies some structure length used to define
interface messages with other external programs

Is there something like #IFDEF of C language that I can use in ADA ?

Is there any other kind of solution for the above problems ?

Thanks to everybody

Giacomo

Re: Porting ADA source

[Dale Stanbrough]

Giacomo Polizzi wrote:

> Hello,
> 
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
> 
> The task is to have, if possible, an unique source code compilable on both
> platforms but there are the following problems:

One solution is to just have a package spec with different bodies
for each host. You could inline the code so it wouldn't be any slower.
You would have to use your configuration tools to help you choose one
or the other.

 
> 1) some system packages that execute the same kind of operations have
> different names in the two compilers



> 2) some system functions (for example mathematical function) have different
> names in the two compilers
> 
> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
> always possible to use the same standard type (for example the long type is
> 64 bits on Alpha and 32 bits on pc)

If you use type long_integer, then you could replace any types with new
type defined by the range needed.

e.g.

   type my_long_integer is range -2**(63)..2**63-1;

Try...

   with ada.text_Io; use ada.text_Io;

   procedure demo is
      type my_long_integer is range -2**(63)..2**63-1;

   begin
      Put_line (integer'image (my_long_integer'size));
   end;


i ran this and got "64" on a 32 bit PPC based mac, so it seems to work.


> 4) the standard type (long long) used by gcc on pc to solve the previous
> problem is not supported by the DEC ADA compiler

see above...


> 5) the different word length modifies some structure length used to define
> interface messages with other external programs

If you need to talk to other programs then you should be defining the 
size|(range of values) for the fields in the structures without using
"long" (or Long_Integer).

Define your own types (with size clauses if needed) and then use those
in your program.


> Is there something like #IFDEF of C language that I can use in ADA ?

Not in Ada. Implementations may support a feature like this, but it's 
not part of the language (e.g. gnat does). Very often you can get around
it and have a better structure for your code.


> Is there any other kind of solution for the above problems ?
> 
> Thanks to everybody
> 
> Giacomo

dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Porting ADA source

[Adrian Knoth]

Giacomo Polizzi <mio@.> wrote:

First I suggest you should put some kind of email-address in this header.

> I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.

Second you should realize that it is called "Ada".

> The task is to have, if possible, an unique source code compilable on both
> platforms but there are the following problems:

A solution might be a portable-package.

> 1) some system packages that execute the same kind of operations have
> different names in the two compilers

Write wrappers around it in the portable-package.

> 2) some system functions (for example mathematical function) have different
> names in the two compilers

Write wrappers around it in the portable-package.

> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
> always possible to use the same standard type (for example the long type is
> 64 bits on Alpha and 32 bits on pc)

Use your own types derived either from the largest type possible (range)
or use mod-types.

   type stuff is mod 2**64;


> 4) the standard type (long long) used by gcc on pc to solve the previous
> problem is not supported by the DEC ADA compiler

Don't rely on any special compiler behaviour, it might not be available
on your target. Use the language specification instead.

> 5) the different word length modifies some structure length used to define
> interface messages with other external programs

You lost. It's a well-known drawback in the C-programming language
that the memory layout of structs is not defined. Also for Ada it
is not specified, but when using representation clauses you can
force the compiler to make it your way, thus giving you a common
interface.

Ergo: you don't know how the compiler, used for compiling the external
C-library, arranges the structs in memory. And because you don't know
you can't build an Ada-Interface for that. The only thing you can
do is to take the headers and the same C-compiler and figure out how
it is done for that particular team (tool-chain). You cannot tell how
it will behave on different systems.

And you'll surely have to put these differences into the portable-package.
Keep in mind that different flags used for the C-compiler may result
in different memory-layout of your structs. 

I suggest a complete rewrite of the world with RepClauses ;)


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Geht die Sonne auf im Westen, mu�t du deinen Kompa� testen

Re: Porting ADA source

[Marin David Condic]

Part of the problem seems to be that the OP is working with existing 
code that nobody apparently thought needed to be portable. Trying to 
dramatically restructure the code at this stage starts becoming 
problematic. Portability can be achieved, but only if you work really 
hard at it from the start. Of course there might be easier fixes to the 
problem now if Ada had some kind of conditional compilation directive - 
but since those are viewed as "Morally Evil" I guess people stuck with 
practical problems should just go use a different language. :-)

MDC



Dale Stanbrough wrote:
> 
> 
> One solution is to just have a package spec with different bodies
> for each host. You could inline the code so it wouldn't be any slower.
> You would have to use your configuration tools to help you choose one
> or the other.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting Ada source

[Jacob Sparre Andersen]

Giacomo Polizzi wrote:

> I have to port an Ada program from an Unix DEC Alpha machine with a
> DEC Ada compiler to a Linux pc machine with gnat (gcc) compiler.
> 
> The task is to have, if possible, an unique source code compilable
> on both platforms but there are the following problems:
> 
> 1) some system packages that execute the same kind of operations
> have different names in the two compilers

This is probably because the DEC Ada compiler is an Ada 83 compiler,
whereas GNAT primarily is an Ada 95 compiler (I think it may have an
Ada 83 mode).

> 2) some system functions (for example mathematical function) have
> different names in the two compilers

Same as above.

> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it
> is not always possible to use the same standard type (for example
> the long type is 64 bits on Alpha and 32 bits on pc)

If the program has been written in terms of the requirements and not
just in term of standard data types, this is unlikely to create
significant problems.  If the program depends on the actual range of
the type Integer, then you may have to rework some of the code.  But
based on previous experience reports on porting of code, I will guess
that it isn't that much work.

> 4) the standard type (long long) used by gcc on pc to solve the
> previous problem is not supported by the DEC Ada compiler

That doesn't matter if you just declare your integer types in terms of
the requirements.

> 5) the different word length modifies some structure length used to
> define interface messages with other external programs

I don't really know much about how representation clauses were done in
Ada 83, so I can't help you here.

> Is there something like #IFDEF of C language that I can use in Ada?

Fortunately not.  Unfortunately there are not a more sensible method
of conditional compilation built into the language either.

Jacob
-- 
"I'm going as a barrel of toxic waste!"

Re: Porting ADA source

[Steve]

"Giacomo Polizzi" <mio@.mio> wrote in message
news:cdfu3s$k1a$1@e3k.asi.ansaldo.it...
> Hello,
>
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC
ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
>
> The task is to have, if possible, an unique source code compilable on both
> platforms but there are the following problems:
>
> 1) some system packages that execute the same kind of operations have
> different names in the two compilers
>
> 2) some system functions (for example mathematical function) have
different
> names in the two compilers

Have you considered obtaining GNAT for DEC Alpha Unix?  This may resolve
the different names issue.

>
> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
> always possible to use the same standard type (for example the long type
is
> 64 bits on Alpha and 32 bits on pc)
>
> 4) the standard type (long long) used by gcc on pc to solve the previous
> problem is not supported by the DEC ADA compiler

The basic answer here is: don't use the standard types.  Define your own
or use the definitions in the Interfaces package.  If you have a large base
or code using the predefined types, look for a tool to convert these to
your own definitions.

> 5) the different word length modifies some structure length used to define
> interface messages with other external programs
>

Use representation clauses to explicitly define structure layout the same on
both systems.

> Is there something like #IFDEF of C language that I can use in ADA ?
>
I believe GNAT has a pre-processor you could use, but I have never used it.

Steve
(The Duck)

> Is there any other kind of solution for the above problems ?
>
> Thanks to everybody
>
> Giacomo
>
>

Re: Porting Ada source

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]


"Jacob Sparre Andersen" <sparre@nbi.dk> a �crit dans le message de news:pld62sdw2q.fsf@sparre.crs4.it...
> > 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it
> > is not always possible to use the same standard type (for example
> > the long type is 64 bits on Alpha and 32 bits on pc)
>
> If the program has been written in terms of the requirements and not
> just in term of standard data types, this is unlikely to create
> significant problems.  If the program depends on the actual range of
> the type Integer, then you may have to rework some of the code.  But
> based on previous experience reports on porting of code, I will guess
> that it isn't that much work.
>
<PLUG>
Moreover, you can change all references to Standard.Integer into -say- Interfaces.Integer_32 automatically with Adasubst. See
http://www.adalog.fr/compo2.htm
</PLUG>

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

Re: Porting ADA source

[Martin Dowie]

"Giacomo Polizzi" <mio@.mio> wrote in message
news:cdfu3s$k1a$1@e3k.asi.ansaldo.it...
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC
ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
>
> The task is to have, if possible, an unique source code compilable on both
> platforms but there are the following problems:
>
> 1) some system packages that execute the same kind of operations have
> different names in the two compilers

You could (possibly) keep the original package spec and then select either
the original package body or a new 'wrapper' package body at build time.


> 2) some system functions (for example mathematical function) have
different
> names in the two compilers

As 1)

> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
> always possible to use the same standard type (for example the long type
is
> 64 bits on Alpha and 32 bits on pc)
>
> 4) the standard type (long long) used by gcc on pc to solve the previous
> problem is not supported by the DEC ADA compiler
>
> 5) the different word length modifies some structure length used to define
> interface messages with other external programs

Don't use the standard types! They are a convience for writing q&d programs
and should never be used in production code.

You could look at "Adasubst" at http://www.adalog.fr/compo2.htm#Semtools
This can look through all your code and replace the offending
"Long_Long_Float"
with "My_Float" (or whatever you define).

Hope this helps!

Cheers

-- Martin

Re: Porting ADA source

[tmoran]

>if Ada had some kind of conditional compilation directive -
>but since those are viewed as "Morally Evil"
  Not "Morally Evil", just "Generally A Poor Solution".
In in the current OP's situation, he can use "renames" for his
differently named library packages/routines, representation clauses
to be explicit about layout of data structures, and problem-oriented,
rather than (obsolete) hardware-oriented types to specify the sizes
of integers, floats, etc.  ie, which is better:

#ifdef Alpha
  Y := Cosine(X);
#else
  Y := Cos(X);
#endif

vs
  function Cosine(X : Float) return Float renames Cos;
  ...
  Y := Cosine(X); -- original, unchanged, source

---------

#ifdef Alpha
  Accuracy,
  Distance_In_Centimeters : Integer; -- DEC Alpha 64 bits
#else
  Accuracy,
  Distance_In_Centimeters : Long_Integer; -- pc 64 bits
#endif

vs:

  type Accurate_Type is range -2**63 .. 2**63-1;
  -- global search and replace changes "Integer" to "Accurate_Type" ?
  Accuracy,
  Distance_In_Centimeters : Accurate_Type;

---------

In the case of structures for interprogram communication, of which
there typically aren't all that many, there's no way to avoid a rep
clause, even if conditional compilation was available.

  type Complicated_Structure_Type is record
    I,J : Accurate_Type;
    Flag: Boolean;
    X : Rough_Float;
    Y : Accurate_Float;
  end record;
-- added explicit representation clause
  for Complicated_Structure_Type use record -- be explicit
    I at 0 range 0 .. 63;
    J at 8 range 0 .. 63;
    Flag at 16 range 0 .. 7;
    X at 24 range 0 .. 31;
    Y at 28 range 0 .. 63;
  end record;

Re: Porting ADA source

[Wes Groleau]

Martin Dowie wrote:
> Don't use the standard types! They are a convience for writing q&d programs
> and should never be used in production code.

Advice that one could easily take too far.
I know of a major project where all sorts of
unnecessary code had to be written for handling text
because String and Integer were forbidden types!

-- 
Wes Groleau

Even if you do learn to speak correct English,
whom are you going to speak it to?
                     -- Clarence Darrow

Re: Porting ADA source

[Larry Kilgallen]

In article <qaydnYUv5oytv2HdRVn-pQ@gbronline.com>, Wes Groleau <groleau+news@freeshell.org> writes:
> Martin Dowie wrote:
>> Don't use the standard types! They are a convience for writing q&d programs
>> and should never be used in production code.
> 
> Advice that one could easily take too far.
> I know of a major project where all sorts of
> unnecessary code had to be written for handling text
> because String and Integer were forbidden types!

What is the advantage of forbidding "string" ?

Re: Porting ADA source

[Wes Groleau]

Larry Kilgallen wrote:
> What is the advantage of forbidding "string" ?

None that I know of.  But the powers that be when
the project started decreed that all predefined types
are non-portable, therefore all types must be subtyped
or derived from types created AND rep-spec'd for the
project.  Much of Standard and System was re-implemented
to support these types.  Character was the only predefined
type exempt (why was that different?), so arrays of Character
with "portable" index types were used instead of String.

Assigning string literals to these arrays was either
humorous or nerve-wracking, depending on how much
time pressure you were under.

Interestingly, string literals and character literals
were one of the Ada 95 conversion headaches.  :-)

-- 
Wes Groleau
http://groleau.freeshell.org/

Re: Porting ADA source

[Martin Dowie]

"Wes Groleau" <groleau+news@freeshell.org> wrote in message
news:qaydnYUv5oytv2HdRVn-pQ@gbronline.com...
> Martin Dowie wrote:
> > Don't use the standard types! They are a convience for writing q&d
programs
> > and should never be used in production code.
>
> Advice that one could easily take too far.
> I know of a major project where all sorts of
> unnecessary code had to be written for handling text
> because String and Integer were forbidden types!

AOL! :-)

Re: Porting ADA source

[Marin David Condic]

Well, you do present some constructive alternatives. I've just often 
found myself in the position of polishing a turd and "Quick & Dirty" can 
be an effective solution. It depends on how much work you want to put 
into it.

MDC

tmoran@acm.org wrote:

>   Not "Morally Evil", just "Generally A Poor Solution".
> In in the current OP's situation, he can use "renames" for his
> differently named library packages/routines, representation clauses
> to be explicit about layout of data structures, and problem-oriented,
> rather than (obsolete) hardware-oriented types to specify the sizes
> of integers, floats, etc.  ie, which is better:

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Marin David Condic]

Yeah, but a) Standard types are part of the language so they often get 
used, B) Saying "Don't do that..." when its already done doesn't really 
present a solution and C) Most programmers are of average to below 
average in skill level and experience so you have to make allowances for 
what they are *going* to do no matter how bad an answer it is. That's 
why I often argue for some of the "expedient" things like conditional 
compilation even if it isn't the "best" or most "pure" answer: It gives 
you a way of dealing with what *is* rather than what *should be*.

MDC



Steve wrote:
> 
> The basic answer here is: don't use the standard types.  Define your own
> or use the definitions in the Interfaces package.  If you have a large base
> or code using the predefined types, look for a tool to convert these to
> your own definitions.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Peter C. Chapin]

tmoran@acm.org wrote in news:bGUKc.133469$Oq2.23309@attbi_s52:

> #ifdef Alpha
>   Y := Cosine(X);
> #else
>   Y := Cos(X);
> #endif
> 
> vs
>   function Cosine(X : Float) return Float renames Cos;
>   ...
>   Y := Cosine(X); -- original, unchanged, source

I'm new to Ada so forgive me if I'm beating a dead horse here, but I'm not 
sure how this example solves the problem. If the Ada code is compiled in an 
environment where 'Cos' does not exist, won't the renaming declaration cause 
an error?

Peter

Re: Porting ADA source

[Martin Dowie]

Peter C. Chapin wrote:
> I'm new to Ada so forgive me if I'm beating a dead horse here, but
> I'm not sure how this example solves the problem. If the Ada code is
> compiled in an environment where 'Cos' does not exist, won't the
> renaming declaration cause an error?

The example is for the case where "Cos" is defined but the code
uses "Cosine". For the environment where "Cosine" already exists
you don't need the renames - you can control which version at
build time.

This can hidden with some sort of wrapper package for both platforms.

Cheers

-- Martin

Re: Porting ADA source

[Marin David Condic]

Right. The only problem being that you are suddenly into rather 
significantly changing the software. You're repackaging things and 
restructuring things and you've got to try to set up some kind of 
configuration control process to accommodate two builds. If you are 
starting from scratch and you know you have to maintain portability this 
might be a valid approach (though I've seen this get waaaaayyy overblown 
too!)

But the mission is to take code body X and get it from its existing 
platform onto another - not redesign the system. Time spent reorganizing 
the code and setting up a build process does not directly move that 
mission forward. Hence, it would be nice to get some kind of quick and 
dirty fix that doesn't mean spending excessive time reworking the 
existing product. A conditional compilation directive can be that sort 
of fix. Its just that it is viewed dimly as a sub-optimal formal 
technique. Oh well....

MDC


Martin Dowie wrote:
> 
> The example is for the case where "Cos" is defined but the code
> uses "Cosine". For the environment where "Cosine" already exists
> you don't need the renames - you can control which version at
> build time.
> 
> This can hidden with some sort of wrapper package for both platforms.
> 
> Cheers
> 
> -- Martin
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Frank J. Lhota]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:cdhesj$bro$1@hercules.btinternet.com...
> AOL! :-)

America Online?

Re: Porting ADA source

[Vinzent 'Gadget' Hoefler]

Frank J. Lhota wrote:

>"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
>news:cdhesj$bro$1@hercules.btinternet.com...
>> AOL! :-)
>
>America Online?

<URL:http://info.astrian.net/jargon/terms/a/AOL.html>


Vinzent.

Re: Porting ADA source

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: But the mission is to take code body X and get it from its existing 
: platform onto another - not redesign the system.

Uhm, "But *if* the mission is to take code body X and get it from its
existing  platform onto another *very similar* platform *once*, and
then *be done with it forever*", o.K.. And hopefully noone else will
have to look at the modified code again. But how often is this the case
with code that is actually used?


Georg

Re: Porting ADA source

[Peter Amey]

Giacomo Polizzi wrote:
> Hello,
> 
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
> 
[snip]

Like others have said, the problem is best avoided by design for 
portability.  However, that doesn't help if it wasn't!

I haven't seen a mention of the rather excellent GnatPrep which might 
just help:

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Preprocessing-Using-gnatprep.html

Peter

Re: Porting ADA source

[Martin Krischik]

Wes Groleau wrote:

> Larry Kilgallen wrote:
>> What is the advantage of forbidding "string" ?
> 
> to support these types.  Character was the only predefined
> type exempt (why was that different?), so arrays of Character
> with "portable" index types were used instead of String.

Because Character and Wide_Character are the only types which can't be
expressed in Ada itself. There are some form of enumeration but not all
values are legal Ada.

But you knew that, didn't you?

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Porting ADA source

[Jeffrey Carter]

Marin David Condic wrote:

> But the mission is to take code body X and get it from its existing 
> platform onto another - not redesign the system. 

Maybe. But the mission is probably to make the SW portable, so a certain 
amount of redesign is probably acceptable.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: Porting ADA source

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:40FD0932.5080604@noplace.com...
...
> But the mission is to take code body X and get it from its existing
> platform onto another - not redesign the system. Time spent reorganizing
> the code and setting up a build process does not directly move that
> mission forward. Hence, it would be nice to get some kind of quick and
> dirty fix that doesn't mean spending excessive time reworking the
> existing product. A conditional compilation directive can be that sort
> of fix. Its just that it is viewed dimly as a sub-optimal formal
> technique. Oh well....

If it is a long-lived system (and this one appears to be) a quick and dirty
solution simply sets the developers up for many years of pain in
maintenance. It's better to do it right the first time (or, as in this
case - a very common one, the second time).

Case in point: when we ported Janus/Ada to the U2200 computers, we had to
change a lot of assumptions about the sizes of things. (We had of course
assumed character = byte = 8 bits, and of the U2200 was a 36-bit word
machine.) Rather than simply coding a different set of assumptions, we
decided to restructure everything so that the compiler depended on a small
set of packages that encoded host and target information. That eliminated
future redos for similar issues. I'm sure the customer would have been
happier in the short run if we hadn't restructured everything, but it meant
that virtually all bug fixes only needed to be made once -- a huge time
savings in the long run.

                             Randy.

Re: Porting ADA source

[Robert I. Eachus]

Randy Brukardt wrote:

> Case in point: when we ported Janus/Ada to the U2200 computers, we had to
> change a lot of assumptions about the sizes of things. (We had of course
> assumed character = byte = 8 bits, and of the U2200 was a 36-bit word
> machine.) Rather than simply coding a different set of assumptions, we
> decided to restructure everything so that the compiler depended on a small
> set of packages that encoded host and target information. That eliminated
> future redos for similar issues. I'm sure the customer would have been
> happier in the short run if we hadn't restructured everything, but it meant
> that virtually all bug fixes only needed to be made once -- a huge time
> savings in the long run.

I'll second Randy on this first.  Quick and dirty gets to "sort of 
working" faster, but doing it right seems to get to working faster, and 
definitely gets to no bugs much faster.

However, there is an issue here that may require living with two 
versions for a long-time: the need to compile using the DEC Ada compiler 
which AFAIK is Ada 83 only.  I believe that GNAT is available for some 
Alpha OSes.  (I don't know which Unix variant this is.)

I think that the right path forward would be to migrate the code to 
GNAT, then use the GNAT version on the Alpha system.  It may be a lot 
simpler than any other approach, and it certainly should reduce the 
support costs going forward.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: Porting ADA source

[Volkert]

"Giacomo Polizzi" <mio@.mio> wrote in message news:<cdfu3s$k1a$1@e3k.asi.ansaldo.it>...
> Hello,
> 
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
"Giacomo Polizzi" <mio@.mio> wrote in message news:<cdfu3s$k1a$1@e3k.asi.ansaldo.it>...
> Hello,
> 
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.

For moving from Ada 83 to Ada 95 read the Ada Compatbility Guide:
http://unicoi.kennesaw.edu/ase/ase02_01/docs/compat/compat-guide6-0.pdf

We are still migrating more than 3 mio loc of Ada 83 code (OpenVMS,
DecAda)
to GNAT (OpenVMS). For such a large application it is really hard
work. The Source has to work for some time on both compilers. The
interersting point is, that we have found to all "source-code"
problems solutions without using
tools like gnatprep.

If it is a valuable piece of software, i would expect, that you 
have a support contract with ACT. They will assist you.

Volkert

Re: Porting ADA source

[Marin David Condic]

Its all rather hypothetical, considering we don't really know what the 
whole situation is. I naturally agree that if one builds a system and 
thinks there is a potential need to port, one ought to design in the 
portability from the start. (Isolate the dependencies at a low level). I 
also would agree that if a system has a long and profitable future ahead 
of it, one might be wise to look at a porting situation as an 
opportunity to fix things that were not designed for portability (or 
other structural problems that may exist).

My observation would be that there is a large class of systems where 
there might be some generally useful capabilities that someone wants to 
preserve for some relatively small body of users and are therefore 
porting them to more available hardware, but the systems just plain 
aren't worth any significan effort to do it "right". Gold plating on 
systems like this is mostly a waste of resources and I like to see ways 
of avoiding building Brick Outhouses when this comes up. It happens far 
more frequently than cases where there is some immensely valuable and 
profitable tool that is worth investing some redesign effort in.

MDC



Robert I. Eachus wrote:
> 
> I'll second Randy on this first.  Quick and dirty gets to "sort of 
> working" faster, but doing it right seems to get to working faster, and 
> definitely gets to no bugs much faster.
> 
> However, there is an issue here that may require living with two 
> versions for a long-time: the need to compile using the DEC Ada compiler 
> which AFAIK is Ada 83 only.  I believe that GNAT is available for some 
> Alpha OSes.  (I don't know which Unix variant this is.)
> 
> I think that the right path forward would be to migrate the code to 
> GNAT, then use the GNAT version on the Alpha system.  It may be a lot 
> simpler than any other approach, and it certainly should reduce the 
> support costs going forward.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Robert I. Eachus]

I said:

 > I'll second Randy on this first.  Quick and dirty gets to "sort of
 > working" faster, but doing it right seems to get to working faster,
 > and definitely gets to no bugs much faster...

 > I think that the right path forward would be to migrate the code to
 > GNAT, then use the GNAT version on the Alpha system.  It may be a lot
 > simpler than any other approach, and it certainly should reduce the
 > support costs going forward.

 > Marin David Condic replied:

> Its all rather hypothetical, considering we don't really know what the 
> whole situation is. I naturally agree that if one builds a system and 
> thinks there is a potential need to port, one ought to design in the 
> portability from the start. (Isolate the dependencies at a low level). I 
> also would agree that if a system has a long and profitable future ahead 
> of it, one might be wise to look at a porting situation as an 
> opportunity to fix things that were not designed for portability (or 
> other structural problems that may exist).
> 
> My observation would be that there is a large class of systems where 
> there might be some generally useful capabilities that someone wants to 
> preserve for some relatively small body of users and are therefore 
> porting them to more available hardware, but the systems just plain 
> aren't worth any significan effort to do it "right". Gold plating on 
> systems like this is mostly a waste of resources and I like to see ways 
> of avoiding building Brick Outhouses when this comes up. It happens far 
> more frequently than cases where there is some immensely valuable and 
> profitable tool that is worth investing some redesign effort in.

I understand your concern and you will notice that I was suggesting what 
may be the 'cheapest' way to get to one version of the code on two systems.

But the more fundamental disagreement is one I will persist in.  I have 
only once regretted going to a more 'elegant' solution (and that was in 
a Simscript project quite a while ago).  But it seems like every time I 
decide not to 'clean-up' the design I regret it during debugging. 
Often, you realize that the only reasonable way to fix a particular bug 
it to go back and do the restructuring.

That is why I said that you may be able to get to "sort of working" 
faster with a 'quick and dirty' approach.  But I've been doing this too 
long and have too good a memory (or too many bad memories) to ever make 
that mistake again.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: Porting ADA source

[Marin David Condic]

We may not be all that far apart. I too have been around the block 
enough to know that "Experience" is what we have that enables us to 
recognize a mistake when we make it again. ;-) I have lived to regret 
believing the story "It will *never* get moved off of this platform...." 
and I too prefer to build things in a more "elegant" manner when possible.

Maybe I've just lived long enough to know as well that people like and 
find useful certain approaches that are *not* 'elegant' because they are 
expedient and that if you fight them on it, they go somewhere else. I 
think that's one of the things that has hurt Ada over the years: We keep 
telling programmers they shouldn't do something they want to do and then 
wonder why they stay away in droves.

MDC


Robert I. Eachus wrote:
> 
> That is why I said that you may be able to get to "sort of working" 
> faster with a 'quick and dirty' approach.  But I've been doing this too 
> long and have too good a memory (or too many bad memories) to ever make 
> that mistake again.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Robert I. Eachus]

Marin David Condic wrote:

> Maybe I've just lived long enough to know as well that people like and 
> find useful certain approaches that are *not* 'elegant' because they are 
> expedient and that if you fight them on it, they go somewhere else. I 
> think that's one of the things that has hurt Ada over the years: We keep 
> telling programmers they shouldn't do something they want to do and then 
> wonder why they stay away in droves.

Pearls before swine, Marin, Pearls before swine.  It is a very tough 
choice, but I think we need _one_ computer language where the habit and 
the discourse is based on good engineering and software engineering 
practice.

The real problem that we keep running into is an attitude towards 
software that says it will be buggy, messy, and expensive to maintain, 
and that this is a fact, not a result of current software development 
practice.

I like it when the support group complains that they have insufficient 
data on mean time to repair bugs in Ada software.  And personally, I am 
not willing to give that up to increase the popularity of Ada.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: Porting ADA source

[Marin David Condic]

Maybe its time to dredge out the "Tower Of Babel" analogy once again? 
Large efforts that involve lots of people and complicated decisions seem 
to be very hard to do and sometimes become impossible. They never go 
forward without errors. People always have their own styles and agendas 
they try to impose on the project. No two engineers are going to agree 
100% of the time on the relative merits of various design decisions. 
People will always misuse tools. Maybe that's a gas law or a "Y = MX + 
B" kind of aspect of the universe. Ada rather deliberately set itself 
the goal of trying to overcome the Tower Of Babel syndrome - maybe there 
is some hubris in there?

MDC

Robert I. Eachus wrote:
> 
> Pearls before swine, Marin, Pearls before swine.  It is a very tough 
> choice, but I think we need _one_ computer language where the habit and 
> the discourse is based on good engineering and software engineering 
> practice.
> 
> The real problem that we keep running into is an attitude towards 
> software that says it will be buggy, messy, and expensive to maintain, 
> and that this is a fact, not a result of current software development 
> practice.
> 
> I like it when the support group complains that they have insufficient 
> data on mean time to repair bugs in Ada software.  And personally, I am 
> not willing to give that up to increase the popularity of Ada.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Robert I. Eachus]

Marin David Condic wrote:

> Maybe its time to dredge out the "Tower Of Babel" analogy once again? 
> Large efforts that involve lots of people and complicated decisions seem 
> to be very hard to do and sometimes become impossible. They never go 
> forward without errors. People always have their own styles and agendas 
> they try to impose on the project. No two engineers are going to agree 
> 100% of the time on the relative merits of various design decisions. 
> People will always misuse tools. Maybe that's a gas law or a "Y = MX + 
> B" kind of aspect of the universe. Ada rather deliberately set itself 
> the goal of trying to overcome the Tower Of Babel syndrome - maybe there 
> is some hubris in there?

No.  Hubris would be asserting that MY work is perfect and I don't need 
code reviews and test plans.  Having a goal of zero defects is not 
hubris, it is good (software) engineering.  With physical products, 
expecting that every widget will be perfect may result in 
overengineering.  But with software, if you have any major defects in 
the final product, the yield is zero.  So when the alternatives are 100% 
good software and 0%, the only goal that makes sense is to eliminate all 
bugs.

 From long personal experience, with Ada it is possible to have residual 
defect levels under one bug per thousand SLOC after unit test.  One 
residual bug per 10,000 SLOC is often possible, but it can only be a 
goal not a requirement.  (If you want the requirement to be zero 
residual bugs after unit test, use SPARK.  There are always some system 
level bugs that can't be caught during unit test.  The SPARK Examiner 
should catch most of these during software integration.)

If you have less than one bug per thousand SLOC, you can realistically 
expect to find and fix all remaining bugs during system test.  Also from 
painful experience, if the residual bug rate going into system test is 
above 1 per 100 SLOC (or 10 per KSLOC, which sounds worse ;-) you can't 
afford to find and fix all the bugs.  It literally is cheaper to throw 
the code away and start over if you need high quality software.

This should all be Software Engineering 101, and taught to 
undergraduates.  Unfortunately, most software engineering has to be 
learned either on the job, or in grad school after having a couple
years of industry experience.  Maybe what we need is a Software 
Economics 101 course for undergraduates in computer science AND management.

Fortunately SPARK seems to be catching on for software where reliability 
is a requirement.  However, there are times when you need more 
expressive power than SPARK currently allows, and of course, SPARK could 
not exist without a wider Ada community.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: Porting ADA source

[Marin David Condic]

The nice thing is that with the stringent test requirements of DO-178b, 
things like SPARC start becoming an economically attractive alternative: 
The more testing I can do automatically, the less it costs me to get my 
product approved. It makes sense for Ada vendors to play that card: Do 
as much as possible to provide test tools, etc., because in that 
particular arena (DO-178b) it starts getting *real* obvious that errors 
cost money and you can't sacrifice verification in order to gain Time To 
Market.

Of course, that's only a small subset of the overall software world, but 
it is at least a market that wants to buy what Ada is trying to sell: 
correct software.

MDC

Robert I. Eachus wrote:
> Fortunately SPARK seems to be catching on for software where reliability 
> is a requirement.  However, there are times when you need more 
> expressive power than SPARK currently allows, and of course, SPARK could 
> not exist without a wider Ada community.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Porting ADA source

[Richard Riehle]

Porting from DEC to anything else can  be very entertaining,
especially when numerics are involved.   The sign bit, on the
VAX, is not located where you might think.

Confronted with this problem, in a one-time conversion, many years
ago, we opted to convert the VAX numerics to human-readable (using
Text_IO) and read them back into the target system, again using Text_IO.
This is a brute-force approach, but it was suitable to the problem at-hand
at that time.

               NOTE:  For some reason, many long-term users of Ada do
                            not realize that these conversions are already a
part
                            of the language and found in the nested IO
packages
                            within Text_IO.

We first tried to create an algorithm to convert the VAX word into the word
of our target platform.  That turned out to be an ugly mess with lots of
code
to verify the correctness of each translated word.   It is even more fun
when
the DEC word represents a floating point value and needs to be converted
to a floating point value on the target.

I realize this is only part of your problem, but others may want to
contribute
additional recommedations based on their direct experience.

Richard Riehle


"Giacomo Polizzi" <mio@.mio> wrote in message
news:cdfu3s$k1a$1@e3k.asi.ansaldo.it...
> Hello,
>
> I have to port an ADA program from an Unix DEC Alpha machine with a DEC
ADA
> compiler to a Linux pc machine with gnat (gcc) compiler.
>
> The task is to have, if possible, an unique source code compilable on both
> platforms but there are the following problems:
>
> 1) some system packages that execute the same kind of operations have
> different names in the two compilers
>
> 2) some system functions (for example mathematical function) have
different
> names in the two compilers
>
> 3) the word length is 64 bits on DEC Alpha and 32 bits on pc so it is not
> always possible to use the same standard type (for example the long type
is
> 64 bits on Alpha and 32 bits on pc)
>
> 4) the standard type (long long) used by gcc on pc to solve the previous
> problem is not supported by the DEC ADA compiler
>
> 5) the different word length modifies some structure length used to define
> interface messages with other external programs
>
> Is there something like #IFDEF of C language that I can use in ADA ?
>
> Is there any other kind of solution for the above problems ?
>
> Thanks to everybody
>
> Giacomo
>
>

Re: Porting ADA source

[Ronald Price]

Good observation Randy.

I have had to design, re-engineer, and refactor code because it was not created
for maintenance.   

I have been told that the Quick and Dirty approach is the best, I was taking
too long, etc.  But I knew if I organized the code for repair in only one place
my job later as the maintainer would be significantly easier.


How do we teach these maintenace concepts except by OJT?

Re: Porting ADA source

[Frank J. Lhota]

"Ronald Price" <softcrafts@aol.com> wrote in message
news:20040817002823.04158.00003023@mb-m15.aol.com...
> How do we teach these maintenace concepts except by OJT?

If I were designing a Software Engineering curriculum for a University, here
is how I would drive this point home.

I would have the Freshmen complete one large project, emphasising that this
project should be as maintainable as possible. These projects would then be
preserved somewhere for the next few years.

In their Junior year, I would then assign the students the task of going
back to their Freshman projects and make a software change, say add a new
feature. We will gladly provide them with all the materials they handed in
two years ago.

Hopefully, this exercise would show them the folly of "quick and dirty".