Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Software Distribution
Message-ID: <1988Aug29.202603.13897@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1988Aug23.180420.28483@utzoo.uucp> <958@esunix.UUCP>
Date: Mon, 29 Aug 88 20:26:03 GMT

In article <958@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>... The general rule is that hardware
>dependent problems must be pushed through to the hardware dependent
>code generator...

The trouble is that, in the real world, the part of the compiler that
does not make hardware-dependent decisions is the easy and small part.
The idea that parsing, type checking, etc. is a big deal is basically
an academic prejudice in favor of things that are easy to formalize.
These things aren't trivial, mind you, but they're not the hard part
of a production-quality compiler.  This is what brought on my comment
about the "intermediate" form being little more than tokenized source.

What this would amount to, almost, is a sort of encrypted source.
That's pretty much what's wanted for portable distributions that don't
give away the farm or permit users to meddle.  (Of course, this is
anathema to the Stallmanites...  Don't expect GNU to support such a
portable distribution form.)

>I just got back from Xhibition, someone from OSF said they are planning
>to establish a standard for a portable intermediate langauge. Nice to
>see that the market is finally growing up enough to need something
>like this.

One can read this two ways, however:  are they talking about standardizing
the form, or the content?  Standardizing the form makes it easy to build
multiple compiler front ends feeding into the same code generation, but
doesn't remove machine-dependencies from the front ends or their output.
(The PCC intermediate format is a de-facto standard form, but its contents
are machine-specific.)  Standardizing the content is what we've been talking
about.  I can see OSF doing either.

>Imagine being able to buy a program, take it home and pop into the
>drive, wait a few minutes while a machine specific version is created
>from the machine independent version on the disk and then just use it.
>The only thing you have to worry about is wheather or not your machine
>has enough horse power to run the program well...

And about whether the programmer was competent enough to make the code
really portable.  Don't forget that condition.  Since you haven't really
got source, you can't (readily) go in and fix it if there's a problem.
This new flexibility also opens the door to a whole new range of bugs,
since the code can now be run on machines which the author never even
compiled it on.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
