Path: utzoo!attcan!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <9443@cup.portal.com>
Date: 25 Sep 88 21:09:32 GMT
References: <891@taux01.UUCP> <650004@hpclscu.HP.COM>
Organization: The Portal System (TM)
Lines: 68
XPortal-User-Id: 1.1001.5156

>> I have felt in my bones that an efficient Intermediate Language for 
>> conventional processors [(examples)] is realistic proposition....       
>Such a piece of research was done years ago at Stanford ("Ucode".             
>Exact reference not available at the moment).                                 
                                                                               
Well, Ucode doesn't really fit the needs here, and certainly "machine-         
independent representation for the distribution of application                 
programs" wasn't the point behind Ucode.  For something closer, but            
not quite there yet, see the work done at DECWRL:  "The Mahler                 
Experience:  Using an Intermediate Language as the Machine Description,"
by David Wall & Michael Powell, WRL Research Report 87/1; this is just
one piece of the great research done for the Titan/MultiTitan project.

Note that one of the major benefits of a MIIL is that a manufacturer
can release a new version of a machine and the poor users of the old
machine won't have to throw away all their software if they want the
features of the new machine.  Notice that this is the promise and, by
and large, the delivery of the current IBM PC and Mac lines, but the
level of compatibility, at the processor instruction set, is too low.  
At least the Mac II lets you install display systems with impunity
(and type in any combination up to six at once!) *without* having to
manually install different drivers in every application, etc. etc.
                                           
But note further that a MIIL can't be limited to just a standard for
expressing application algorithms, it must also specify a great deal
about the operating system (geeze, call it BIOS or TOOLBOX if you're
a little insecure at this point).  For the Mac line, this should not
be a very hard thing to do; the IBM PC world is a little more cloudy.

As an example of this, I was always pleased that I could take a binary
program from 4.2 BSD and run it on Dec's Ultrix, most of the time.  I
know that doesn't exhibit a MIIL, but it does show what kind of
operating system specification is needed.

As someone said earlier in a posting, what we need for processor 
instruction sets is what UNIX provides for computer operating systems
(please no flames about how *good* UNIX is; I am just trying to say
that the idea of a standard *interface* is there).

And, we don't have to have just *one* MIIL, why not have many?  Then,
if you want access to a certain application, you must have the compiler
for the MIIL in which it is written.  This allows more money to be charged
for the more sohpisticated MIILs, thus satisfying the maketing types
among us.  And it also reflects the *fact* that no one MIIL will be
sufficient for all time.  Instead of embellinshing *one* MIIL forever,
until it becomes a CISC, we can have one MIIL for simple, procedural
languages, C, PASCAL, etc., one for Object oriented languages, one for
ADA (for which we can chanrge MEGA BUCKS because the military will
want it!!!), etc. etc.  Also, if MIIL specifications are made public,
we can all compete for the MIIL market by writing better (faster,
smaller, etc.) MIIL compilers.  A new market is waiting to be tapped!
The existence of MIILs doesn't cut revenue, it increases it!

Even with a MIIL for every area, there will still
only be a few, and having a few compilers on your system is not a big
deal (or won't be soon), and they can even be kept off-line if necessary
(unless the compilation is done on-the-fly).  Note that with the right
metaphores (such as that on the Mac, "double clicking"), the operating
system can discover that the application hasn't been compiled from MIIL
to native code and do that automatically.  "Please wait:  installing
application.  XX seconds 'till installation complete."  *THIS* is the
way to do it.  *This* is the way computers should work.  Whenever I tell
a layperson (but computer user) that I have been working on a way to let
new computers run old software, they ask why it hasn't always been that
way....  Think of software for computers as gasoline for automobiles and
you understand why the layperson is mad that IBM PCs can't run Apple
software!  What would you think if Arco gasoline only worked in economy
cars!