fast code and no morals

Munach Rvi'i SofPasuk at imagen.UUCP
Tue Feb 18 03:16:24 AEST 1986


> In article <6365 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
> >> > Assembler isn't portable, C is. ...
> >> 
> >> "C" is as portable as Stonehedge!!  At least assembler languages don't
> >> pretend to be portable.
> >
> >How curious.  At U of T we routinely move C code among half a dozen or so
> >different processors (more than that if you count different C compilers
> >for things like the 68000).  Compile it and it runs.
> >
> >C's portability is more than just pretense.  Of course, you have to know
> >what you're doing when you write the code.
> 
> When the same application or small routine has to on an 8085, 8086, 68000,
> 68010, PDP-11, and a VAX, and is subject to FREQUENT enhancement, and
> only two machines run UNIX, the less written in assembler, the better.
> 
> Standard practice in this case is to run everything, including libraries
> through lint, all 8 compilers (Large and small model 68K on native and
> non-native), and be real specific about types.
> 
> This is much better than having to maintain 8 different assembler versions.
> 
> ...
> 

The point about the "C" being as portable as Stonehenge was made NOT to
imply that programs should be routinely written in Assembler Language
(pun not intended), but rather that porting of programs written in "C"
has its own different set of problems, the solution to some of which are
noted above.  This is very obvious to organizations, such as mine, that
distribute "C"-based software for use on many different host systems, all of
which allegedly have "standard UNIX" and "standard C" (whatever "standard"
means these days).

Of course, we would never be able to distribute our software for so many
different host systems if we were required to write the code in Assembler,
but, on the other hand, we must go through significant coding gymnastics to
assure the portability including sticking to the "least common multiple" of
language features and "detuning" programs due to the compiler restrictions
(authors call them features, of course) on some systems.  We don't have the
luxury of telling our customers "too bad, your system doesn't have a good
or standard enough C compiler!"



More information about the Comp.lang.c mailing list