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!