Subject: Re: bin/3277: mail can't count
To: None <netbsd-bugs@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: netbsd-bugs
Date: 03/06/1997 18:23:09
> There is absolutely no reason to associate the bit size of an integer
> with address space.
Well, there are several pragmatic ones, actually. :-) They do tend to
go together; indeed, if anyone knows of a machine where an int has more
bits than a pointer, I would be fascinated to hear more about it.
> There are a fair number of systems [...] on which int and long are
> different sizes, and pointers are as big as long... It's called
> MS-DOS in <foo> mode. (I can't recall what <foo> is...)
Any in which the default pointer type is far. Large and huge, I think
they're usually called. (If any DOS compiler has a mode where pointers
are huge by default, that would probably qualify too, but I don't know
of any. I've often thought it would be the only sane way to do C under
DOS, because it preserves the flat-address-space model.)
Of course, even far/huge pointers don't _have_ to be that big; there's
no reason they couldn't be as small as two and a half bytes (though
admittedly three bytes is probably more practical; if nothing else,
conformance with a data type occupying a non-integral number of chars
is somewhere between difficult and impossible). By my understanding,
anything over 20 bits is perforce wasted, in an information-theoretic
sense.
Unless you want to put EMS/XMS/whatever into the language pointer-fetch
code...in which case, heck, you could do pointers over 32 bits on a
SPARC by paging from disk "by hand", if you're willing to go that far.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B