Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.arch Subject: Re: What *should* architectural pointers point at? Summary: I still say "bits" Message-ID: <0899@sheol.UUCP> Date: 2 Sep 90 03:27:13 GMT References: <41188@mips.mips.COM> <26DE7EE3.58FC@tct.uucp> Lines: 81 > From: mash@mips.COM (John Mashey) > However, it is still clear that bit-addressing would break more programs > than byte-addressing, so all I wanted was for someone to work through > a complete example to show why it would be A Good Thing on balance. Looking at it from another perspective, I think it certain that many, many MORE programs (and mostly the same sloppy programs, BTW, IMHO) will be broken by making pointers 64 bits long, whether or not integers are also made 64 bits long. Further, programs that count on pointer formats being byte granular are already not maximally portable, since many machines are still word addressed (though, granted, this is becomeing quite rare). This in mind, the backwards compatibility issue is a small one, IMHO. Of course, the complete example showing the net effects is a good idea. > From: daveg@near.cs.caltech.edu (Dave Gillespie) > 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)". Well, OK, but why go after the least significant bit anyways? Isn't it more likely to be needing the MSB (at least, for many operations)? Or, to put it another way, I think the situation is still balanced endian-wise on a bit-addressed machine. Some operations are easier on little-endian machines, others on big-endian. Certainly as a practical matter, a bit-addressed machine can quite easily be big-endian: the bit-addressed machine I'm most familiar with was big-endian for example, and this didn't interfere with the addressing granularity one whit. > From: chip@tct.uucp (Chip Salzenberg) > I would not so blithely throw away 15/16 of my address space. Why not? You are (or at least the industry at large is) willing to throw away 3/4 of it so that addresses are byte-granular despite the fact that so many loads/stores are 32-bit aligned. What's that I hear from the cheap seats? It's important to be able to reference characters, since so many things are text-oriented? Really? So why isn't it important to indicate pixels, bitmaps, positions in huffman (and other bit granular) code strings, page table property bits, boolean arrays, and any of the other zillions and zillions of naturally-bit-granular things that abound in the software written every day? I still claim that trading address space for finer granularity is a Good Thing (even a Very Good Thing), IF we are talking about at-least-64 bit addresses. (I'd even argue it for 32 bit addresses, but even I have to admit it's dodgier there.) > From: daveg@near.cs.caltech.edu (Dave Gillespie) > 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. From the rest of Dave's posting, it's not clear to me that he's really objecting to bit-granular addresses on the above grounds. (In fact, it seems not to be the case.) But let me respond as to a hypothetical person who *does* think this is an objection. I hope Dave takes no offense. The point is, why use a naive encoding? Presumably a RISC would insist on word-of-some-size aligned istreams, so word-granular offsets in instructions would remain, just as today. Similarly for offsets and partial addresses in instructions that manipulate other aligned things. Sure, let the people who want to operate on entities of bit granularity pay for the privilege. But there's no reason to require them to tie their hands behind their backs and stand on their heads and spin hula-hoops on their feet while they type with their noses either. -- Wayne Throop !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org