negative addresses

Tim Olson tim at amdcad.AMD.COM
Wed May 11 06:36:35 AEST 1988


Note: I am also including comp.lang.c, since this also pertains to C...

In article <2393 at uvacs.CS.VIRGINIA.EDU>, wulf at uvacs.CS.VIRGINIA.EDU (Bill Wulf) writes:
| Has anyone ever seen a machine with "negative addresses", that is, one
| where the address space is -2**31..2**31-1 rather than 0..2*32-1??
| Any thoughts on what the problems with such a scheme might be (or are)?

I can't think of any real problems offhand, but this representation
affects a few things:

Your program's virtual address space probably starts at -2**31,
rather than 0 (to give you the full range).  This means that C-language
null pointers, because they are defined never to point to a valid
address, will probably have to be something other than the standard
all-zero bit representation.  This is not a real problem, as C allows
this.  However, it complicates the compiler somewhat (having to detect
the assignment/comparison of a pointer and the integer constant 0 as a
special case).  Also, buggy programs that used to run with references
through uninitialized static pointers might break in horrible ways (this
is not necessarily bad! ;-)

| Why ask such a question, you ask -- well, I'm trying to remove unsigned
| arithmetic from WM, and as far as I can tell, the primary (only?) use
| of unsigned arithmetic is for address computations. Soooooo...

What about support for explicit unsigned types in HLLs?  This would only
work if you limited the range of "unsigned" values to 0..2**31-1, rather
than the full 32-bit range.  However, my copy of the ANSI C Draft Spec
(which might be out of date) says:

	"For |signed char| and each type of |int|, there is a
	corresponding unsigned type (declared with the keyword
	|unsigned|) that utilizes the same amount of storage including
	sign information.  The set of nonnegative values of a signed
	type is a subset of its corresponding unsigned type."

	-- Tim Olson
	Advanced Micro Devices
	(tim at delirun.amd.com)



More information about the Comp.lang.c mailing list