Code portability question

Code portability question

[Mike Werner]

Hi folks.  Got into an argument the other day, and am now trying to get
some more info from those more knowledgable then myself.  I'm a first
year CS student, and the argument was with another student in my class. 
The point of contention revolves around some code written on a PC with a
K6 as the CPU.  The code needed to be mostly rewritten to compile on the
department's Unix server.  The code was written and tested on the PC,
then uploaded to the Unix server.  Once on the server, a compile was
attempted but failed, necessitating the rewrite.  The code was not
complex - intro CS course programming not much advanced from the classic
"Hello World" type projects.  As such, optimization and such is not a
factor.  The class is focused on introducing programming with Ada95.

Now, one side claims that this was necessitated by the architecture
difference, due to the K6 CPU being designed differently and handling
floats differently.  The other claims that either the code was badly
written or the compiler used was faulty or ... something was broken
somewhere.

I would appreciate any pointers as to which is correct.  But please be
gentle - I'm still learning this language and if you get technical on me
I could easily get lost.
-- 
Mike Werner  KA8YSD           |  "Where do you want to go today?"
ICQ# 12934898                 |  "As far from Redmond as possible!"
'91 GS500E                    |
Morgantown WV                 |

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d-@ s:+ a- C++>$ UL++ P+ L+++ E W++ N++ !o w--- O- !M V-- PS+ PE+
 Y+ R+ !tv b+++(++++) DI+ D--- G e*>++ h! r++ y++++
------END GEEK CODE BLOCK------

Re: Code portability question

[Corey Ashford]

Mike Werner wrote:
> 
> Hi folks.  Got into an argument the other day, and am now trying to get
> some more info from those more knowledgable then myself.  I'm a first
> year CS student, and the argument was with another student in my class.
> The point of contention revolves around some code written on a PC with a
> K6 as the CPU.  The code needed to be mostly rewritten to compile on the
> department's Unix server.  The code was written and tested on the PC,
> then uploaded to the Unix server.  Once on the server, a compile was
> attempted but failed, necessitating the rewrite.  The code was not
> complex - intro CS course programming not much advanced from the classic
> "Hello World" type projects.  As such, optimization and such is not a
> factor.  The class is focused on introducing programming with Ada95.
> 
> Now, one side claims that this was necessitated by the architecture
> difference, due to the K6 CPU being designed differently and handling
> floats differently.  The other claims that either the code was badly
> written or the compiler used was faulty or ... something was broken
> somewhere.
> 
> I would appreciate any pointers as to which is correct.  But please be
> gentle - I'm still learning this language and if you get technical on me
> I could easily get lost.

It's impossible to evaluate this without seeing the example code, and getting
a description of the problem that was encountered.

It is possible to write Ada95 code that doesn't port easily to another machine.
A simple example would be code that relies on the byte order of the
machine to be big endian, and the machine to which you are porting is
little endian order.  In most cases, endianness won't affect you at all... it's
transparent - at least until you start dealing with interfacing to hardware,
networks, other computers, etc.  It is possible to write code which is portable
between different machines, but the coding must be done with portability in mind.

The same problems can occur in C, but I think it's harder to program
portably in C since the language doesn't allow you to specify the range
and accuracy of types that are used.

For example, in Ada, you can say something like this:

type My_High_Precision_Float is digits 15;

If the compiler doesn't have an underlying type that has at least that precision,
it will give you a compile time error - which is a good thing!

In C (or C++), you have to hope that the predefined type "double" will
have sufficient precision for your application, and that if double doesn't
have sufficient precision that your application will fail in a way that
makes that fact obvious.  Of course, you could put in runtime assertion
checks in the code to test for insufficient precision, but at best you
won't find out until your program actually links and runs that "double"
isn't up to par.

Hope this helps a bit.  I'm sure others will chime in with things I haven't
thought of.

Re: Code portability question

[bill_1]

In article <36A9849C.A9FE01E4@rocketmail.com>, Corey says...
>
> 
>It is possible to write Ada95 code that doesn't port easily to another machine.
>A simple example would be code that relies on the byte order of the
>machine to be big endian, and the machine to which you are porting is
>little endian order. 

yes, but the problem was a compile time errors the poster complained 
about, not run-time problems.

I agree with you, more info is needed to understand the problem was.

Bill.



 

Re: Code portability question

[bill_1]

In article <36A94B78.963F3215@wvu.edu>, Mike says...
>
 
