Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!ll-xn!ames!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!mrspock From: mrspock@hubcap.UUCP (Steve Benz) Newsgroups: comp.arch Subject: Re: Software Distribution Message-ID: <2793@hubcap.UUCP> Date: 20 Aug 88 16:53:37 GMT References: <1988Aug19.175624.19835@utzoo.uucp> Organization: Clemson University, Clemson, SC Lines: 29 >[Chaim Bendalac wrote:] >>[Use intermediate language instead of a common binary code for >> distribution purposes, and make a utility common to all machines >> for translating this intermediate code to executable form.] To which Henry Spencer replies: > The one problem I can think of is that it's tricky to build such a > representation in which the front end doesn't need to know *anything* about > the machine. Things like data-type sizes often have to be decided before > the intermediate representation is generated, even if the details of the > code generation get deferred. Perhaps not impossible, but tricky. I'm not sure what Henry talks about is really that big a problem, If the *source* is portable, then the intermediate code could be made to be portable. The worst case would be if one had to abstract a data type all the way back to the level of the source language. That sort of worst-case scenario would result in a compilational problem, but not a representational problem. (i.e. the onus would be on the vendor to fix the problem, not on the standards committee.) I think the real bugaboo here will be system calls and the like. Granted that they are theoretically semantically identical, but in reality, they're not so. In order for such a scheme to work, vendors would still have to break down and come to an agreement on what the standard semantics of all system calls will be. And don't talk to me about graphical interfaces... - Steve Benz