🚀 go-pugleaf

This is an architecture and a language issue.

The Alpha people often point out that Alpha is a `pure' 64-bit architecture,
instead of a 32-bit architecture extended to 64-bit, like say SPARC and MIPS.
This sounds to me like a good story; certainly if i got to design a brand new
architecture for the next 30 years, i'd make it clear that it's really 64-bit,
although it would also have good support for smaller and larger data types.

Then look at the Alpha instruction set.  It has instructions for 32-bit add,
subtract, and multiply.  It also has instructions for 32-bit load and store,
even though it *doesn't* have single instructions for byte load and store!
That seems just a bit peculiar for a `pure' 64-bit, byte-addressed machine.
Now there's nothing wrong with that, having support for 32-bit operations,
it's just that when you look at it, it looks no different from SPARC V9.

If it seems a bit ambiguous at the assembly level, look at the C interface.
For integer types, `int' is usually the `natural word size' of the machine,
and it's common that `short' is a half-word, and/or `long' is a double-word.
If you look at the Alpha, this scheme fits perfectly: it's a 32-bit machine.

This can be changed with compiler switches that specify what size `int' is,
but that won't solve the problem without creating more compatibility problems.
For example, when you call "fscanf(fp, "%d", &value);", we need to be clear on
what size `value' is meant to be, or you get nasty memory corruption problems.
There are lots of other, similar problems to worry about, like file formats;
we need to agree on whether various integer values are 32-bit or 64-bit.

In fact, the situation with Alpha is very similar to the current situation
with Macintosh and 16-bit Windows programs, with the sizes doubled of course.
You will run into the same types of problems around 2 GB on the Alpha as we
currently run into at 32 KB with Mac and Windows programs.  Of course these
things can be fixed and they probably will be, but it's better to avoid them!

I think that we can see the problem here: we're straining C's type system,
because the usual `char', `short', `int', and `long' just can't cover enough.
I'd very much like to see some sort of de-facto standard way to specify the
number of bits for an integral type, with both `exact' and `at least' sizes.
This would make it easier to write portable programs, without a lot of crap,
and it would return old types like `int' to what they're supposed to be.

--
Joe Keane, professional programmer