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

Unless you want to put EMS/XMS/whatever into the language pointer-fetch 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

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B