machines with oddball char * formats

[Stuart D. Gathman]

In article <177 at houligan.UUCP>, dave at murphy.UUCP (H. Munster) writes:
> I can think of one, from my college days: the Univac 1100 mainframes.  I have
	[. . .]
> First of all, the machine uses a 36-bit word size.  Normally, addressing
> is done in words; a pointer to a word is a 36-bit type (of which only 18
> bits are normally used, but let's not worry about that).  However, to
> address anything smaller than a word, a wierd "byte pointer" format is
> used; this format has an 18-bit word address field, a 3-bit field that

The DEC-10 (and DEC-20 I assume) also have this addressing format.  The
C compiler uses, as you expected, 9-bit chars, 18-bit shorts, and 36-bit
ints and longs.  All pointers are 36-bit (the word pointers use the
first 18 bits for specifying indirection and an index register), but
with three different formats.  Since instructions using index registers
(like accessing the stack and structure members through a pointer) require
copying the 18-bit part to a work area or register anyway and are so common,
you could probably reasonably make word pointers the size of shorts.  (But
this would of course break all the brain-damaged code that assumes
sizeof(int)==sizeof(int *)).

The actual C-implementation that I have seen, however, stores pointers
as follows:

	type		0 . . . . . . . 17 18 . . . . . . . 35
	word		18-bit address     0
	short		18-bit address	   0400000 or 0
	char		18-bit address	   0 through 0600000

This is so that brain damaged code that assumes sizeof(int)==sizeof(int *)
*and* doesn't bother to convert pointers doesn't break.  (Incrementing
a character pointer by sizeof(foo) and then passing without casting
to a function expecting (foo *) still works with this setup.)  The result
of this is that code must be generated to convert pointers every time
they are referenced (instead of just when converted via cast).
-- 
Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!bms-at!stuart>