Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!wca From: wca@oakhill.UUCP Newsgroups: comp.arch Subject: Re: M88000 power dissipation as a function of programming Summary: M88000 misaligned addresses Message-ID: <1377@claude.oakhill.UUCP> Date: 12 Jul 88 15:27:17 GMT References: <1370@claude.oakhill.UUCP> <10157@tekecs.TEK.COM> Organization: Motorola Inc. Austin, Tx Lines: 102 In article <10157@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) writes: > A few nits ... That's OK, Andrew, I deserve it. > r2: 0x55555555 > r3: 0xAAAAAAAA > 0xFFFFFFFC: > st r2,r3,r0 > br.n -1 > st r3,r2,r0 > > Under normal circumstances, each store will cause a misaligned data > access exception because the target addresses are not longword-aligned. > You can disable this exception by manipulating a bit in the PSR, but > I've never been able to figure out just what happens in that case, > except that a 68020-style unaligned longword store (straddling two > adjacent aligned longwords) doesn't. When the misaligned access exception is disabled (by setting the appropriate bit in the Processor Status Register) and a misaligned access is attempted, the M88100 rounds the address *down* to a consistent boundary. In the above case, a word access addressed for the location 0xAAAAAAAA will access (in this case, store) a full word of data (that is, byte strobe = 0xF) at location 0xAAAAAAA8. Clearly, this could create serious problems (!), so the moral of the story is that any programmer who disables the misaligned access exception better know what he/she is doing. Note that one use of this feature is in a tagged architecture application. > I-Address D-Address Data Byte Strobe > (30 bits) (30 bits) (32 bits) (4 bits) > -------- -------- -------- - > 3FFFFFFF 55555555 AAAAAAAA F > > You can't get 55555555 in 30 bits. The D-address will be 15555555. > Will the byte strobe really be F for this misaligned access? You're right, Andrew, the D-Address should be 15555555 (and the next D-Address in the cycle should be 2AAAAAAA). And the byte strobe is 0xF for this access, as mentioned above. In my enthusiasm to flip as many bits (and burn as many mW) as possible (and to keep the sample program as simple as possible), I blithely ignored the misaligned problem and committed the gaffe. If I use two more registers for the addresses 0x55555554 and 0xAAAAAAA8 (keeping r2 and r3 for the data as above), then I can write a program that does flip as many bits as possible and one gets essentially the same results as in the previous article (as far as power dissipation goes). That is to say, if we have: r2: 0x55555555 r3: 0xAAAAAAAA r4: 0x55555554 r5: 0xAAAAAAA8 and we run the code: 0xFFFFFFFC: st r2,r5,r0 br.n -1 st r3,r4,r0 then we get P-bus states that look like: I-Address D-Address Data Byte Strobe (30 bits) (30 bits) (32 bits) (4 bits) -------- -------- -------- - 3FFFFFFF 00000000 00000001 3FFFFFFF 00000000 2AAAAAAA 55555555 F 00000001 2AAAAAAA 55555555 0 3FFFFFFF 15555555 AAAAAAAA F 00000000 2AAAAAAA 55555555 F 00000001 2AAAAAAA 55555555 0 3FFFFFFF 15555555 AAAAAAAA F and so on. Or, I could disable misaligned access exceptions and use the original code for identical results (as far as the P-bus and the MC88100 are concerned; after all, this was the pathological example!) The remainder of the article (in particular, the power dissipation analysis for the M88K) is not affected by this correction in any substantial way. > -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] > (andrew%tekecs.tek.com@relay.cs.net) [ARPA] Thanks again for the correction, Andrew. The statements and opinions presented in this article are my own. They should not be interpreted as being the opinons or policy, official or otherwise, of Motorola Inc. /\ /\ William C. Anderson //\\ //\\ Member of the Motorola 88000 Design Group ///\\\ ///\\\ Motorola Microprocessor Division // \\ // \\ Oak Hill, TX / \/ \ / \