Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!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: 31 Aug 90 08:22:49 GMT References: <0887@sheol.UUCP> <2491@l.cc.purdue.edu> Sender: news@laguna.ccsf.caltech.edu Organization: California Institute of Technology Lines: 63 In-Reply-To: cik@l.cc.purdue.edu's message of 30 Aug 90 12:37:51 GMT >> 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! Herman Rubin responds in <2491@l.cc.purdue.edu>: > We are discussing machines where the memory is sufficiently large that > 32-bit addressing is inadequate. Four bits is 1/16 of an address. That's not the point. The 68000 puts a short branch in a 16-bit instruction. Eight bits of that instruction encode the displacement. Using a naive encoding, you are wasting four of eight bits, *NOT* four of 64. The problem here is wasting bits in the instruction word, which reflects directly on performance unless your instruction cache is 100% perfect. >> 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. > There are quite a few machines now which have both addresses and indices. > For an index, the appropriate shifting is done. This is not new hardware. I don't think you are using the terminology in quite the way I do, but, yes, the hardware is already there, which is why I mentioned the idea shortly after this paragraph. >> Again, we are discussing 64-bit address machines. "Wasting" even 8 bits >> in addressing is only 1/8 of the length of an address. Once again: Many compilers for 68000-style machines require functions to have no more than 32K bytes worth of local variables. This is so that they can use a fast 16-bit displacement from the frame pointer to refer to those variables. Without auto-scaling, those same 16-bit displacements now allow only 32K *bits* of local variables. So to do the same job a 68000 does now would require a compiler to generate longer displacements, i.e., larger instructions, which take more time to fetch from memory, which in turn slows everything down. Many new machines support auto-scaling of index registers, but none that I have seen support auto-scaling of fixed displacements in the instruction word. I was trying to show why bit addressing would create a much more compelling need for this feature. Of course, few functions have more than 32K bits worth of locals, so perhaps it's not that great a sacrifice. But compilers that previously could get away with imposing a hard limit to make their code generators simpler would now pretty much have to be willing to generate longer displacements when the need arises. Many architectures, like the 68000 and the 88000, make full 32-bit displacements significantly slower or more awkward to use. -- Dave -- Dave Gillespie 256-80 Caltech Pasadena CA USA 91125 daveg@csvax.cs.caltech.edu, ...!cit-vax!daveg