A quick question...

[Wayne Throop]

> torek at elf.ee.lbl.gov (Chris Torek)
>>	*((short *)arrayptr)++ = othervalue();
> But this does not mean anything. 
> [.. general explanation of why omitted... skip to the specific example ..]
> I will take a typical C compiler for a Data General MV series machine.
> The Data General MV series has two kinds of pointers, `byte pointers'
> and `word pointers'.  Both are 32 bits long, but one looks vaguely like
> this:  WWW...WWWI  [note: I am deliberately leaving out the ring stuff]
>                    (mostly because I cannot remember how it worked)
> and the other like this:    BWWW...WWW
> where W is a word address, `I' is an indirection bit (normally 0), and B
> is the index number of a byte within a two-byte word.

Well...  Chris has the ideas right, but as he forwarned, the specifics
are slightly off.  But, his description of how one can "head off into
the ozone" by pointer punning is correct in essence.  Also, I think
other once-widespread word oriented machines do/did it the way Chris
outlines above. 

But to go into boring detail in the DG case, this all started with the
word-oriented NOVA architecture, which had no byte operations, and no
byte-granular addresses supported by single instructions.  It's 64Kbyte
address space was addressed as 32K words, with an indirect bit.  These
machines and their descendents were big-endian, and I'll write the bits
in decreasing significance.  The NOVA address layout was
                                              IWWWWWWWWWWWWWWW

Then byte operations were added to the instruction sets of these
16-bit machines (using a trick that deserves an essay all on its
own, but I digress...), giving the "Eclipse" series.  The indirect
bit was dropped, and a byte address was formed in the "cannonical"
way, giving the two addressing formats, word: IWWWWWWWWWWWWWWW
(just as in the NOVA) and the new byte:       BBBBBBBBBBBBBBBB.

Thus, a byte address was gotten by left-shifting a word address one bit
(losing the indirect bit in the process) and adding a 0 or 1 to the
resulting integer representation to indicate which byte in that word was
meant.  The resulting byte address was pretty much the familiar address
you'd find on most byte-addressed big-endian machines.

Then things were expanded to 32 bits with eight rings, by adding yet
more instructions to act on "wide" addresses (mostly the same mnemonics
with "W" prefix (and other prefixes and suffixes in a scheme that would
take yet *another* essay, but I digress again)).  In this scheme, word
addresses were:           IRRRWWWWWWWWWWWWWWWWWWWWWWWWWWWW 
and byte addresses were:  RRRBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

There are also bit addresses to handle bit-granular accesses, which are
32 bits long in the 16-bit Eclipses, and (I think I remember) 64 bits
long in the 32-bit "MV series" Eclipses, and special instructions to
manipulate bits, and other special instruction formats that give faster
access to certain regions of the address space reachable with short
offsets, and wide and narrow stacks, and some historical glitches about
where the stack pointers pointed, and so on and on.  But the above
suffices to give a flavor of the thing. 

One "nice" thing about the shift involved in going from one type of
pointer to the other: in the ring-protected MV series, this meant that
you would get an access violation if you used the wrong flavor pointer,
instead of just trashing something random.  (Unless this bug was in
the kernel and the other ring had something mapped and... well, you
get the idea.)

The result was that DG compilers had a hard time, because much C code
exists which assumes that all pointers have the same format, despite
the fact that even K&R explicitly warned against this sort of thing.
Detailing the tradeoffs that were made in compiling C code for MV
machines is (you guessed it) another essay's worth.

---

( It is almost frightening to think of, but despite my frequent
  references to details I've left out of the above, there were even
  more endless details left out that I didn't even mention.  So, if
  you are a DG fan, and are tempted to tell me about the earlier
  origins of the byte pointer format than the Eclipse instruction
  set, or about various gradiations of Eclipse stuff, have more pity
  on me than I've had on comp.lang.c, and spare me.

  So what's frightening about it?  Well, the fact that I *know* about
  all this useless stuff, taking up memory space better devoted to
  other things... THAT's what frightening! )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw