Path: utzoo!utgpu!bnr-vpa!bnr-fos!leibniz!schow From: schow@leibniz.uucp (Stanley Chow) Newsgroups: comp.arch Subject: Object Translator (was Re: Register Scoreboarding) Message-ID: <491@bnr-fos.UUCP> Date: 10 May 89 02:51:35 GMT References: Sender: news@bnr-fos.UUCP Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) Organization: Bell-Northern Research, Ottawa, Canada Lines: 58 Summary: Followup-To: Keywords: In article grunwald@flute.cs.uiuc.edu writes: > >In his picture, when you have a new architecture with, say, more registers, >different delay costs or deeper pipelines, you translate your .o files and/or >your final binaries. This is essentially what scoreboarding is doing, albeit >dynamically. There are some limits to this approach, some obvious, some not >so obvious. > >Comments? Well, it would depend a lot on how much you expect the object translator to do. Somethings are clearly impossible, some may be just inefficent and some may even be useful. 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. Similarly, there are many problems for which optimal solution requires different algorithms for different architectures. Yes, I would be impressed if someone can take i860 code and translate it for Z80. Just to show that this comparison of Z80 and i860 is not silly, consider the Chess programs. For quite a long time, the best chess programs were written by a husband & wife team (I forgot their names) for Z80 (or is it 6502?) chips. The commercial products (the Chess challengers, I think) would compete with the programs running on Cray's and other supercomputers. Do you seriously think an object code translator could achive the performance on a 6502/Z80? 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? As far as object translation as related to comp.arch, I think it is at best a kludge. Some architectures may well need it since as you (or Hennesy) point out, different delay costs and lack of scorboarding make life very interesting over the long term. 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! 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. :-) Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.