From: billb@nasty (Bill Burcham)
Subject: Re: NeXT's binaries need a diet
Organization: First National Bank Of Chicago, Chicago IL, USA
Date: Wed, 18 Nov 92 23:29:47 GMT

In article <Uf13FDq00iV2E6L31w@andrew.cmu.edu>  writes:
> Excerpts from netnews.comp.sys.next.advocacy: 12-Nov-92 Re: NeXT's
> binaries need a .. by @RedBrick.COM 
> >   Indeed fat binaries are a "cool" idea.  I just question your 30%
> >   figure.  Do you have this on some authority from somewhere?   
> 
> Not on authority, no.  But try using "size" on some NeXT executables and
> see what you get.  Here's some figures (compare __TEXT to dec):
[munch data]
> 
> A little work with awk gives the sums for columns 1 and 5:
> 1.06M / 2.47M and 239K / 950K.  For /bin/*, 2.29M vs 4.35M.
> That's about 30%...
> 
> 
> > [munch]
> >   machine independent.  I guess strings MIGHT be, but numerical
> >   constants certainly aren't unless there is someway of doing
> >   all the necessary byte and bit swapping when you load the module
> >   (for instance 680x0s and 80x86s have different endian and 
> >   byte swap requirements), and floating point constants are also
> >   probably different from machine to machine.  Any constant
> >   data structures might have alignment differences (you mentioned
> >   that but made light of it).  More importantly, I would doubt
> >   that a binary is only composed of 30% code, probably more like
> >   80% at the least.        
> 
> Alignment constraints aren't going to differ that much between 2
> different 32-bit processors; just select the greatest required alignment
> for the CPU types in question and you'll be fine.  To deal with raw
> binary representation differences (byte ordering) between CPU's isn't
> that bad either; the loader can do that automatically.  Floating point
> can be standarized on the IEEE 754 representation (which has pretty much
> happened, anyway).
>   
> >   As a side note, what happens to object archive files?  Are they
> >   portable across environments?  If so, how is this handled?  Does
> >   the 486 AppKit adapt to the 680x0 object format when loading and
> >   writing object archives?  If not, what happens if I try to
> >   initialize a 486 application with the nib file from a 680x0
> >   IB session?  
> 
> This is a problem for NeXT to answer (assuming NeXT does offer
> FatBinaries); I can think of a solution or two, but I'm not going to be
> the one to have to code it.
> 
> -Chuck
[munch]
> 
> +------------------------------------------+ "Foosh.  Aaughh!!"
> | Charles William Swiger -- CMU...crunch!  | "Foosh.  Aauuggghh!!"
> | AMS & normal mail: cs4w+@andrew.cmu.edu  | "Cold spray deodorant...."
> | NeXTmail: chuck@mon.slip.andrew.cmu.edu  |
> +------------------------------------------+   -- Opus, Bloom County  
[RIP]

30% huh.  Well, have you _ever_ seen a NeXT app that takes up more than  
one or two floppies?!?  I am really tired of people whining about how  
overweight all our deliverables will be on the danged newfangled  
object-oriented systems.

WRT archives (Typed Streams):  YES they are portable.  YES nibs are  
portable between different-endian machines.  The only thing that is not  
portable is that (30%) object code.

Now if we want to have a constructive discussion we could talk about  
things like:

1) Why isn't NeXT talking about shipping a cross-compiler so that I don't  
have to have one of each of the target systems running NeXTSTEP in order  
to create my fat binaries.

2) Why doesn't someone work out a way to ship an intermediate rep. or the  
executable image so we don't have to have fat binaries.  Once (1) is  
accomplished, we could pretty much have this one solved:  just put a  
switch on the Objective-C++ compiler to have it output it's intermediate  
rep. of the code for each source (make up a new suffix).  Now we could  
have a bootstrap loader for each target that would essentially finish the  
compile on the target machine and then do the link.  Am I nuts or what?  I  
believe the reason NeXT isn't doing this is because they want us to be  
able to have fileservers shared betw. different-endian systems any of  
which may run the (fat)binaries thereupon.  I guess it is a bad idea for  
now.
--
+--------------------------------+----------------------------------+
|          Bill Burcham          | "Make no small plans; they have  |
| First National Bank of Chicago | no magic to stir men's souls"    |
|    billb@fnbc.com  (NeXTmail)  |      Daniel J. Burnham           |
+--------------------------------+----------------------------------+