Xref: utzoo comp.arch:7788 comp.misc:4628 comp.lang.misc:2471 comp.protocols.misc:441
Path: utzoo!attcan!uunet!lll-winken!ames!xanth!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc
Subject: Re: "big endian" and "little endian" - first usage for computer
Summary: Either FORTRAN or Mr. Dixon is an ERROR
Message-ID: <2702@rti.UUCP>
Date: 7 Jan 89 18:26:32 GMT
References: <2766@cbnews.ATT.COM> <10147@well.UUCP> <13045@cup.portal.com> <205@mic.UUCP>
Organization: Research Triangle Institute, RTP, NC
Lines: 63

In article <205@mic.UUCP>, d25001@mic.UUCP (Carrington Dixon) writes:
> In article <2695@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
>  
> >My immediate thought on seeing the VAX instruction set when it first came
> >out was that by making the byte order "little endian" it allowed something
> >like a Fortran compiler to take a statement like:
> 
> >	call sub (1)
> 
> >and pass a number to it (a longword - 4 bytes) which would be interpreted
> >correctly whether the receiving formal parameter was a byte, a word (2 bytes),
> >or a longword (4 bytes).  [...] Could this be the REAL
>				   ^^^^^^^^^^^^^^^^^^^^^^
> >motivation for "little endian"?
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>      If I thought that it was, my respect for DEC would take a BIG drop.
> Passing a longword and receiving a word is an ERROR.  Sure, it works fine
> for your example, but what if the statement were: [...]

Well, you can assert that the FORTRAN language itself is an error;  this is
essentially what you are saying.  The point is that there is NO WAY (repeat:
NO WAY) in the Fortran 77 standard to declare a formal argument list.  That
means that there is NO WAY to declare to the compiler that it is to pass
an INTEGER*2 value (as opposed to, say, an INTEGER*4 value) as a parameter
to the subroutine.  In other words, the INTENT OF THE PROGRAMMER was all
along to pass a word rather than a longword, but the DEFINITION OF THE
LANGUAGE does not allow this to be explicitly declared.

Now I am not going to defend FORTRAN as a "safe" language, or an "elegant"
language, or even a "good" language.  It is however a very commercially
significant language - which is not at all the same thing (eg, COBOL).
FORTRAN is still in considerable use (even for new development in some
environments).

> the error _may_ not be found until the module has been in production,
> spewing out wrong answers for months.  I don't know about what kind of
> environment you work in, but where I work this kind of error could cost my
> company $k in data that had to be reprocessed.  (Not too mention egg on
> our corporate face if a client were to discover the gaffe.)

The classic FORTRAN error had nothing whatsoever to do with this kind
of error, but with the terseness that FORTRAN uses for its syntax:

a statement something like

	do 100 i=1,10

got permuted to something like

	do 100 i=1.10

The former statement starts a loop varying "I" from 1 to 10, and the latter
assigns a value of 1.10 to a variable named "DO100I".  Because of the
structure of FORTRAN, where there is no explicit end-loop construct (that
is specified by the statement label "100"), so the error went undetected ...
until the satellite got dumped in the ocean and NASA had lots of egg on
its face.

In other words, if you want to flame anything about safe computing, you
should probably be flaming FORTRAN, not DEC or the VAX or me.

						Bruce C. Wright