Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Software Distribution
Message-ID: <1988Sep18.031934.13750@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1988Sep7.210317.5781@utzoo.uucp> <970@esunix.UUCP>
Date: Sun, 18 Sep 88 03:19:34 GMT

In article <970@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>> Distribution with sources is Good.  Distribution without sources is Evil.
>
>Oh, great... GOOD versus EVIL! Send me your definition of good and
>evil and how you feel about absolute moral values and I'll send you
>mine. Then we can debate the whole issue. But PLEASE do it off line.

You miss the point; these are not my beliefs, but Richard Stallman's, and
by extension, those of the Gnu project.  This is why I'd expect them to
be very unenthusiastic about anything that would facilitate sourceless
distribution.  We are indeed talking about absolute moral values, not mere
considerations of tactics.

>> ... What I'm thinking of is much more subtle things that the compiler
>> can't easily discover and put in the intermediate form, e.g. "this program
>> depends on being able to dereference NULL pointers".  Or, for that matter,
>> "the details of the arithmetic in this program assume that integers are
>> at least 36 bits"...
>
>... To be truely 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.  Some machines
allow it; some do not.  If the intermediate form allows dereferencing NULL,
then the intermediate form's pointer-dereference operation is inherently
expensive on machines which do not permit dereferencing NULL, making it
impossible to generate good code from the intermediate form.  If the
intermediate form forbids it, then the compilers must guarantee that
no program will try to do so... which for normal compilers will boil down
to inserting run-time checks, again making efficient code impossible.
This is an inherently unportable issue, which an intermediate form MUST
NOT try to resolve if it is to be both efficient and portable.

>Yes, that means that C compilers will have to put information into the
>intermediate form that does not derive from any programmer provided
>declarations. That indicates a flaw in C, not a problem with the idea
>of a portable intermediate language. 

This is like saying that the impossibility of reaching the Moon with a
balloon indicates a flaw in the position of the Moon, not a problem with
the idea of using balloons for space travel!  All of a sudden, our
universal intermediate form is useless for most of today's programming
languages, unless the compilers are far more sophisticated than current
ones.  (NULL pointers are a C-ism, but deducing the size of integers that
the program's arithmetic needs is a problem for most languages.)

I assumed that we were talking about *practical* portable intermediate
forms, ones that could be used with current languages and current compiler
technology.
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu