Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!seismo!epiwrl!epimass!jbuck
From: jbuck@epimass.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <1024@epimass.UUCP>
Date: Thu, 2-Apr-87 15:51:00 EST
Article-I.D.: epimass.1024
Posted: Thu Apr  2 15:51:00 1987
Date-Received: Sat, 4-Apr-87 16:49:38 EST
References: <213@pyuxe.UUCP>
Reply-To: jbuck@epimass.UUCP (Joe Buck)
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 37
Keywords: portability, performance
Summary: Almost never is there any efficiency penalty in portable C

In article <213@pyuxe.UUCP> joecar@pyuxe.UUCP asks:
>   If one writes portable C, does it have to be less efficient 
>   than non-portable C ?

98.44% of the time, there is absolutely no penalty for writing portable
code.  For example, casting pointers to the right type, and using
"sizeof" rather than putting numbers in the code, and making sure
to use "long" instead of int when a value may exceed the range of
a 16 bit integer, generates essentially the same code as doing it
sloppy does.  And it's less likely to be buggy.  This is because
casts that don't do anything on a particular architecture generate
no code, and expressions involving sizeof are evaluated at compile
time.  SysV vs BSD differences can be taken care of with #ifdefs
where they arise.  Again, no time penalty.

Having said all this, I will make a confession.  I wrote a rather
large and complex simulator/symbolic debugger for a DSP board
designed here at Entropic.  It runs on at least 5 different versions
of Unix (and one alleged Unix:  Eunice) including one with 16 bit
ints and 32 bit pointers (thank you, lint!).  The only problem
encountered in porting was that I had assumed sprintf returns a
pointer to the data (as in bsd) while it returns the string length on
Sys V.  But it makes one glaring nonportable assumption:  that the
machine it's running on is two's complement.  This is because it's
simulating a machine that does two's complement math; the alternative
would be to make the code run much slower.  So yes, there are cases
where truly portable code would give an efficiency penalty.  But they
are rare.  

Actually, it turns out that casting from unsigned to signed ints and back
is guaranteed to simulate two's complement behavior even on non-two's
complement machines (see K&R).  Had I known this, I could have done the
simulator portably without a time penalty.  But I don't think I'll
go back and change it now.
-- 
- Joe Buck    {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck
	      seismo!epiwrl!epimass!jbuck  {pesnta,tymix,apple}!epimass!jbuck