mishkin@apollo.uucp (Nathaniel Mishkin) (01/01/70)
In article <2035@umn-cs.UUCP> randy@umn-cs.UUCP (Randy Orrison) writes: >In article <36b9fbe5.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >-In article <1931@umn-cs.UUCP> randy@umn-cs.UUCP (Randy Orrison) writes: >-I will raise the following concern with this solution: I might be >-surprised when I do the following from my Sun 3: >- >- cp //one_sun_4/bin/cat //another_sun_4/bin/cat >- >Ah, but that's not a problem. Remember that /bin is a link to /$(systype)/bin, >so what you're doing is: > > cp //one_sun_4/sun3/bin/cat //another_sun_4/sun3/bin/cat > Actually, not. I imagine "/bin" to be a link to "/$(isptype)/$(systype)/bin" since I need to support all combinations of ISP type (Sun 3, 4, etc.) and type of Unix (bsd4.2, sys5, etc.). It seems wrong to conflate the two variables. Thus, my problem still stands. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {wanginst,yale,mit-eddie}!apollo!mishkin
whm@arizona.edu (Bill Mitchell) (08/04/87)
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.
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.
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.
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.kurt@hi.UUCP (Kurt Zeilenga) (08/04/87)
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..."
guy%gorodish@Sun.COM (Guy Harris) (08/04/87)
> 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. Since the SPARC instruction set does not at all resemble the 68K instruction set, this is certainly true. > 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. Which, in our case, is an excellent reason. SunOS releases are, for better or worse, quite big; were the standard binaries to contain several types of image, you might have to cut back quite a bit on optional software to fit it on a 71MB shoebox (or might not be able to fit it at all). Also note that, if the standard development environment were to build 3-way executables, this environment would have to contain both 68K and SPARC compilers, as well as 68K and SPARC libraries (or even 68010, 68020, and SPARC libraries). In addition, were you to have a server serving several different Sun *and* non-Sun architectures (as will be possible once ND is eliminated), you'd either have to teach all the non-Sun machines about this executable format and stuff the additional images into the common image, or use the idea only for Suns. > 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. I'm not sure what the problem is. If you have several different kinds of executables, you have to compile the program N times, once for each kind of machine. If you have multiple-machine executables, you have to compile the program N times, once for each kind of machine. Both of these will take up some amount of programmer time. There is some additional maintenance time for installing the various different forms of executable image. I don't see why this is a major component of the total development time, though. > In some ways the current incompatibilities help Sun -- they provides some > motivation to roll out Sun-2s and roll in Sun-3s, That was NOT the intent. If you can build Sun-2 binaries, you can run them on Sun-3s; we now offer cross-compilers, so you can build Sun-2 and Sun-3 binaries on Sun-3s. (There is a charge for these; please do not attempt to engage me in a debate about whether this is the right thing to do or not, because 1) I don't have sufficient information about *all* sides of the question to have an authoritative opinion and 2) I don't make policy on that anyway, so if you don't like it you're better off complaining to your salesperson. My *personal* opinion is that we shouldn't charge for it, but there may be a good reason for doing so that I don't know about.) > but on the other hand, it lessens (to near-zero for me) the motivation to > roll in a Sun-4. I still don't see what the executable image format has to do with this; there will be customers to whom binary compatibility with Sun-2s and Sun-3s is more important than the added performance of a Sun-4, so they will buy Sun-3s instead of Sun-4s. The Sun-4 is aimed at customers to whom the expense of recompiling their software (and, if necessary, changing their code to "play by the rules" of portable C) is more than offset by the benefits of the added performance of the Sun-4. DISCLAIMER for the less-bright members of the audience: none of this represents the official opinion of Sun Microsystems, it merely represents my understanding of some of the issues involved (but then one hopes most of the audience understood that anyway). Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy%gorodish@Sun.COM (Guy Harris) (08/05/87)
> 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. In a lot of UNIX systems, you already have that, and you don't have to stuff the interpreter into the kernel, and thus can avoid the effort of making large hunks of your kernel pageable or swappable (you don't want that pseudo-code interpreter wired down, do you?) or making those same hunks reloadable (you don't want to have to reboot when you change the interpreter, right?). The magic number is the string "#!"; just put the pathname of the interpreter after that, and have the interpreter understand that its first argument is the pathname of the file to be interpreted. If the interpreter takes flag arguments, you should have some flag that says "no argument after this one is a flag, even if it begins with '-'" and stick that after the name of the interpreter in the "#!" line. ("/bin/sh" has the "-" argument; the 4.3BSD C shell has "-b".) Of course, you can't safely use this for set-UID executables. The most obvious hole is closed by the above "this is the last argument" flag, and changes in 4.3 that cause the script name NOT to be passed as argv[0] fix the second-most-obvious hole; however, somebody pointed a fairly obscure hole out to me that is fixable only by some extra effort in the kernel, and there may be even more obscure holes after that one. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
kyle@xanth.UUCP (Kyle Jones) (08/05/87)
Sun really ought to come up with a decent name for their new machine instead of "the Sun-4". A different name would clarify the difference in architecture and users would be less inclined to think that executables should be backward compatible. Too late now, though. In the words of a wise old editor, "Sorry, I can't undo that. What's done is done." -- emacs264
whm@arizona.edu (Bill Mitchell) (08/05/87)
Well, I've certainly got some interesting responses to my article, but it seems
that some persons are thinking in terms of using this format across machines
of various vendors and they ennumerate every machine they can think of and
say: "Ok, so with 50 differents executables in file, are you still not worried
about the disk space?" Doing this sort of thing with software from different
vendors is a larger problem, since for best results you'd really need identical
sources. The Suns seem like a good thing to think about initially, since
binaries are not interchangable, but sources are identical.
I should say that my interest in this is from the standpoint of system
administration; not software development. We have three different types of
VAXs, but the suite of locally installed software is basically identical
across all the VAXs. This is trivial with rdist -- we compile on one
machine and distribute to the others. Users can do the same thing with their
personal bins.
On the Suns however, if you want to have software on Sun-2s and Sun-3s, you
can compile Sun-2 binaries and run them on Sun-3s, but you miss out on some
of the good 68020 instructions. Or, you can install things twice and I'll
admit that this is more of a nuisance and psychologial problem than anything
else, but how many sites are really compulsive about this? I'd guess that
most administrative domains with VAXs and Suns have matching software on their
VAXs (if they've heard of rdist), and are running Sun-2 binaries on Sun-3s
or have non-matching software on Sun-2s and Sun-3s. (If this is not the case
for you -- mail me! I'll envy your discipline.)
Guy Harris:
Regarding Sun software distributions, I think that distributing binaries
for only one machine type is perfectly suitable, but is that a reason for not
having the capability to have multiple-machine executables?
Also, it seems that compiling a binary for N machines *is* simpler than
compiling N binaries for N machines. Consider:
cc -o /usr/local/newprog -Msun2 -Msun3 -Msun4 newprog.c
versus:
cc -o /r/sun2/usr/local/newprog -Msun2 newprog.c
cc -o /r/sun3/usr/local/newprog -Msun3 newprog.c
cc -o /r/sun4/usr/local/newprog -Msun4 newprog.c
I also believe that Sun does not introduce incompatiblities to sell new
machines, but incompatibility surely has an effect on sales.
Keep those notes coming!
Bill Mitchell
whm@arizona.edu
{allegra,cmcl2,ihnp4,noao}!arizona!whmtrb@ima.ISC.COM (Andrew Tannenbaum) (08/05/87)
I don't see the advantage of multi-machine binaries over multiple directories with symlinks. It's already commonly done for BSD/ATT universes, why not for CPU or version dependencies too? No code change required. If you do insist on multi-machine executables, please consider using an exisiting format (like ar format). Andrew Tannenbaum Interactive Boston, MA +1 617 247 1155
jas@llama.rtech.UUCP (Jim Shankland) (08/05/87)
In article <12646@sol.hi.UUCP> kurt@hc.dspo.gov (Kurt Zeilenga) writes: >In article <1853@megaron.arizona.edu> whm@arizona.edu (Bill Mitchell) writes: >>I find myself frequently inconvenienced by the incompatibilities between >>different Sun binaries.... 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. Something like Pyramid's conditional symbolic links, but based on CPU type, would be another approach; that strikes me as a little more appealing than having one gigantic a.out file.
guy%gorodish@Sun.COM (Guy Harris) (08/05/87)
> Regarding Sun software distributions, I think that distributing binaries > for only one machine type is perfectly suitable, but is that a reason for not > having the capability to have multiple-machine executables? Given the development effort required to make this work for all the tools that deal with object files (and given that it gets more complicated with something like the approach to shared libraries described in the USENIX talk by Gingell *et al*), it may very well be a reason for not having this capability. Sun, like any other organization, has finite resources for doing development; you have to choose where you're going to put your resources. It's not clear that the benefits *to Sun* of providing this capability exceed the costs of doing so. > Also, it seems that compiling a binary for N machines *is* simpler than > compiling N binaries for N machines. Consider: > > cc -o /usr/local/newprog -Msun2 -Msun3 -Msun4 newprog.c > > versus: > cc -o /r/sun2/usr/local/newprog -Msun2 newprog.c > cc -o /r/sun3/usr/local/newprog -Msun3 newprog.c > cc -o /r/sun4/usr/local/newprog -Msun4 newprog.c Not really much simpler; note that the three commands are identical except for the "-M" flag (which wouldn't be used - "-M" already means something to "cc") and the pathname of the target. Compiling binaries is usually done with "make", not "cc", so the difference would be the difference between make newprog and make CPU=sun2 newprog make CPU=sun3 newprog make CPU=sun4 newprog > I also believe that Sun does not introduce incompatiblities to sell new > machines, but incompatibility surely has an effect on sales. Yes, but I suspect the major impact of the Sun-4's incompatibility has nothing to do with the availability of multiple-machine binaries. Most people who wouldn't buy a Sun-4 for compatibility reasons would do so because it wouldn't run Sun-3 binaries *at all*, not because you can't bundle Sun-3 and Sun-4 binaries into the same file. The only way to "fix" that would have been not to come out with the Sun-4 at all! Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
lmcvoy@eta.ETA.COM (Larry McVoy) (08/06/87)
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 Hmmm... It seems like you are going about this in a "hard" way. Here's an easy fix: Have an environment var MACHINE which == the machine type Have /sun2/{bin,usr/bin} , /sun3/{bin,usr/bin} etc Then in /bin and /usr/bin replace each program with a shell script that figures out which program to execute. You'll pay a price, but you could also get around that by setting your path correctly at login time. I dunno, but this seems a lot easier than hacking up the a.out format and being incompatible with the rest of the world. But I might be wrong, it's happened before :)
steve@nuchat.UUCP (Steve Nuchia) (08/06/87)
In article <12646@sol.hi.UUCP>, kurt@hi.UUCP (Kurt Zeilenga) writes: > 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. This is, of course, a viable idea. There are a large class of unix utilities for which a well selected p-code implementation would be "fast enough". If there were a primitive for each standard library routine plus a few more a large number of the binaries posted could be portable. Actually, they could almost all be portable but I'll grant that you might not like to have to sit through a run of some of them. This is roughly a 90% solution to the problem that started this thread, but it solves a few others in the process. It results in smaller, portable "binaries". It allows the owner of the code to get the program to the users with a minimum of hassle. Has anyone done a simple stack machine that runs C programs reasonably well? coupled with a good set of file, screen, string, and math primitives and given a compiler targeted for it it would be interresting to see how many programs were tolerable under it. I've done such things in the past, but I don't own the code so I'd have to regenerate it. Is there enough interrest out ther to justify the experiment? Anyone want to help? Steve Nuchia {{soma,academ}!uhnix1,sun!housun}!nuchat!steve
jay@splut.UUCP (Jay Maynard) (08/06/87)
In article <12646@sol.hi.UUCP>, kurt@hi.UUCP (Kurt Zeilenga) writes: > 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. I thought that C WAS a pseudo code...after all, it's nearly impossible to read (at least by the uninitiated! :-) The only problem is that it won't run everywhere...I have troubles making stuff that's supposedly Unix C source run on my System V, if it was originally written for Version 7, 4.x BSD,...maybe a meta-C? -- >splut!<...Jay Maynard, K5ZC | uucp: ...!seismo!soma!uhnix1!sugar!splut!jay "Don't ask ME about Unix... | GEnie: JAYMAYNARD (...e-i-e-i-o!) I speak SNA!" | CI$: 71036,1603 FidoNet: SysOp @106/64 The opinions herein are shared by neither of my cats, much less anyone else.
bzs@bu-cs.bu.EDU (Barry Shein) (08/08/87)
I dunno, the proposal to put multiple executables into an a.out to support sun-N at first glance seems like an obvious and straightforward solution, but on a little deeper thought I wonder if the solution should go in a slightly different direction, or at least be thought about in more general terms. First, the "officially sanctioned solution" from Sun is to use a combination of directories, perhaps symlinks and path variable settings. Thus a Sun-2 should search /usr.MC68010/bin while a Sun-3 should search /usr.MC68020/bin (etc.) I suppose the big glitch in that is that both probably are really looking for /usr/bin but this can be hidden by use of fstab and symlinks (/usr is symlinked to the appropriate directory which is then mounted, eg. /usr -> /usr.MC68010 etc.) The Sun setup programs lead one in that direction. I bring this up for two reasons. The first is that what appears to be a solution exists and I'd be curious what the problem with that really is, it adds no new features to the kernel and is fairly straightforward to implement. The second is that this scheme plus the extra inode for each binary probably takes up at least as much space as your scheme (ie. not much, but the Sun solution is also non-zero, there ain't no such thing as a free lunch) so Sun's comment on disk space does not seem to hold water unless I am missing something. Finally, with NFS spreading rapidly, I'd like to see this proposal include (and consider, eg. header space layout, byte order) the possibility of supporting many machine architectures simultaneously, not just the Sun cross-section. If this doesn't seem possible or practical then that should be explained (is it an example of the best being the enemy of the good? or just not laid out in general enough terms.) I think I'd also like to see thought towards using existing facilities. Maybe the right approach is to teach exec() about archives? Thus when an archive magic # is found in a header the executable is extracted and loaded (is this too much hair? just an example.) Of course, any of these naturally leads us towards some cacheing mechanism to speed up frequently used items on a particular machine (I dunno, sounds like a long route to get 'ls' loaded.) Not passing judgement, just trying to point out what I see as issues I don't see an obvious solution for off-hand. -Barry Shein, Boston University
guy%gorodish@Sun.COM (Guy Harris) (08/08/87)
> The second is that this scheme plus the extra inode for each binary > probably takes up at least as much space as your scheme (ie. not much, > but the Sun solution is also non-zero, there ain't no such thing as a > free lunch) so Sun's comment on disk space does not seem to hold water > unless I am missing something. The difference is that, unless there are separate sets of executables for servers and for other diskful machines, all machines would have executables containing code for all architectures with the "archived executable image" scheme; this isn't the case with the "multiple directories" scheme, since you can selectively pull in only the executables that are intended to run on the machine. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
sa@ttidca.TTI.COM (Steve Alter) (08/08/87)
It makes much more sense to stick with symbolic-links to the directories containing the binaries (just one executable per file) for whichever machine you happen to be running on. Mr. Tannenbaum noted that such is already the case on machines that have done dual-ports of BSD and SYS V, i.e. if you're running in BSD mode then /bin is really a symlink to something like /.bsdbin whereas the SYS V mode /bin is a symlink to /.attbin (we have a Pyramid that does something like this.) Additionally, SUN has done something like this too. We have a network of Sun 2's and Sun 3's that all have NFS-mounts to files on a common server. From the Sun 2, /bin is a symlink to something like /pub/MC68010.bin whereas from the Sun 3, /bin is symlinked to /pub/MC68020.bin. If you want to start archiving your executables and have the kernel do an extraction upon every invocation (even with supreme caching!) then you're just pouring your performance down the drain!
craig@srs.UUCP (Craig Schmackpfeffer) (08/08/87)
> 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. The cost in disk space and major rewrites wouldn't be worth it. Since Sun-2 binaries run on the Sun-3, why not just compile everything to Sun-2 format? If there is an application that needs the speed boost from the 68020's larger instruction set, then have a spare copy compiled on the Sun-3 (you can append a '20' to the name like dbx does). Craig Schmackpfeffer seismo!rochester!srs!craig -- --------------------------------------------------------------------------- Craig Schmackpfeffer ...!seismo!rochester!srs!craig or ...!seismo!rochester!ritcv!css5791
dan@srs.UUCP (Dan Kegel) (08/10/87)
Here's an alternative to conditional symbolic links: Make a program called 'machine' which senses machine type and exec's argv[0] from a machine-specific directory. Then make hard links to 'machine' for any program you need to tailor for the processor. We use this on our Suns for dbx and number-crunching programs; it works well. - Dan Kegel
randy@umn-cs.UUCP (Randy Orrison) (08/11/87)
The scheme that Apollo uses for multiple unvierses would work nice here.
The use environment variables in their links, which allows the links to
point to different things. e.g.
/bin is a link to /$(systype)/bin
/usr/bin is a link to /$(systype)/usr/bin
and they have /bsd? and /sys5. The same system could be easily adapted for
multiple processor types.
-randy
--
Randy Orrison, University of Minnesota School of Mathematics
UUCP: {ihnp4, seismo!rutgers!umnd-cs, sun}!umn-cs!randy
ARPA: randy@ux.acss.umn.edu (Yes, these are three
BITNET: randy@umnacvx different machines)roy@phri.UUCP (Roy Smith) (08/11/87)
In article <1853@megaron.arizona.edu> whm@arizona.edu (Bill Mitchell) talks
about whys and ways of merging Sun-[234] binaries into a single file to
make life easier on programmers.
We've got a similar problem. All our Suns are Sun-3's, but they
come in various flavors -- no hardware floating point, 68881 floating
point, and full-blown fpa. We've got programs that we want to run on all
the machines. Right now, we could compile with the -fswitch option, but I
understand that you get poor code that way. You're better off making three
separate binaries (with -fsoft, -f68881, -ffpa respectively) and using the
right one on each machine if you can afford the disk space. That's not so
bad for your own program where you can control which binary you run, but
how about something in a public bin that's going to be run by people who
may not even know what kind of machine they are on. Seems like the
solution to to Bill's problem would solve mine too.
BTW, does anybody know how hard it is to upgrade a non-68881 3/50
to add the 68881 chip? Do I just have to buy some chips and plug them in?
Move some jumpers? Send them back to Sun and pay them the difference in
the original purchase price to do the upgrade?
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016mangler@cit-vax.Caltech.Edu (System Mangler) (08/12/87)
In article <1857@megaron.arizona.edu>, whm@arizona.edu (Bill Mitchell) writes: > On the Suns however, if you want to have software on Sun-2s and Sun-3s, you > can compile Sun-2 binaries and run them on Sun-3s, but you miss out on some > of the good 68020 instructions. The larger problem with running Sun-2 binaries is that Sun-3s cannot demand-page them. Thus before suntools can start at all, the entire 700K text segment has to be loaded, in our case from a Sun-2 serving 16 NFS clients. Slowww... One easy solution to this problem would be to add a hybrid a.out format, using only 68010 instructions so that it will run on a Sun-2, but having the text segment rounded to an 8K boundary instead of 2K, so that a Sun-3 can demand-page from the executable. The cost in disk space would be small, the improvement in response time would be dramatic, and it should be trivial to implement, since the code is almost all there and in most places you'd just be duplicating one of the cases of a switch statement. Please? Don Speck speck@vlsi.caltech.edu {rutgers,amdahl}!cristsommuOrga
mangler@cit-vax.Caltech.Edu (System Mangler) (08/12/87)
In article <3570@cit-vax.Caltech.Edu>, I wrote: > The larger problem with running Sun-2 binaries is that Sun-3s cannot > demand-page them. I stand corrected; Sun-3's *can* demand-page from Sun-2 binaries. I must have confused model numbers and release numbers when reading pg. 5 of the SunOS 3.0 release notes: "The Sun3 release has a system page size of 8 Kilobytes (as opposed to 2 Kilobytes for Sun2 machines)". Don Speck speck@vlsi.caltech.edu {amdahl,rutgers}!cit-vax!speck
jgh@root.co.uk (Jeremy G Harris) (08/12/87)
To get really silly, you could carry the source along with zero-or-one executable images in each 'executable' file. The image would be tagged with the machine type, and the source with the commands to compile it. When trying to run a file, should the image be a) not the correct one for the machine or b) not present the compilation would be performed first to produce the image. To save space, on a well-set-up net you could point to a source-server rather than carrying the source. Jeremy Harris (I don't speak for my employers) -- Jeremy Harris jgh@root.co.uk
molly@killer.UUCP (Molly Fredericks) (08/16/87)
In article <288@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > In article <12646@sol.hi.UUCP>, kurt@hi.UUCP (Kurt Zeilenga) writes: > > 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. > > Has anyone done a simple stack machine that runs C programs > reasonably well? > > Is there enough interrest out > ther to justify the experiment? Anyone want to help? I recently posted in comp.lang.c looking for such a beasty. I would be willing to do some of the original work, such as writing a p-machine, but I think that's about all I've got time for. I haven't thought about the time needed to handle the libraries and all because I wanted the code for a compiler I'm working on ... Is there anyone out that wants to do the loaders, assemblers, compilers (no, I don't have time (or the sources) to handle a C compiler). I'd rather do a 2 address machine rather than a stack, especially since I don't know what the performance of an interpretive stack machine versus an interpretive normal :-) machine is like, but I suppose that all them pushes and pops gotta cost ya somethin'. Also, I cross-posted this into comp.lang.c. It probably really belongs in comp.compilers (or talk.bizzare), so would the next person please remove the comp.unix.wizards group since I can't imagine how this got here in the first place. Molly -- Molly Fredericks UUCP: { any place real }!ihnp4!killer!molly Disclaimer: Neither me, nor my cat, had anything to do with any of this "I love giving my cat a bath, except for all those hairs I get on my tongue" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mishkin@apollo.uucp (Nathaniel Mishkin) (08/17/87)
In article <1931@umn-cs.UUCP> randy@umn-cs.UUCP (Randy Orrison) writes: >The scheme that Apollo uses for multiple unvierses would work nice here. >The use environment variables in their links, which allows the links to >point to different things. e.g. > /bin is a link to /$(systype)/bin > /usr/bin is a link to /$(systype)/usr/bin >and they have /bsd? and /sys5. The same system could be easily adapted for >multiple processor types. Not a bad idea. However, in standard Apollo over-engineering mode (:-) I will raise the following concern with this solution: I might be surprised when I do the following from my Sun 3: cp //one_sun_4/bin/cat //another_sun_4/bin/cat (Use your imagination about what "//" means.) I will end up with a copy of the Sun 3 binaries sitting on my Sun 4. Perhaps we'll all learn to live with this phenomenon in the brave new world. Perhaps there are better solutions though. The "big a.out" solution is better in that the above wierdness doesn't occur, but it has all the problems that have previously been raised. It will be interesting to see how people will react. I can imagine plenty of people willing to trade disk space for ease of use. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {wanginst,yale,mit-eddie}!apollo!mishkin
allbery@ncoast.UUCP (08/18/87)
As quoted from <288@nuchat.UUCP> by steve@nuchat.UUCP (Steve Nuchia): +--------------- | In article <12646@sol.hi.UUCP>, kurt@hi.UUCP (Kurt Zeilenga) writes: | > 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. | | This is, of course, a viable idea. There are a large class of unix | utilities for which a well selected p-code implementation would | be "fast enough". If there were a primitive for each standard library | routine plus a few more a large number of the binaries posted could | be portable. Actually, they could almost all be portable but I'll | grant that you might not like to have to sit through a run of some of | them. +--------------- At least one interpreter of this general kind DOES exist on (non-BSD) machines. It runs at a tolerable speed for the majority of programs. It even has a means of expansion to add new features. Its major problem is not the implementation, but the language: Ryan-McFarland COBOL (ugh). Maybe we should ask for RM/C? -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" is changing its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". ***
randy@umn-cs.UUCP (Randy Orrison) (08/18/87)
In article <36b9fbe5.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: -In article <1931@umn-cs.UUCP> randy@umn-cs.UUCP (Randy Orrison) writes: -> /bin is a link to /$(systype)/bin ->and they have /bsd? and /sys5. The same system could be easily adapted for ->multiple processor types. - -Not a bad idea. However, in standard Apollo over-engineering mode (:-) -I will raise the following concern with this solution: I might be -surprised when I do the following from my Sun 3: - - cp //one_sun_4/bin/cat //another_sun_4/bin/cat - -(Use your imagination about what "//" means.) I will end up with a copy -of the Sun 3 binaries sitting on my Sun 4. Ah, but that's not a problem. Remember that /bin is a link to /$(systype)/bin, so what you're doing is: cp //one_sun_4/sun3/bin/cat //another_sun_4/sun3/bin/cat If you don't have directories for sun3 binaries on your sun4s, it doesn't work, and if you do, it ends up right where it belongs. (If you're using the type of the source/target node, however there's a problem with sun4 -> sun3, but using the type of the node you're on keeps it consistent, and is probably what you want.) - -- Nat Mishkin - Apollo Computer Inc. - Chelmsford, MA - {wanginst,yale,mit-eddie}!apollo!mishkin -- Randy Orrison, University of Minnesota School of Mathematics UUCP: {ihnp4, seismo!rutgers!umnd-cs, sun}!umn-cs!randy ARPA: randy@ux.acss.umn.edu (Yes, these are three BITNET: randy@umnacvx different machines)
daveb@geac.UUCP (Brown) (08/18/87)
In article <36b9fbe5.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >... I might be surprised when I do the following from my Sun 3: > cp //one_sun_4/bin/cat //another_sun_4/bin/cat >... I will end up with a copy of the Sun 3 binaries sitting on my Sun 4. Oh dear, I hope only the Translator_Search_Rules/Paths points at the Sun 3 libraries, and not the Command_Loader_Search_Paths/Rules. I'd really only want CP to come from the Sun 3 library. I'd want the operands come back with an "incomplete path specification" message because I didn't specify //one_sun_4/4/bin/cat. --dave -- David Collier-Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
pcl%robots.oxford.ac.uk@cs.ucl.ac.uk (Paul Leyland) (08/26/87)
In article <288@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > In article <12646@sol.hi.UUCP>, kurt@hi.UUCP (Kurt Zeilenga) writes: > > 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. > > Has anyone done a simple stack machine that runs C programs > reasonably well? > > Is there enough interrest out > ther to justify the experiment? Anyone want to help? The answer is yes. I have microcoded a C machine. The raw beast was built round AMD2900 series bit-slices. As the control store was in RAM, I could also convert it to a Lispkit Lisp machine and a BCPL machine. The C implementation was a double stack machine (one for scalars, return addresses, etc; the other for aggregates) with machine instructions for loading auto and static variables onto and off the appropriate stack; function call and return; arithmetic and logical operators; case selection and so on. Most C constructs compiled into a few instructions. The machine is still made, by High Level Hardware Limited of Oxford, UK, but it is looking a bit old fashioned now. Such copmputers *needn't* be slow. The Orion (for that is its name) has approximately the performance of a VAX750 but was significantly cheaper, 30-50% of DEC's price, when both were viable products. I guess that it should be easy to double the speed with today's technology but 4-5 times the performance would be tricky and that still only gives you a half-way decent 68020 based machine or a poor to middling VAX. If any one wants to help me make a fortune by coming in on the design, manufacture and selling of an up-rated machine though, let me know 8-) Paul Leyland JANET: pcl@uk.ac.oxford.robots How you get to talk to JANET is your problem - why not give her a call? ----- End Forwarded Message -----