>
>Now, one side claims that this was necessitated by the architecture
>difference, due to the K6 CPU being designed differently and handling
>floats differently.  The other claims that either the code was badly
>written or the compiler used was faulty or ... something was broken
>somewhere.
>
>I would appreciate any pointers as to which is correct.
 
What compilers were used on the PC and on Unix? What OS's ? 
The only case I would see where an Ada program would compile on one system
and not on the other is if it used some packages that one compiler has as
part of its standard installation, and another did not. Ada is one of the
most portable langauges out there.

Bill

Re: Code portability question

[Tucker Taft]

Mike Werner (mwerner@wvu.edu) wrote:

: ... The code was written and tested on the PC,
: then uploaded to the Unix server.  Once on the server, a compile was
: attempted but failed, necessitating the rewrite.  The code was not
: complex ...

: Now, one side claims that this was necessitated by the architecture
: difference, due to the K6 CPU being designed differently and handling
: floats differently.  The other claims that either the code was badly
: written or the compiler used was faulty or ... something was broken
: somewhere.

With no other information, I would favor the second group, though
at least a little more information would help tremendously.
The representation and detailed properties of floating point numbers 
are irrelevant to most programs which are not doing serious number crunching.

Can you indicate the nature of the rewrite?  Give an example
of what the old and new versions looked like, and in what way
the old version failed on the Unix server.  It also wouldn't
hurt to identify the CPUs, operating systems, and compilers involved.  

Given this information, we might be able to provide some more 
useful (or at least more informed ;-) feedback.

: I would appreciate any pointers as to which is correct.  But please be
: gentle - I'm still learning this language and if you get technical on me
: I could easily get lost.
: -- 
: Mike Werner  KA8YSD           |  "Where do you want to go today?"
: ICQ# 12934898                 |  "As far from Redmond as possible!"
: '91 GS500E                    |
: Morgantown WV                 |

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Code portability question

[Mike Werner]

bill_1@nospam.com wrote:
> What compilers were used on the PC and on Unix? What OS's ?

As far as I know, the PC was a Windoze machine using the AdaGide
compiler.  The Unix machine is - according to the login screen results -
first Unix System V Release 4.0 before I login, then changes to SunOS
5.5.1 after login.  And we use the gnat extension (addon? not sure
exactly what to call it) version 3.10p on it.

> The only case I would see where an Ada program would compile on one system
> and not on the other is if it used some packages that one compiler has as
> part of its standard installation, and another did not. Ada is one of the
> most portable langauges out there.

That thought had occured to me, but I do not remember having any trouble
with it when I took it.  And I'm told that the programming assignments
haven't changed for quite a few years.  There was one locally modified
package, but we were explicitly told about that one and exactly how to
deal with it.
-- 
Mike Werner  KA8YSD           |  "Where do you want to go today?"
ICQ# 12934898                 |  "As far from Redmond as possible!"
'91 GS500E                    |
Morgantown WV                 |

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d-@ s:+ a- C++>$ UL++ P+ L+++ E W++ N++ !o w--- O- !M V-- PS+ PE+
 Y+ R+ !tv b+++(++++) DI+ D--- G e*>++ h! r++ y++++
------END GEEK CODE BLOCK------

Re: Code portability question

[Mike Werner]

Corey Ashford wrote:
> It's impossible to evaluate this without seeing the example code, and getting
> a description of the problem that was encountered.

That's what I was kind of figuring.  Unfortunately, I cannot supply the
code at this point.  It was the other guy that wrote the code.  He did
say that he would try and find it again - if he does, I'll certainly get
a copy.  All he could supply at this point was that the error concerned
initialization of floats.  He also indicated that the rewrite needed was
fairly major.  What had me so suspicious was that he was blaming his
woes on the fact that his computer had a K6 as the CPU.  His claim was
that the K6 handled floats so differently that it messed up his
program.  I didn't see how this was possible.  Or does Ada now
discriminate against the AMD?
 
> It is possible to write Ada95 code that doesn't port easily to another machine.
> A simple example would be code that relies on the byte order of the
> machine to be big endian, and the machine to which you are porting is
> little endian order.  In most cases, endianness won't affect you at all... it's
> transparent - at least until you start dealing with interfacing to hardware,
> networks, other computers, etc.  It is possible to write code which is portable
> between different machines, but the coding must be done with portability in mind.

