Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!laguna.ccsf.caltech.edu!daveg From: daveg@near.cs.caltech.edu (Dave Gillespie) Newsgroups: comp.arch Subject: Re: What *should* architectural pointers point at? Message-ID: Date: 30 Aug 90 05:51:27 GMT References: <0887@sheol.UUCP> <41167@mips.mips.COM> Sender: news@laguna.ccsf.caltech.edu Organization: California Institute of Technology Lines: 95 In-Reply-To: mash@mips.COM's message of 29 Aug 90 06:00:33 GMT >>>>> On 29 Aug 90 06:00:33 GMT, mash@mips.COM (John Mashey) said: > In article <0887@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: >>Surely bit-granular addressing is the only sensible way to go... what >>reasons are against it in a 64-bit world? > I doubt this is the only sensible way to go, but it does lead to an > interesting exercise. Okay... You could provide two variants of the load/store instructions, one set that trap on unaligned accesses and one set that don't (but are possibly much slower). This latter instruction replaces the specialized "bit-field" instructions that some machines have now. Compilers could have an option to generate only the slow-but-safe instructions for the benefit of fast-but-reckless programmers. I've heard of at least one architecture (SPARC?) that uses this approach. It seems to me that a bit-addressed, aligned-accessing machine can be thought of as just like a byte-addressed machine with three zeros on the right that would have been on the left. (Once we are confident that bit-addressing doesn't cost too much from this point of view, we can go on to see what bit-addressing gains us beyond what we can do now.) The only problem I can think of is that you lose bits in your instruction word. I cringe every time I look at the 68000's short-branch instruction that uses an 8-bit displacement measured in bytes; instructions must fall on even addresses, so one precious bit of the displacement is completely wasted. Now imagine a bit-addressed 68000: four bits are wasted! Most newer machines (like the 88000) don't have this problem; they shift the displacement enough bits to the left so that all bits are useful. You would probably want to adopt this approach for all displacements. Accessing an aligned double-precision float with a 16-bit offset from the frame pointer wastes three bits now, but with bit-addressing it would waste six bits. On a machine like the 88000, there is a huge extra cost if the target doesn't lie within a 16-bit displacement of the index register, and this cost would become much more significant if you didn't auto-shift your displacements to avoid wasting those bits. Certain programming tricks (putting an odd address in a register and then using an odd displacement to access a word on an even address) would be much harder to do with auto-shifted displacements, but I don't think this would be a serious problem. It's much easier to be little-endian than big-endian if you use bit addresses. In bit-addressing, little-endian translates to "LSB is bit zero", and big-endian translates to "LSB is bit 31 (or 15, or 7, or 63, or whatever)". Just look at the 68020's bit-field instructions: Because the rest of the architecture is big-endian, they had to number bits from the left in the bit-field instructions, even though the rest of the architecture numbers bits from the right. If anything, switching to bit-addressing might put an end to one brand of flame war on comp.arch. :-) The hardware would probably be about the same. I hear really fast machines are limited by the carry chain in the incrementer for the program counter; this gets to be three bits shorter if the PC is a bit address. Those auto-shifted displacements might make your addressing unit a bit more complicated, but most new machines already have a shifter there to handle scaled indexing. I doubt software could tell the difference unless it casts pointers to ints and back. If you are writing a compatibility-oriented compiler, probably all your pointers will be multiples of eight. So you could cure even this by doing a three-bit shift when converting between pointers and ints. (Not that I'd advocate such a kludge for any purpose other than to provide an all-the-world's-a-VAX mode for those who absolutely must get software package X to compile effortlessly on your box.) Let's see... Operations on C character arrays now require shifts where previously they didn't. Many of these shifts can be factored into a scaled-indexing addressing mode, but some will not be so amenable. (For example, "p = p + i" or "i = p - q", with "int i; char *p, *q;".) Operations on BCD digit strings would be slightly cleaner. Some Lisp implementations stuff tag bits into the low two bits of a longword's byte address. Now you could fit five tag bits down there. Bit arrays are nicer to work with. It may now be practical to pack a Pascal "array of 0..3" into two-bit chunks, when formerly it might have been inefficient to do so. Features like subranges would suddenly be much more popular among programmers. Oh, no! This would give Ada an advantage over C. :-) Enough! It's someone else's turn now. -- Dave -- Dave Gillespie 256-80 Caltech Pasadena CA USA 91125 daveg@csvax.cs.caltech.edu, ...!cit-vax!daveg