🚀 go-pugleaf

In article <1990Sep1.131041.15411@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
   howell@bert.llnl.gov (Louis Howell) writes:
   > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
   >|> [...] If you allow each compiler to make its own decisions about how
   >|> to lay out a structure, then you force _any_ programs sharing data
   >|> across comm links _or_ time _or_ memory space _or_ file storage to
   >|> be compiled with compilers having the same structure layout rules
   >|> designed in, or to pack and unpack the data with every sharing
   >|> between separately compiled pieces of code, [...]
   >In short, you want four types of compatibility: "comm links", "time",
   >"memory space", and "file storage".  First off, "time" and "file
   >storage" look like the same thing to me,
   [...]
   But if a program compiled with compiler A revision 1.0 stores data in
   a file, and a program compiled with compiler A revision 4.0 cannot
   extract it, that is a compatibility problem to solve of a different
   type.  Mandating no standard for structure layout forces programmers
   in both these cases to anticipate problems, unpack the data, and store
   it in some unstructured format.  Tough on the programmer who realizes
   this only when compiler A revision 4.0 can no longer read the structures
   written to the file with compiler A revision 1.0; it may not be around
   any more to allow a program to be compiled to read and rewrite that data.

I feel a little odd posting here, being radically anti-c++ myself, but
I *did* drop in and something about this thread is bothering me. (-:
(honestly!) Look, if you're going to take an ugly language and then
bolt on a kitchen sink and afterburners :-), why not put in the one
thing that is REALLY missing from C:

                    * STANDARD BINARY TRANSPUT *

Can't we have the compiler provide the trivial little shim function
that will read and write arbitrary data structures to binary streams?
Most operating systems now seem to have standard external data
representations, which are intended for precisely this kind of
purpose, and a "default" version would not be hard to cook up (or
appropriate). The runtime overhead is usually dwarfed by transput
cost, and you get better RPC support as a freebie. That way only the
*external* representation format needs to be specified, and the
runtime image can be as zippy as it please.

You can even read and write code if you're willing to interpret it -
or call the compiler, if you've got it kicking around.

   >As for "memory space",
   >I think it reasonable that every processor in a MIMD machine, whether
   >shared memory or distributed memory, should use the same compiler.
   >[...]

Ahem. Offhand I can think of any number of HETEROGENEOUS shared-memory
machines. Mainframes have IOPs. Amigae share memory between bigendian,
word-align 680x0s and littlendian, byte-align 80x86es (-: amusingly
enough you can do things about bytesex by negating all the addresses
on one side and offsetting all the bases, but... :-).  Video
processors with very *serious* processing power and their own
(vendor-supplied) C compilers abound. Now, I'll grant, a *real*
operating system, (-: if someone would only write one for me, :-)
would mandate a common intermediate code so that vendors only supplied
back-end, but even then I'm NOT going to pay interpretation overhead
on all variable accesses on, say, my video processor, my database
engine, by graph reduction engine and my vector processor, just
because my "main" CPU wants a certain packing strategy!

There *must* be a mechanism for binary transmission of binary data,
this must *not* be the programmer's responsibility, and while
localising all code generation in the operating system's caching and
replication component is the obvious thing to do, (a) that day hasn't
arrived yet and (b) the compiler will STILL have to get involved and
generate the appropriate type descriptors and shim functions.

stephen p spackman  stephen@estragon.uchicago.edu  312.702.3982