Re: large NPOT rowbytes
Re: large NPOT rowbytes
- Subject: Re: large NPOT rowbytes
- From: Jerry <email@hidden>
- Date: Thu, 2 Dec 2004 14:23:08 +0000
On 2 Dec 2004, at 14:02, Holger Bettag wrote:
On Thu, 2 Dec 2004, Segher Boessenkool wrote:
So C/C++ offers the type 'int' as the largest integer type for which
the hardware offers a full set of computational operations, and the
type 'long' as the largest integer type that the hardware natively
supports at all, possibly incompletely.
Sorry Holger, but that is the worst rubbish I've heard in days.
Thanks, that was very constructive. :-)
Although that might be true for some C implementations, it has
nothing to do with the language at all.
I wasn't around when K & R devised the language, but that was the
explanation I got for the existence of both 'int' and 'long' as
distinct
types.
Who knows, long ago in a prehistoric age of computing, there might have
been machines with distinct address and data registers (like 68k), with
address registers being wider than data registers (unlike 68k), and
with
add and subtract the only computatations allowed on address registers
(like 68k), while the data registers enjoyed booleans, shifts/rotates,
and
multiply/divide as well (like 68k).
On such a hypothetical machine, a distinction between int and long
would
make sense the way I explained it earlier. (The 'long long' type was a
late addition to the language.)
It's a long time ago now, but I used to program DEC-10 machines where
pointers consisted of (I think, - the details are hazy now) a 18-bit
word address plus a 6-bit byte size and a 6 bit bit-offset into 36-bit
words. Incrementing pointers caused a jump in the value of the pointer
every 4 bytes as it skipped over the unused 4 bits at the end of each
word.
Any sort of fooling around with pointer arithmetic and casting to
integers was an extremely dodgy proposition. Ah, those were the days,
when programmers were real programmers...
Jerry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden