Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!vsi1!daver!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: RT/PC Unaligned Accesses Message-ID: <16420@winchester.mips.COM> Date: 2 Apr 89 07:44:03 GMT References: <4618@pt.cs.cmu.edu> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 63 In article pgc+@andrew.cmu.edu (Paul G. Crumley) writes: ....good tutorial on way RT/PC works.... >The processor has instructions that load and store bytes, halfwords and words. >For halfword accesses (both load and store)the LSB is silently forced to a zero >and for word accesses the two LSBs are silently forced be zeroes.... ... >"How can one write a correct program on a machine that drops the bits and >doesn't report any exceptions?" If you have a program that runs correctly on >some other processor and you have used language supported ways to create new >objects, this program will run correctly on an RT/PC... ... >As with all implementations there are trade-offs. The silicon saved in the MMU >by not supporting arbitrary alignment was put to good use. The RT/PC operates >more reliably and with higher performance than many similar systems. When good >compilers are used, the current RT/PCs, models 12X & 13X, perform very well. Is there any chance of posting some data in support of 1) "more reliably", and 2) "with higher performance" or at least perhaps specifying what "many similar systems" refers to? or what "performs very well" means? (I'm sure it wasn't meant this way, but this read like: "It's better to do it this way because it's better than (unspecified) Brand X or Y. This sort of dataoid is hard to evaluate.) Note that at least some other RISCs support extensive use of parity or ECC, for example. Are there published numbers for 12X & 13X? >..... Though the dropping of >low order address bits may seem to prevent any hope of producing correct object >code, we see that such concerns are not a problem. If there are problems with >the way a program accesses data on the RT/PC, there are problems with that code >on other machines too. I think the discussion got inverted. I can't imagine there being any problem running CORRECT, portable code, on an RTPC, that ran correctly on machines that enforced alignment. But, that isn't the problem, which is in debugging programs. The RT/PC design is the only one I can think of offhand that made this particular choice. Most machines: a) Support unaligned data in general. OR b) Trap on unaligned references I observe in my experience that a trap caused by an unaligned reference is one of the commonest first indications of error in a program. For what it's worth, as an example, let me illustrate this with a story from a long time ago. At school, we used to have 360/xx computers, which used approach b). We then got a 370/xxx, which used a). Our computer center actually requested a price from IBM for a mode that would retain the 360 behavior, because they went thru their list of APARs (trouble reports), and discovered that something like 50% of them were first discovered by encountering an alignment error. [The price was too high, unfortunately.] Anyway, it seems that either a) or b) is viable; at least if you have a), although you lose the debugging assist, some kinds of code are certainly more convenient. In this particular area, it seems that the RT PC made an unusual tradeoff, very different from the rest of the RISCs, for no reason that is yet obvious. It's truly hard to believe that with 2 whole VLSI chips to implement CPU + MMU, that a few gates couldn't be found to implement the alignment check....so please say more, maybe I've missed something. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086