| Chunky 2 Planar Guide v0.1 |
Input a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 e7e6e5e4e3e2e1e0 f7g6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 Output a7b7c7d7e7f7g7h7 a6b6c6d6e6f6g6h6 a5b5c5d5e5f5g5h5 a4b4c4d4e4f4g4h4 a3b3c3d3e3f3g3h3 a2b2c2d2e2f2g2h2 a1b1c1d1e1f1g1h1 a0b0c0d0e0f0g0h0-2- Primary C2P tool: Transposition
ab __\ ac cd / bd-3- Transposing 8x8
a7a6a5a4 | a3a2a1a0 b7b6b5b4 | b3b2b1b0 c7c6c5c4 | c3c2c1c0 d7d6d5d4 | d3d2d1d0 ---------+--------- e7e6e5e4 | e3e2e1e0 f7f6f5f4 | f3f2f1f0 g7g6g5g4 | g3g2g1g0 h7h6h5h4 | h3h2h1h0and here's the transpose, split into 4x4-size blocks:
a7b7c7d7 | e7f7g7h7 a6b6c6d6 | e6f6g6h6 a5b5c5d5 | e5f5g5h5 a4b4c4d4 | e4f4g4h4 ---------+--------- a3b3c3d3 | e3f3g3h3 a2b2c2d2 | e2f2g2h2 a1b1c1d1 | e1f1g1h1 a0b0c0d0 | e0f0g0h0-4- Notes on 8x8 traspositioned
a3a2a1a0 b3b2b1b0 c3c2c1c0 d3d2d1d0and:
a3b3c3d3 a2b2c2d2 a1b1c1d1 a0b0c0d0-5- Transpositions that do C2P on 8x8
a7a6a5a4 | a3a2a1a0 b7b6b5b4 | b3b2b1b0 c7c6c5c4 | c3c2c1c0 d7d6d5d4 | d3d2d1d0 ---------+--------- e7e6e5e4 | e3e2e1e0 f7f6f5f4 | f3f2f1f0 g7g6g5g4 | g3g2g1g0 h7h6h5h4 | h3h2h1h0Split up into 2x2-size squares:
a7a6 | a5a4 | a3a2 | a1a0 b7b6 | b5b4 | b3b2 | b1b0 -----+------+------+----- c7c6 | c5c4 | c3c2 | c1c0 d7d6 | d5d4 | d3d2 | d1d0 -----+------+------+----- e7e6 | e5e4 | e3e2 | e1e0 f7f6 | f5f4 | f3f2 | f1f0 -----+------+------+----- g7g6 | g5g4 | g3g2 | g1g0 h7h6 | h5h4 | h3h2 | h1h0Perform transpose on each 4x4 square:
a7b7 | a5b5 | a3b3 | a1b1 2x2 Merge a6b6 | a4b4 | a2b2 | a0b0 -----+------+------+----- c7d7 | c5d5 | c3d3 | c1d1 c6d6 | c4d4 | c2d2 | c0d0 -----+------+------+----- e7f7 | e5f5 | e3f3 | e1f1 e6f6 | e4f4 | e2f2 | e0f0 -----+------+------+----- g7h7 | g5h5 | g3h3 | g1h1 g6h6 | g4h4 | g2h2 | g0h0Notice here, that the "7351" bits are separated from the "6420" bits. (they're in different registers). Also, notice sequences like "a7b7", "e3f3", and other such things -- there are some _small_ signs of what's happening here.
Swap block "b" and "c" inside each 4x4 group (= 2x2-size swap):
a7b7 | c7d7 | a3b3 | c3d3 4x4 Merge a6b6 | c6d6 | a2b2 | c2d2 -----+------+------+----- a5b5 | c5d5 | a1b1 | c1d1 a4b4 | c4d4 | a0b0 | c0d0 -----+------+------+----- e7f7 | g7h7 | e3f3 | g3h3 e6f6 | g6h6 | e2f2 | g2h2 -----+------+------+----- e5f5 | g5h5 | e1f1 | g1h1 e4f4 | g4h4 | e0f0 | g0h0Remember, that the previous thing done, was to "transpose each 2x2-size block internally", and this was then phase #2: swapping block "b" and block "c" inside the current, kind of.
Merge back into 4x4-size blocks:
a7b7c7d7 | a3b3c3d3 a6b6c6d6 | a2b2c2d2 a5b5c5d5 | a1b1c1d1 a4b4c4d4 | a0b0c0d0 ---------+--------- e7f7g7h7 | e3f3g3h3 e6f6g6h6 | e2f2g2h2 e5f5g5h5 | e1f1g1h1 e4f4g4h4 | e0f0g0h0Swap block "b" and "c" inside the 8x8-group (ie, 4x4-size blocks):
a7b7c7d7 | e7f7g7h7 8x8 Merge a6b6c6d6 | e6f6g6h6 a5b5c5d5 | e5f5g5h5 a4b4c4d4 | e4f4g4h4 ---------+--------- a3b3c3d3 | e3f3g3h3 a2b2c2d2 | e2f2g2h2 a1b1c1d1 | e1f1g1h1 a0b0c0d0 | e0f0g0h0Merge back, and you have it all done!
-6- How do we do the merge ops?
In this step-by-step-description, the
actual _exchanging_ of bits/blocks happened
first on the smallest levels, and then on
larger and larger levels (1x1, 2x2, 4x4)
but in fact this works just as well if it's
done in the other order.
But in fact this works just as well if it's done in the other order - ie, by defining transpose as "first swap blocks b & c, then transpose each block in itself")
We're coming to the question "How do we implement this?". More specifically, "How do we perform the bit-exchanges?"
That's where the bit-merges come in handy.
Don't worry about register shortage now, assume that you have 1024 of them like on some RISC CPUs :) - and as if you had the data in the lowest byte of d0-d7.
The "bit-merge / merge-op" is just what I'm going to show to you now.
... and you're going to do the 4x4-size "exchange blocks b & c" -- let's call that "performing a 4x4-merge"
.. then, what should be done? I'll copy/past a bit array again: [this one's just an example. no intention of you recognizing it. ;)]
a7b7c7d7 | a3b3c3d3 a6b6c6d6 | a2b2c2d2 a5b5c5d5 | a1b1c1d1 a4b4c4d4 | a0b0c0d0 ---------+--------- e7f7g7h7 | e3f3g3h3 e6f6g6h6 | e2f2g2h2 e5f5g5h5 | e1f1g1h1 e4f4g4h4 | e0f0g0h0.. then, you want to exchange the "a3b3c3d3" part in register d0 with the "e7f7g7h7" part in register d4.
and, that exchange could be done like this:
move.b d0, d8 ; make a copy of that row move.b d0, d8 ; make a copy of that row move.b d4, d9 ; copy that row too and.b #$f0, d0 ; those bits should remain in d0 and.b #$0f, d4 ; those bits should remain in d4 and.b #$0f, d8 ; those are the ones which should move and.b #$f0, d9 ; ditto lsl.b #4, d8 ; you figure this one out on your own. :) lsr.b #4, d9 ; ditto lsl.b #4, d8 ; you figure this one out on your own. :) lsr.b #4, d9 ; ditto or.b d8, d4 ; put in the bits or.b d9, d0-7- More Merge ops
now, how about the 2x2? it could be done on the nibble level... but! Remember that you want to do another 2x2 operation between the same registers:
a7b7 | a5b5 | a3b3 | a1b1 a6b6 | a4b4 | a2b2 | a0b0 -----+------+------+----- c7d7 | c5d5 | c3d3 | c1d1 c6d6 | c4d4 | c2d2 | c0d0Look at registers d0 and d2 there,
a7b7 | a5b5 | a3b3 | a1b1 and c7d7 | c5d5 | c3d3 | c1d1there you want to do a5b5<->c7d7, AND a1b1<->c3d3
Also notice that they're going to shift equally far (ie, both a1b1 and a5b5 are going 2 bits left) so one can perform both those in just one merge:
move.b d0, d8 ; copy move.b d2, d9 and.b #$cc, d0 ; save the static bits and.b #$33, d2 and.b #$33, d8 ; save the dynamic and.b #$cc, d9 lsl.b #2, d8 lsr.b #2, d9 or.b d8, d2 ; add on the bits or.b d9, d0If this all seems too weird to you, draw bitcharts in the comments.... like, after "and.b #$cc,d9" -- ; d9 = c7d7....c3d3....
Remember that you can do the 1x1, 2x2 and 4x4 in any order you like. :)
-8- Preparing C2P for 32bit register usage
Now you know how to make a byte-writing c2p.
The next step is to try to make it process
(and write) longwords instead.
But before doing so, we will need to
once again look at some 8x8-bit charts
to determine some interesting facts.
a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0(Next will discuss why merges must be done in certain order and how the order can be determined -neure)
There's an original chart again.
When doing 1x1, 2x2, 4x4, one will perform operation between lines
"a7...." and "b7....", "a7...." and "c7....", "a7...." and "e7...."What I'm trying to show here, is that under _normal_ circumstances, you only need to look at the bit #7 of the bytes a, b, c, e, i, q (= 2^0, 2^1, 2^2, .... = line 0, 1, 2, 4, ...)
you're never making any merge between a and a .... so you could skip a in the list.
... when you're trying to establish what merges to perform.
in this case we only have abce to worry about. and think like this:
"What bits are in the same column as a7?"
"Hmm, b, c and e. therefore we can
do 1xn, 2xn, or 4xn now."
( The number of lines that it is down (relative to a) is what determines the vertical step. )
Why does this reasoning work?
Well, the ONLY way to get in "e7" 4 bits after "a7" in the same register, is by performing a 4xn merge at the correct moment and -- the correct moment is ONLY when e7 is in the same column as a7.
Having this in mind, we can now proceed to try our hands at 32x8 bit arrays instead. (= 8 longs, = it will do longword-writes to chipmem)
Btw; if we don't remember this, we can more or less blindly try, and try to find other things that coincide, but that takes much more looking and "pattern-matching" than this.
[In case yo wonder "where the hell did you find out about the last rule?", I answer: after having worked and thought about them for 2 years, I have finally found that pretty simple scheme. :)]
-9- 5 pass C2P with registers
a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 i7i6i5i4i3i2i1i0 j7j6j5j4j3j2j1j0 k7k6k5k4k3k2k1k0 l7l6l5l4l3l2l1l0 m7m6m5m4m3m2m1m0 n7n6n5n4n3n2n1n0 o7o6o5o4o3o2o1o0 p7p6p5p4p3p2p1p0 q7q6q5q4q3q2q1q0 r7r6r5r4r3r2r1r0 s7s6s5s4s3s2s1s0 t7t6t5t4t3t2t1t0 u7u6u5u4u3u2u1u0 v7v6v5v4v3v2v1v0 w7w6w5w4w3w2w1w0 x7x6x5x4x3x2x1x0 y7y6y5y4y3y2y1y0 z7z6z5z4z3z2z1z0 A7A6A5A4A3A2A1A0 B7B6B5B4B3B2B1B0 C7C6C5C4C3C2C1C0 D7D6D5D4D3D2D1D0 E7E6E5E4E3E2E1E0 F7F6F5F4F3F2F1F0Since each register is 32 bits, and the values are in "non-scrambled order", we will at least need to do 1/2/4/8/16bit merges.
If we do a bad job we will also need to do some merges twice. well, let's reason - look at the a7 column:
a7 e7 i7 m7 q7 u7 y7 C7See that e and i and q are in the same column therefore, 4/8/16bit are possible.
Let's begin with the 8bit: 8x2
a7a6a5a4a3a2a1a0 i7i6i5i4i3i2i1i0 c7c6c5c4c3c2c1c0 k7k6k5k4k3k2k1k0 e7e6e5e4e3e2e1e0 m7m6m5m4m3m2m1m0 g7g6g5g4g3g2g1g0 o7o6o5o4o3o2o1o0 b7b6b5b4b3b2b1b0 j7j6j5j4j3j2j1j0 d7d6d5d4d3d2d1d0 l7l6l5l4l3l2l1l0 f7f6f5f4f3f2f1f0 n7n6n5n4n3n2n1n0 h7h6h5h4h3h2h1h0 p7p6p5p4p3p2p1p0 q7q6q5q4q3q2q1q0 y7y6y5y4y3y2y1y0 s7s6s5s4s3s2s1s0 A7A6A5A4A3A2A1A0 u7u6u5u4u3u2u1u0 C7C6C5C4C3C2C1C0 w7w6w5w4w3w2w1w0 E7E6E5E4E3E2E1E0 r7r6r5r4r3r2r1r0 z7z6z5z4z3z2z1z0 t7t6t5t4t3t2t1t0 B7B6B5B4B3B2B1B0 v7v6v5v4v3v2v1v0 D7D6D5D4D3D2D1D0 x7x6x5x4x3x2x1x0 F7F6F5F4F3F2F1F0Now look at the a7 row again.
And -- e and q remained, that's no wonder -- but: b came in! Thus we can now do 1/4/16bit
Let's do 4bit: 4x1:
a7a6a5a4e7e6e5e4 i7i6i5i4m7m6m5m4 c7c6c5c4g7g6g5g4 k7k6k5k4o7o6o5o4 a3a2a1a0e3e2e1e0 i3i2i1i0m3m2m1m0 c3c2c1c0g3g2g1g0 k3k2k1k0o3o2o1o0 b7b6b5b4f7f6f5f4 j7j6j5j4n7n6n5n4 d7d6d5d4h7h6h5h4 l7l6l5l4p7p6p5p4 b3b2b1b0f3f2f1f0 j3j2j1j0n3n2n1n0 d3d2d1d0h3h2h1h0 l3l2l1l0p3p2p1p0 q7q6q5q4u7u6u5u4 y7y6y5y4C7C6C5C4 s7s6s5s4w7w6w5w4 A7A6A5A4E7E6E5E4 q3q2q1q0u3u2u1u0 y3y2y1y0C3C2C1C0 s3s2s1s0w3w2w1w0 A3A2A1A0E3E2E1E0 r7r6r5r4v7v6v5v4 z7z6z5z4D7D6D5D4 t7t6t5t4x7x6x5x4 B7B6B5B4F7F6F5F4 r3r2r1r0v3v2v1v0 z3z2z1z0D3D2D1D0 t3t2t1t0x3x2x1x0 B3B2B1B0F3F2F1F0Scanning the edge again: b, q = 1bit, 16bit.
Let's do 16x4:
a7a6a5a4e7e6e5e4 i7i6i5i4m7m6m5m4 q7q6q5q4u7u6u5u4 y7y6y5y4C7C6C5C4 a3a2a1a0e3e2e1e0 i3i2i1i0m3m2m1m0 q3q2q1q0u3u2u1u0 y3y2y1y0C3C2C1C0 b7b6b5b4f7f6f5f4 j7j6j5j4n7n6n5n4 r7r6r5r4v7v6v5v4 z7z6z5z4D7D6D5D4 b3b2b1b0f3f2f1f0 j3j2j1j0n3n2n1n0 r3r2r1r0v3v2v1v0 z3z2z1z0D3D2D1D0 c7c6c5c4g7g6g5g4 k7k6k5k4o7o6o5o4 s7s6s5s4w7w6w5w4 A7A6A5A4E7E6E5E4 c3c2c1c0g3g2g1g0 k3k2k1k0o3o2o1o0 s3s2s1s0w3w2w1w0 A3A2A1A0E3E2E1E0 d7d6d5d4h7h6h5h4 l7l6l5l4p7p6p5p4 t7t6t5t4x7x6x5x4 B7B6B5B4F7F6F5F4 d3d2d1d0h3h2h1h0 l3l2l1l0p3p2p1p0 t3t2t1t0x3x2x1x0 B3B2B1B0F3F2F1F0Scan edge -- oh, now c got in there 1/2bit, let's do 2x4:
a7a6c7c6e7e6g7g6 i7i6k7k6m7m6o7o6 q7q6s7s6u7u6w7w6 y7y6A7A6C7C6E7E6 a3a2c3c2e3e2g3g2 i3i2k3k2m3m2o3o2 q3q2s3s2u3u2w3w2 y3y2A3A2C3C2E3E2 b7b6d7d6f7f6h7h6 j7j6l7l6n7n6p7p6 r7r6t7t6v7v6x7x6 z7z6B7B6D7D6F7F6 b3b2d3d2f3f2h3h2 j3j2l3l2n3n2p3p2 r3r2t3t2v3v2x3x2 z3z2B3B2D3D2F3F2 a5a4c5c4e5e4g5g4 i5i4k5k4m5m4o5o4 q5q4s5s4u5u4w5w4 y5y4A5A4C5C4E5E4 a1a0c1c0e1e0g1g0 i1i0k1k0m1m0o1o0 q1q0s1s0u1u0w1w0 y1y0A1A0C1C0E1E0 b5b4d5d4f5f4h5h4 j5j4l5l4n5n4p5p4 r5r4t5t4v5v4x5x4 z5z4B5B4D5D4F5F4 b1b0d1d0f1f0h1h0 j1j0l1l0n1n0p1p0 r1r0t1t0v1v0x1x0 z1z0B1B0D1D0F1F0... And finally, only an 1x2 to perform. Here goes...
a7b7c7d7e7f7g7h7 i7j7k7l7m7n7o7p7 q7r7s7t7u7v7w7x7 y7z7A7B7C7D7E7F7 a3b3c3d3e3f3g3h3 i3j3k3l3m3n3o3p3 q3r3s3t3u3v3w3x3 y3z3A3B3C3D3E3F3 a6b6c6d6e6f6g6h6 i6j6k6l6m6n6o6p6 q6r6s6t6u6v6w6x6 y6z6A6B6C6D6E6F6 a2b2c2d2e2f2g2h2 i2j2k2l2m2n2o2p2 q2r2s2t2u2v2w2x2 y2z2A2B2C2D2E2F2 a5b5c5d5e5f5g5h5 i5j5k5l5m5n5o5p5 q5r5s5t5u5v5w5x5 y5z5A5B5C5D5E5F5 a1b1c1d1e1f1g1h1 i1j1k1l1m1n1o1p1 q1r1s1t1u1v1w1x1 y1z1A1B1C1D1E1F1 a4b4c4d4e4f4g4h4 i4j4k4l4m4n4o4p4 q4r4s4t4u4v4w4x4 y4z4A4B4C4D4E4F4 a0b0c0d0e0f0g0h0 i0j0k0l0m0n0o0p0 q0r0s0t0u0v0w0x0 y0z0A0B0C0D0E0F0'lo and behold! finito!
-10- Transpositions summary
(i) 8 x 2 (ii) 4 x 1 (iii) 16 x 4 (iv) 2 x 4 (v) 1 x 2
-12- Further optimization
We start utilising eor ^ logical operation.
Eor works like this:
A ^ 0 = A A ^ A = 0 A ^ B ^ C = (A ^ B) ^ C = A ^ (B ^C)So one can change the order of EORs sometimes. For instance, if you currently do:
eor.l d0,d1 eor.l d2,d1Then you could change it into
eor.l d0,d2 eor.l d2,d1The value in d1 will be the same. (d2 wil be trashed, though.)
In the above example, one could say that d2 contains two eor's - the "eor.l d2,d1" does what the first version's "eor.l d0,d1; eor.l d2,d1" did. This can be very useful later on...
Here's a normal merge once again:
move.l d0,d6 move.l d1,d7 and.l #$f0f0f0f0,d0 and.l #$f0f0f0f0,d7 and.l #$0f0f0f0f,d6 and.l #$0f0f0f0f,d1 lsl.l #4,d6 lsr.l #4,d7 or.l d6,d1 or.l d7,d0... just the AND.L's thrown around a little so that they have the $f0f0... ands first, and then the $0f0f's. Also notice that we're only using 8 dataregs now. :)
move.l d0,d7 ; d7 = aaaaaaaa bbbbbbbb cccccccc dddddddd and.l #$f0f0f0f0,d0 ; d0 = aaaa.... bbbb.... cccc.... dddd.... eor.l d0,d7 ; d7 = ....aaaa ....bbbb ....cccc ....ddddNow how about that? :)
Well, so let's have a look at what we can make the merge-op to look like with two eors instead:
move.l d0,d6 ; d6 = aaaaaaaa bbbbbbbb cccccccc dddddddd move.l d1,d7 ; d1 = eeeeeeee ffffffff gggggggg hhhhhhhh and.l #$f0f0f0f0,d0 ; d0 = aaaa.... bbbb.... cccc.... dddd.... and.l #$f0f0f0f0,d7 ; d7 = eeee.... ffff.... gggg.... hhhh.... eor.l d0,d6 ; d6 = ....aaaa ....bbbb ....cccc ....dddd eor.l d7,d1 ; d1 = ....eeee ....ffff ....gggg ....hhhh lsl.l #4,d6 ; d6 = ......aa ......ff ......g lsr.l #4,d7 eor.l d6,d1 ; was or eor.l d7,d0 ; was orBecomes:
move.l #$f0f0f0f0,d4 move.l d0,d6 ; d6 = a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 move.l d1,d7 ; d7 = e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 and.l d4,d0 ; d0 = a7a6a5a4........ b7b6b5b4........ c7c6c5c4........ d7d6d5d4........ and.l d4,d7 ; d7 = e7e6e5e4........ f7f6f5f4........ g7g6g5g4........ h7h6h5h4........ eor.l d0,d6 ; d6 = ........a3a2a1a0 ........b3b2b1b0 ........c3c2c1c0 ........d3d2d1d0 eor.l d7,d1 ; d1 = ........e3e2e1e0 ........f3f2f1f0 ........g3g2g1g0 ........h3h2h1h0 lsl.l #4,d6 ; d6 = a3a2a1a0........ b3b2b1b0........ c3c2c1c0........ d3d2d1d0........ lsr.l #4,d7 ; d7 = ........e7e6e5e4 ........f7f6f5f4 ........g7g6g5g4 ........h7h6h5h4 eor.l d6,d1 ; d1 = a3a2a1a0e3e2e1e0 b3b2b1b0f3f2f1f0 c3c2c1c0g3g2g1g0 d3d2d1d0h3h2h1h0 eor.l d7,d0 ; d0 = a7a6a5a4e7e6e5e4 b7b6b5b4f7f6f5f4 c7c6c5c4g7g6g5g4 d7d6d5d4h7h6h5h4There you are.
let's have a look at the AND/EORing in the merge. what will happen to d0?
The bits
........a3a2a1a0 ........b3b2b1b0 ........c3c2c1c0 ........d3d2d1d0become removed, and
........e7e6e5e4 ........f7f6f5f4 ........g7g6g5g4 ........h7h6h5h4become added on. That is like:
move.l #$0f0f0f0f,d4 move.l d0,d6 ; d6 = a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 move.l d1,d7 ; d7 = e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 lsr.l #4,d7 ; d7 = ........e7e6e5e4 e3e2e1e0f7f6f5f4 f3f2f1f0g7g6g5g4 g3g2g1g0h7h6h5h4 and.l d4,d6 ; d6 = ........a3a2a1a0 ........b3b2b1b0 ........c3c2c1c0 ........d3d2d1d0 and.l d4,d7 ; d7 = ........e7e6e5e4 ........f7f6f5f4 ........g7g6g5g4 ........h7h6h5h4 eor.l d7,d6 ; d6 = d6 ^ d7 eor.l d6,d1 ; d1 = a7a6a5a4e7e6e5e4 b7b6b5b4f7f6f5f4 c7c6c5c4g7g6g5g4 d7d6d5d4h7h6h5h4Either you could do
eor.l d7,d0 eor.l d6,d0... or you could do
eor.l d7,d6 eor.l d6,d0
instead of ANDing against both d6 & d7, and then EORing d7 onto d6, let's EOR d7 onto d6, and then AND against d6 only:
move.l #$0f0f0f0f,d4 move.l d0,d6 ; d6 = a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c2c1c0 d7d6d5d4d3d2d1d0 move.l d1,d7 ; d7 = e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 lsr.l #4,d7 ; d7 = ........e7e6e5e4 e3e2e1e0f7f6f5f4 f3f2f1f0g7g6g5g4 g3g2g1g0h7h6h5h4 eor.l d7,d6 ; d6 = d6 ^ d7 and.l d4,d6 ; (d6 ^ d7) & $0f0f0f0f eor.l d6,d0 ; d0 = a7a6a5a4e7e6e5e4 b7b6b5b4f7f6f5f4 c7c6c5c4g7g6g5g4 d7d6d5d4h7h6h5h4what (bits) did we eor against d0? namely,
........a3a2a1a0 ........b3b2b1b0 ........c3c2c1c0 ........d3d2d1d0 and ........e7e6e5e4 ........f7f6f5f4 ........g7g6g5g4 ........h7h6h5h4now I look at the "old" merge, and check what should get EORed against d1
e7e6e5e4........ f7f6f5f4........ g7g6g5g4........ h7h6h5h4........ and a3a2a1a0........ b3b2b1b0........ c3c2c1c0........ d3d2d1d0........(the 1st line should be removed, and the 2nd added to d1)
These are the same, just shifted a little.. "Remove the 7654 bits, insert the 3210 ones << 4"
So let's give the last piece of code we touched a look In d6 the (d6 ^ d7) & $0f0f0f0f mask resides; All that it takes to mangle d1 is:
lsl.l #4,d6 eor.l d6,d1and then we're done:
move.l d1,d7 ; d7 = e7e6e5e4e3e2e1e0 f7f6f5f4f3f2f1f0 g7g6g5g4g3g2g1g0 h7h6h5h4h3h2h1h0 lsr.l #4,d7 ; d7 = ........e7e6e5e4 e3e2e1e0f7f6f5f4 f3f2f1f0g7g6g5g4 g3g2g1g0h7h6h5h4 eor.l d0,d7 ; d7 = mask0 ^ mask1 still dirty and.l #$0f0f0f0f,d7 ; d7 = mask eor.l d7,d0 ; d0 = a7a6a5a4e7e6e5e4 b7b6b5b4f7f6f5f4 c7c6c5c4g7g6g5g4 d7d6d5d4h7h6h5h4 lsl.l #4,d7 ; d7 = mask << 4 eor.l d7,d1 ; d1="a3a2a1a0e3e2e1e0" b3b2b1b0f3f2f1f0 c3c2c1c0g3g2g1g0 d3d2d1d0h3h2h1h0Just the same thing as before, just a little different order when sweeping together the stuff.
-14- Optimizing towards 6 instruction merge op
Instead of doing the bit-shuffling on
the diagonal, one of the regs are ROR/ROLed
and then the job is done vertically.
ror.l #4,d1 move.l d0,d7 eor.l d1,d7 and.l #$0f0f0f0f,d7 ; there we have a simple "vertical" mask eor.l d7,d0 eor.l d7,d1 rol.l #4,d1You can drop the last rol away. Then you need a new set of transpositions, and add a few extra rotations to the code, to unrotate registers back for writing to planes.
So the code will end up 5*4*6 + N, N = 4..7 instructions.
(This does only pay off on 68060, because a ROL/ROR is 1 cycle there. On 68020-68040 your C2P will most likely get slower -Azure)
-15- Blitter
Blitter with A&D channels active on a500 copied 74k/frame.
Blitter with ABD channels on 1200 works about 40k/frame.
First it reads data from channels A-B-C You can turn off any of them so they contain bitmasks instead when it's read one word from each.
It can shift A and/or B by N pixels (specifiable) After that it will combine the three values into one using the "miniterms"
I won't talk about miniterms now, but I'll tell you that one can program the blitter to do this
(A & ~C) | ((B >> 4) & C)... and imagine that C = $0f0f
I changed another error there too, yes. The first part will keep the _high_ nibbles from source A, and insert the _high_ nibbles from source B into the _low_ nibbles of the destination which is 50% of the "old" merge-op.
First that blit, and then another blit. Going in the opposite direction cause the blitter can't LSL/LSR freely (it can only shift in one direction by "delaying")
((A << 4) & ~C) | (B & C)What'll give you the other datas.
There's one more thing to see here though The blitter only deals with words Therefore you can jump around with the modulos And by doing so, yu can get the 16bit merge "for free". So, lets have merge order 8x2 4x1 1x2 16x4 2x4 After the 1x2, let the CPU write the data to chipmem And then the blitter does the 16x4 while performing the 2x4 There's cpu3blit1.
But remember, this is only useful on 020/030; on 040+ cpu5 is the only for 1x1. :)
Thats it...