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