Path: utzoo!attcan!uunet!portal!cup.portal.com!bcase From: bcase@cup.portal.com (Brian bcase Case) Newsgroups: comp.arch Subject: Re: Object Translator (was Re: Register Scoreboarding) Message-ID: <18209@cup.portal.com> Date: 10 May 89 19:03:11 GMT References: <491@bnr-fos.UUCP> Organization: The Portal System (TM) Lines: 57 >>[Dirk Grunwald's (Hi Dirk!) comments on Hennessey's comments about >>binary translation] >To take the impossibles first, I would be really impressed if anyone can >take the context switching code for one machine and translates it into >functional context switching code for a different machine. Hennessey, and anyone else considering binary translation, was talking about translating the binaries for *application* programs, not things like OS kernels. >There are, however, valid uses for object translators. For example, Hunter >systems will translate MS-DOS programs to run on Unix boxes. From what I >understand, this is done for support cost reasons! It is cheaper for a >software house to support one version for MS-DOS than it is to support >multiple versions for different systems. This is strictly a support cost >vs. translation cost trade-off. I have not heard performance or optimization >as a sales pitch for Hunter systems. Anyone with better knowledge? I have done some insulti, I mean, consulting for Hunter Systems (but only mundane things). It is true that some of their customers are interested in keeping their support problems minimized. Translating one version for many hosts is better than supporting many versions. XDOS can do quite well with respect to performance, at least compared to the dynamic schemes used to Phoenix and Insignia Solutions. Hunter Systems XDOS is *not* an automatic translator. It requires "key files" that are nearly completely human generated (or at least human supervised). This is because automatic *static* translation is *impossible* without more information than is present in executable images. Some people appear to be addressing this issue somewhat by retaining more info in the executable. I've written about this before; if you want to know more, let me know. (The hard problem is indirect branches.) > It would also be interesting to look at the complexity of an "Optimizing >Translator". Any OT would first have to discover the real intent of the >program, then optimize it for the new architecture. This is a much harder >problem than an optimizing compiler where the source code is available. >Consider all the work that has gone into language design to make it easy >for compilers to optimize! This is why I was calling for one or a few "universal" (boy, is that an overworked term) intermediate langauges to be used for application distribution. This would allow much more freedom for the development of new architectures. This would keep us all in business! >Basically, the object code (for any architecture) is a very poor medium >for communicating algorithm or program intent. Most emulators have trouble >just faithfully micmacing the target system! Optimizing translators sound >very hard to me. :-) Well, I've written a couple of optimizing translators. They can be straightforward or very complex, depending on the architectures in question. Object code is a poor intermediate language (which is what they are being asked to be with respect to object code translation). One way to look at optimization is that its purpose is to lose information.