🚀 go-pugleaf

In article <jgkDFG9HJ.49x@netcom.com> Joe Keane <jgk@netcom.com> writes:
>This is an architecture and a language issue.

(I have more or less removed the architecture issue from this, so
probably should have removed comp.arch from the newsgroups, but...)

>[T]he Alpha ... has instructions for 32-bit [integer operations].
>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 is true in the same sense that a 68020 using 16-bit `int's is
a 16-bit machine.  That is, the internal busses in the CPU are all
twice as wide, so while the Alpha is perfectly capable of doing
both 32 and 64 bit operations, it is really a 64-bit architecture.
It just gives you an easy way to toss out the upper half of the result.

>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.

This is true.  But that does not mean there should necessarily be
a compiler option to make `int' 32 or 64 bits.  If the C compiler
flatly refuses to do anything but 32-bit `int's, this problem
vanishes.

>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.

Not really, because no one ever promised that `int's were big enough
to hold pointers, and there are no 32-bit pointer formats on the Alpha.
I know nothing about 16-bit Mac applications, but 16-bit Windows
applications use native 16-bit pointers.

>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.

The `SBEIR proposal', recently discussed to death in comp.std.c,
does exactly this.  I, however, believe you are overestimating the
usefulness of `at least' and `exact' bit-sizes, and the extent to
which they will improve the situation.  (Time may tell, since the
SBEIR extensions are, they say, being put into a version of GCC,
and will thus be available to anyone via the GNU Copyleft.)
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA	Domain:	torek@bsdi.com	+1 510 549 1145
  `... if we wish to count lines of code, we should not regard them as
   ``lines produced'' but as ``lines spent.'' '  --Edsger Dijkstra