short circuit evaluation - some com

preece at ccvaxa.UUCP preece at ccvaxa.UUCP
Fri Feb 27 01:37:00 AEST 1987


  drw at cullvax.UUCP:
> As far as run-time, it is not a legitimate result because the standards
> (implicitly) state that run-time is "implementation defined".  (Flame
> on:) How can it possibly be a legitimate result???  It changes if you go
> to a faster processor!!!  (Otherwise why would you get a faster
> processor???)  Which one of us is crazy???  (Flame off.)
----------
I guess you've never written code that had to do time-dependent
things on a system that didn't have a sleep call.  There are
environments in which code is written that is processor specific:
change to a faster processor and you have to change the timing
constants (lengthen buzz loops).  For such code "portability" means
exposing the constants so that they can be easily changed to match
new hardware.
----------

> The choice of internal representation of a quantity should be entirely
> up to the compiler.  Thus, whether a number is normalized or
> unnormalized (or represented as strings of ASCII characters) is
> something that the programmer should (a) have no control over, and (b)
> have no concern with.  (Other than I/O to/from other subsystems.)
----------
I guess you've never written code that had to run fast or do careful
things with numbers.  Consider, for instance, the arithmetic runtimes
for a LISP system.  We have to have tight control over the hardware
results of operations so that we can do appropriate mapping between
hardware results and LISP-side reresentations of objects.  Many other
users have similar problems.

We talk a lot about portability and cleanliness here, but there are
a tremendous number of computer users who use the machines where
very tight control of the hardware is the only way they can get their
jobs done.  That doesn't mean we shouldn't strive to make portability
problems visible or that code that doesn't have to have machine
specificity shouldn't avoid it, but it does mean that pious
generalizations about making the hardware invisible are somewhere
between naive and insulting.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece at gswd-vms



More information about the Comp.lang.c mailing list