🚀 go-pugleaf

here's a question about "the large body of existing C code"...
how many programmers assume that the address of a struct is the same
as the address of its first member?  or that the members are arranged
in address space in the same order they appear in the struct definition
in the source code?  i wrote a program once that did that first evil,
but now i realize that K&R never claims it'll work, and also there
are legal ways around it that take no time or space.  it seems like
as long as programmers don't do that kind of junk, then (having a
compiler) sort the members of a struct by size is painless and free.

i personally have always been willing to do bizarre things in the name
of performance (like keep 2 copies of registers--now That's unconventional,
but if it helps, great.)

advSORRYance if i screw this all up; i've barely ever posted before.

let me say however, what a pleasure it's been to read your group for
the past half-year; it's so refreshing to hear people who know how it
works talk.  most programmers (even highly-paid ones) wouldn't know
which end of the soldering iron to hold (at least for about 60 seconds);
most folks around here, if they bought more dynamic memory chips
for their mac would ask why you have to malloc() it and can't use
it for stack.

thanks again for illuminating talk and the HOT hardware.  those 98X,
those R2000, those 88K, 29K, those Sun4, that VLIW, killer stuff.  i can't 
believe how far we/YOU've come in the last 5 years.  Running apps on
a Sun4 with an Iris4D as the XServer hauls butt.  Way faster than the
Cyber I used to keypunch for, seems like.

  T--T   Les Milash (w)303-443-6961 graphix s/w slave, Unicad Inc.
 /| /|   (h)303-444-8552348 Arapahoe #17 Boulder CO USA 80302
T-+T |   my opinions are so different from those of my employer :-(
| T+-T   that i often look for a different employer :-)
|/ |/    and that's what these are.
T--T