On Sat, Jul 30, 2005 at 06:49:53PM +0200, Rhialto wrote:
> On Fri 29 Jul 2005 at 08:16:16 -0500, Richard Rauch wrote:
> > There were two classes of software that had a VERY HARD TIME running
> > on NetBSD/amd64: LISP implementations and web browsers.  (At least,
> 
> People who write such programs should be vigorously treated with the
> clue bat. 64 bit machines have existed for many years, there is simply

The same sorts of problems were seen 20 years ago, or so, when personal
computers moved towards 32 bits.  I remember lots of people assuming
that they could declare a pointer as an {int} if they were not going
to dereference it (this was in the K&R days when men were men and sheep
were scared; (^&).  That bit me with example programs, since the compiler
I learned with (Aztec C on the Motorolla 68K) used 32-bit pointers and
16-bit integers.

This is deja vu for me, as personal computers (if you prefer,
*commodity* computers) slide into the 64-bit realm and software
developers (though without as much excuse as K&R C afforded those
that use C/C++) either forgot those lessons or are too young to
have ever learned them.

But, the web encourages a sloppy approach to encoding information
I think, where many people just worry about what works with their
system (web browser) and assume that everyone has the same system.
At least, that's my hypothesis to explain why web-browsers had so
much trouble on the AMD64.

And LISP...well, I like LISP, don't get me wrong.  But it has pointers,
while at the same time being a typeless language.  You certainly are
discouraged from ever thinking about the size of anything.  (As the
old saying goes: LISP programmers know the value of everything and
the cost of nothing.  (^&)  The idea is that the only things you
have are CONS cells (with a CAR and CDR), and the only way to hold a
ref. to a CONS cell is in something that can be copied to/from a CAR
or CDR.  Everything else (string, integer, float, rational, complex,
vector, ...) is more or less in the interpretation; you can still
copy data around between variables fairly freely.


I actually wonder a bit that people don't use 64-bit integers on
the AMD64 for C's {int}.  What are the reasons?  Would it make
programs *that* much bigger/slower?  (Yes, it would affect caching.
Yes, it would require larger constants, larger stack frames, etc.
But a lot of protability issues would not have existed if GCC had
arranged that {sizeof (int) == sizeof (void *)}.)


> ne excuse to write a program that doesn't work on them. I personally
> have an Alpha for over 5 years now (now also an amd64).

Yeah, I know.  But the Alpha has 64-bit {int} with its C compilers,
doesn't it?  The sloppy assumption that an {int} is the same size
as a pointer is probably the biggest problem I've seen.  Relatively
little code is bothered by 64-bit pointers, per se, or by the
fact that the CPU can directly manipulate 64-bit values.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/