Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!appserv!sun!amdcad!dgcad!dg-rtp!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.lang.c Subject: Re: A quick question... Summary: details of a a word-oriented example... Message-ID: <1409@sheol.UUCP> Date: 18 Mar 91 00:54:09 GMT References: <1991Mar12.030759.26698@nntp-server.caltech.edu> <1991Mar12.062941.2369@nntp-server.caltech.edu> <24247@hydra.gatech.EDU> <1991Mar13.174154.12537@nntp-server.caltech.edu> <10953@dog.ee.lbl.gov> Lines: 84 > torek@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