True.  But with programs as simple as we were doing (intro to Computer
Science) it should be difficult to write code that won't transfer.  The
most complicated program I did was 230 lines.  My brother used AdaGide
on a Windoze machine and I used gnat on a Linux box as our initial
platforms - we then uploaded the source to the Unix server and
recompiled.  Neither of us ever had to do such a rewrite for our
programs.  And I'm told that the programming assignments have hardly
changed over the past few years, so his assignments should not have been
much different from what my brother and I did.
-- 
Mike Werner  KA8YSD           |  "Where do you want to go today?"
ICQ# 12934898                 |  "As far from Redmond as possible!"
'91 GS500E                    |
Morgantown WV                 |

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d-@ s:+ a- C++>$ UL++ P+ L+++ E W++ N++ !o w--- O- !M V-- PS+ PE+
 Y+ R+ !tv b+++(++++) DI+ D--- G e*>++ h! r++ y++++
------END GEEK CODE BLOCK------

Re: Code portability question

[Mike Werner]

Tucker Taft wrote:
> With no other information, I would favor the second group, though
> at least a little more information would help tremendously.
> The representation and detailed properties of floating point numbers
> are irrelevant to most programs which are not doing serious number crunching.

That's one of the points that we argued.  Unfortunately, information is
kind of slim here.  It was the other guy that wrote the code. 
Supposedly, he is going to try and find it to show me.  If at all
possible I will get a copy.
 
> Can you indicate the nature of the rewrite?  Give an example
> of what the old and new versions looked like, and in what way
> the old version failed on the Unix server.  It also wouldn't
> hurt to identify the CPUs, operating systems, and compilers involved.

He did not provide specifics on the rewrite - only that it was a
substantial portion of his code.  The failure before the rewrite had to
do with intialization of floats.  He claimed that the failure stemmed
from the fact that his PC's CPU (AMD K6) architecture was so different
that it screwed up his program.

The department's server - Unix mainframe (actual hardware unknown)
running either SysV R4 or SunOS 5.5.1 (it seems to report both) with
gnat 3.10p as the compiler.

His machine - home PC with an AMD K6 CPU running (assumptions start
here) Windoze 9x with AdaGide as the compiler.  I am assuming AdaGide as
that is what the department recommends for those that don't already have
an Ada compiler.

I did essentially the same assignments on an Intel box running Linux
with gnat 3.10p as my compiler, and my brother used a Windoze 95 box
(unknown "intel compatabile" CPU - possibly actual intel) with AdaGide
as the compiler when we took the class.  Neither of us ever had to do a
rewrite when we uploaded to the Unix server.  
-- 
Mike Werner  KA8YSD           |  "Where do you want to go today?"
ICQ# 12934898                 |  "As far from Redmond as possible!"
'91 GS500E                    |
Morgantown WV                 |

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d-@ s:+ a- C++>$ UL++ P+ L+++ E W++ N++ !o w--- O- !M V-- PS+ PE+
 Y+ R+ !tv b+++(++++) DI+ D--- G e*>++ h! r++ y++++
------END GEEK CODE BLOCK------

Re: Code portability question

[Corey Ashford]

Mike Werner wrote:
[snip]
> All he could supply at this point was that the error concerned
> initialization of floats.  He also indicated that the rewrite needed was
> fairly major.  What had me so suspicious was that he was blaming his
> woes on the fact that his computer had a K6 as the CPU.  His claim was
> that the K6 handled floats so differently that it messed up his
> program.  I didn't see how this was possible.  Or does Ada now
> discriminate against the AMD?

Not unless your compiler emits code for the AMD/Cyrix 3DNow instructions!
(not likely)

The AMD processor is supposed to be an exact clean-room implementation of the
IA32 architecture (plus their 3D enhancements).

I think the chances of the problem being due to a difference in the floating
point register implementation are about, as you surmised, zero.

- Corey

Re: Code portability question

[Corey Ashford]

robert_dewar@my-dejanews.com wrote:
> 
> In article <36AB878E.F51CA837@rocketmail.com>,
>   Corey Ashford <yeroca@rocketmail.com> wrote:
[snipped]
> > The AMD processor is supposed to be an exact clean-room
> > implementation of the
> > IA32 architecture (plus their 3D enhancements).
> > I think the chances of the problem being due to a
> > difference in the floating point register implementation
> > are about, as you surmised, zero.
> 
> Wait a moment! This is going in a bizarre direction. It is'
> OF COURSE the case that the K6 (and any other ia32
> implementation) has radically different floating-point
> behavior, namely it implements 80-bit floating-point
> formats which are typically used for intermediate values.
> It would be quite possible to create an algorithm that was
> stable on the ia32 and unstable on a 64-bit Unix
> implementation, and this is possible even if all the
> declared variables are float and long_float (remember these
> types are unconstrained in Ada 95, so they can use the
> 80-bit format at the compiler's discretion).

Somehow I was thinking that the machine they were going from
was a K6 and the machine they ended up on was an Intel Pentium.

Assuming the machine they ended up on was SPARC, the precision of
float, long_float etc. may well be different (they aren't different
on the Rational Ada compiler, but probably are on GNAT).

If the programmer had specified the precision of the float types
he was using, then there shouldn't have been any problem.  Right?

This is one reason why I stated earlier that code has to be written
with portability in mind.

> 
> I think this is unlikely, but it is a WHOLE lot more likely
> than worrying about the AMD 3-D instructions!

Yup.  Agreed.

Thanks for your comments.

- Corey

Re: Code portability question

[dewar]

In article <36ABE8BF.FFBD087F@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:

> Assuming the machine they ended up on was SPARC, the
> precision of float, long_float etc. may well be different
> (they aren't different on the Rational Ada compiler, but
> probably are on GNAT).

Most certainly GNAT follows the implementation requirement
of RM B.2(10):

   10  Floating point types corresponding to each floating
       point format fully supported by the hardware.

Since the ia32 hardware supports 80-bit floating-point, but
the SPARC hardware only supports 64-bit hardware, the RM
*requires* that the two implementations are different in
this respect. Are you really saying that Rational does not
follow this requirement? That would be rather surprising,
this is not an optional requirement, since this part of
annex B is required to be implemented in any conforming
compiler.

In GNAT, the relevant declarations are:

   --  Floating point types. We assume that we are on an
   --  IEEE machine, and that the types Short_Float and
   --  Long_Float in Standard refer to the
   --  32-bit short and 64-bit long IEEE forms.
   --  Furthermore, if there is
   --  an extended float, we assume that it is available as
   --  Long_Long_Float.

   --  Note: it is harmless, and explicitly permitted, to

   --  include additional
   --  types in interfaces, so it is not wrong to have
   --  IEEE_Extended_Float
   --  defined even if the extended format is not
   --  available.

   type IEEE_Float_32       is new Short_Float;
   type IEEE_Float_64       is new Long_Float;
   type IEEE_Extended_Float is new Long_Long_Float;

The decision to provide the type Long_Long_Float in
Standard is of course NOT required, and is a (permissible,
and we think desirable) implementation choice.

However, providing full support of the 80-bit form in
Interfaces is clearly required by the RM, and indeed
was quite deliberate. During the design, we felt it was
important to ensure support for all available hardware
floating-point formats.

Robert Dewar
Ada Core Technologies


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Code portability question

[robert_dewar]

In article <36AB878E.F51CA837@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:



> > that the K6 handled floats so differently that it
> > messed up his program.  I didn't see how this was
> > possible.  Or does Ada now discriminate against the
> > AMD?
>
> Not unless your compiler emits code for the AMD/Cyrix
> 3DNow instructions! (not likely)
>
> The AMD processor is supposed to be an exact clean-room
> implementation of the
> IA32 architecture (plus their 3D enhancements).
>
> I think the chances of the problem being due to a
> difference in the floating point register implementation
> are about, as you surmised, zero.


Wait a moment! This is going in a bizarre direction. It is'
OF COURSE the case that the K6 (and any other ia32
implementation) has radically different floating-point
behavior, namely it implements 80-bit floating-point
formats which are typically used for intermediate values.
It would be quite possible to create an algorithm that was
stable on the ia32 and unstable on a 64-bit Unix
implementation, and this is possible even if all the
declared variables are float and long_float (remember these
types are unconstrained in Ada 95, so they can use the
80-bit format at the compiler's discretion).

I think this is unlikely, but it is a WHOLE lot more likely
than worrying about the AMD 3-D instructions!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Code portability question

[Nick Roberts]

One thing is for sure: if the UNIX target is not an IA (Intel Architecture)
machine, then whether the PC's CPU is a K6 or other IA is irrelevant.
Otherwise (if both are IA), it is faintly possible that the flags for the
NDP (floating-point unit) are set differently on the UNIX machine cv the PC,
and this is causing problems.

But one other, more likely, possible cause occurs to me: does your friend's
program write out floating-point data into a data file, and then read it
back in again? If so, and your friend decided to simply copy the data file
from PC to UNIX, then this might explain the problems!

-------------------------------------------
Nick Roberts
-------------------------------------------