Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!preece
From: preece@ccvaxa.UUCP
Newsgroups: comp.lang.c
Subject: Re: short circuit evaluation - some com
Message-ID: <28700008@ccvaxa>
Date: Thu, 26-Feb-87 10:37:00 EST
Article-I.D.: ccvaxa.28700008
Posted: Thu Feb 26 10:37:00 1987
Date-Received: Sun, 1-Mar-87 14:55:41 EST
References: <813@cullvax.UUCP>
Lines: 44
Nf-ID: #R:cullvax.UUCP:813:ccvaxa:28700008:000:2106
Nf-From: ccvaxa.UUCP!preece    Feb 26 09:37:00 1987


  drw@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@gswd-vms