Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <698@edge.UUCP>
Date: Tue, 28-Apr-87 16:39:02 EDT
Article-I.D.: edge.698
Posted: Tue Apr 28 16:39:02 1987
Date-Received: Fri, 1-May-87 03:51:17 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1287@ubc-cs.UUCP>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 25

// Note to the net:  This is getting out of hand.  I really *am* trying to
keep this to a minimum, and trying to avoid "is/is not/is so" arguments. //

I think I gave the wrong impression:

> > I'm certainly not a C zealot, but I can't think of *any* application for
> > which C is a poor choice as a language but assembler is a good one.
>
me>Well, let's see.  There are some obvious ones, like real-time life-support
me>or safety-monitor applications in which it is absolutely necessary to show
me>that in the worst case, the response time will be less than x microseconds.
> 
> I said *language*, not *compiler* ...
> there is nothing in the specification of C (or other high-level languages)
> which mandates they be less efficient.

I wasn't referring to efficiency.  I was referring to predictability.  I can
look in my book here and find that on a 10MHz 68000, the instruction
  MOVE.W 6(A0),D0    will take exactly 1.6+.1w microseconds, for a "w" wait
state memory.  I haven't the vaguest idea how long it will take to execute
  temp1 = ptr1->count;   and what's worse, a change to some other part of
the same module could cause this statement to be faster or slower (as the
result of global optimization).  Okay?

-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona