Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!wsmith From: wsmith@m.cs.uiuc.edu Newsgroups: comp.arch Subject: Re: Object Translator (was Re: Regi Message-ID: <3300066@m.cs.uiuc.edu> Date: 11 May 89 03:16:00 GMT References: <19162@winchester.mips.COM> Lines: 31 Nf-ID: #R:winchester.mips.COM:19162:m.cs.uiuc.edu:3300066:000:1423 Nf-From: m.cs.uiuc.edu!wsmith May 10 22:16:00 1989 >If we decided to put in load interlocks, that would >be upward-compatible, although we'd likely compile 3rd-party executables >with R3000-style forever. (Of course, if we did add load interlocks at >some point, and if there got to be more of those machines around, at some >point maybe we'd start advising peopel to compile for that, and then do >a reverse-translate on R3000-machines!) >... >Our experience with these methods tends to make us more willing to >consider object code translation as one more trick to use when it makes >sense, and it's really not that weird once you get used to it. >-- >-john mashey DISCLAIMER: >UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com >DDD: 408-991-0253 or 408-720-1700, x253 >USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 >/* End of text from m.cs.uiuc.edu:comp.arch */ This sounds like a version control nightmare. It probably requires more sophistication than current software engineering tools under UNIX are able to provide. The instant you have binaries that look like they should work and they fail in possibly subtle ways, chaos is likely to ensue quickly for the system administrator or software developers trying to port to these systems. Before you worry about making it super-fast, you have to guarantee that it will run correctly. Bill Smith wsmith@cs.uiuc.edu uiucdcs!wsmith