Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Software Distribution
Message-ID: <1988Sep29.192410.246@utzoo.uucp>
Organization: U of Toronto Zoology
References: <978@esunix.UUCP>
Date: Thu, 29 Sep 88 19:24:10 GMT

In article <978@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>>>... To be truly portable the intermediate form MUST address
>>>the issues you mention. Even if the source language doesn't define the
>>>semantics of dereferencing NULL pointers, the intermediate form must
>>>define the semantics of dereferencing NULL pointers.
>>
>>Unfortunately, it *can't*, without being machine-specific.
>
>... if UIF allows a compiler to put a flag in the UIF
>that says that *NULL == NULL, or if UIF defines *NULL == NULL, then
>the code will run on brand Y machines, but with a speed penalty caused
>by the run time checks that the code generator had to insert to comply
>with the the brand X compilers request that *NULL == NULL.

Right.  In other words, what we have done is to redefine the semantics
of C to allow *NULL.  Thus guaranteeing that all programs with this flag
in the UIF will be at a serious performance disadvantage on machines
that don't allow *NULL.  The semantics of *NULL are inherently and
incurably machine-dependent, and any "universal" intermediate format
file which specifies them is machine-dependent.

>I can't find any thing about requiring compilers to deduce number
>ranges in anything in my author_copy file. What I keep saying is that
>the compiler must explicitly state its ASSUMPTIONS in the UIF form of
>a program...

How does the target machine's translator know whether it can do the
arithmetic that the program wants?  This cannot be stated in the UIF
unless the compiler can figure it out.  It can't simply be based on the
compiler's host, because then a program which *doesn't* require the full
range of the host's arithmetic (think of a 32-bit host and a 16-bit
target, and a program which is careful not to depend on 32-bit numbers) 
again takes a massive efficiency hit for no good reason.

It is a property of the *program*, not the host it is compiled on, whether
it requires 32-bit arithmetic, the ability to dereference NULL pointers,
etc.  It is difficult to deduce these things from the program, unfortunately.
Modifying the program is not the answer, because there is a massive payoff
for being able to use this technology on existing programs.  Accepting the
efficiency hits is not the answer, because there is another massive payoff
for not losing efficiency.

>... I believe
>Henry published a paper that showed that using better algorithms is
>much better than using nonportable hardware features.

Geoff Collyer and I did indeed publish such a paper.  However, all the
effort on better algorithms is for naught if you cannot get efficient
code out of the compiler.  The *programmer* should not have to worry
about the details of how that is done, but it is important that it be
done.  That is, just because I compiled something on a *NULL machine to
be run on a non-*NULL machine should not mean that I take an efficiency
hit every time I use a pointer -- because I'm careful to avoid needing
*NULL, even though it is difficult for the compiler to know this.

Note, I am not saying that it is inherently evil to accept some efficiency
loss for the sake of correct functioning.  What I am saying is that people
who guarantee correct functioning by their own efforts don't want to take
that efficiency hit for no reason.  And if we are talking about something
that is supposed to sell, we cannot ignore the efficiency issue.  One can
make a fairly good argument that we would all be better off with a small
efficiency loss for the sake of correctness, but that is not the way the
market thinks, and trying to re-educate the market is a really good way
to go broke (if you are trying to do it for profit) or to be laughed at
and ignored (even if you aren't).  When I talk about the idea not being
"practical", I don't mean it is technically ridiculous, I mean that it
WON'T SELL -- people will not adopt it, so proposing it is pointless.
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu