Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!sri-spam!ames!hc!hi!kurt
From: kurt@hi.UUCP (Kurt Zeilenga)
Newsgroups: comp.unix.wizards
Subject: Re: multiple-machine executables for Suns?
Message-ID: <12646@sol.hi.UUCP>
Date: Tue, 4-Aug-87 12:22:48 EDT
Article-I.D.: sol.12646
Posted: Tue Aug  4 12:22:48 1987
Date-Received: Thu, 6-Aug-87 02:30:51 EDT
References: <1853@megaron.arizona.edu>
Reply-To: kurt@hc.dspo.gov (Kurt Zeilenga)
Organization: U. of New Mexico, Albuquerque
Lines: 72

In article <1853@megaron.arizona.edu> whm@arizona.edu (Bill Mitchell) writes:
>I find myself frequently inconvenienced by the incompatibilities between
>different Sun binaries.  Sun-2 binaries will work on a Sun-3, but not
>vice-versa and I expect that Sun-4 binaries work iff they're on a Sun-4.
>A fairly straightforward solution to this problem seems to be to extend
>the executable format so that multiple executables can be contained in a
>single file.  Thus, if you've got Sun-2s and Sun-3s lying around, it'd be
>nice to have an executable that contains both Sun-2 and Sun-3 versions of
>the same program.  If you run it on a Sun-3, it fishes out the Sun-3 code
>and if you run it on a Sun-2, it fishes out the Sun-2 code.

Me, too!  But really gets me is that code is not portable between different
systems on campus.

>I asked someone at Sun about this and they said that although Sun had talked
>about it there were no plans for doing it at the current time.  As the only
>specific reason for not doing this, he cited the extra disk space required for
>such a format.  Here, disk space is much cheaper than programmer time and I'd
>gladly have binaries that are twice as big if I didn't have to worry about two
>different executables.

Let's see, we got SUN3s and SUN2s and eventually SUN4s, a Sequent, a Encore
(on the way), some BIG and little VAXs and lets not forget those bloody
PCs.  Let's see, that's three images for the SUNs, two for the VAX (one
for Ultrix and one for BSD), one for the Sequent, one for the
Encore, and we'll forget the PCs.  That makes 7 images per a.out, no big deal.

>As far as I've thought about it, it seems that it really wouldn't be hard to
>implement this.  I might go so far as to say that it would make a good
>independent study project for a sharp student.

Sure, no problem.  I'll hack it in this evening.

>A possible plan of attack:
>
>	Fix the kernel to recognize the multiple format and ignore portions
>	 of the file intended for other machines.
>
>	As with the kernel, fix programs that read a.out files to ignore
>	 portions for other machines.
>
>	Produce a utility that will take one or more regular executables of
>	 different machine types and produce a multiple-machine executable.
>
>There's also the problem of object files, but since they're also a.out files,
>a lot of the stuff for them would just fall out.  As far as production of
>multiple-machine object files is concerned, just modify the language front
>ends to accept a list of machines to compile for and then do each one in turn,
>adding each to the object file.
>
>Has anyone else done much thinking about this?  Any implementation attempts?
>
>In some ways the current incompatibilities help Sun -- they provides some
>motivation to roll out Sun-2s and roll in Sun-3s, but on the other hand, it
>lessens (to near-zero for me) the motivation to roll in a Sun-4.
>
>					Bill Mitchell
>					whm@arizona.edu
>					{allegra,cmcl2,ihnp4,noao}!arizona!whm
>p.s.
>If you've got something to say of interest -- post it; don't just mail it to me.

Well, someone had to point out the obvious :-).

But more seriously, if I was going to design an a.out format that could
"run" everywhere I would have the compilers, loaders, etc output a psuedo
code and then have the kernal interpet the code.  This will keep the
a.out small, but the will take FOREVER to execute. 
-- 
	Kurt Zeilenga	 (zeilenga@hc.dspo.gov)		I want my talk.flame!

	"Remember, Mommie, I'm off to get a commie..."