68000 code optimisations

[meynaf]

Originally Posted by remz

Curiosity: Why were 6 bits allocated to shift&rotate instructions instead of 5?
Is there any practicality to rotate more than 32?

More than 32 isn't really interesting, but 32 itself can be. And you need 6 bits to represent that value.
It needs verification, but i think it is really 5 for rotates and 6 only for shifts.

[a/b]

They're all 6-bit (it was tested on real hw, a500 68000): they all take tbe same number of cycles.

[Karlos]

Being able to shift 6 bits makes sense if you are thinking of some future 64-bit wide register implementation. Although that probably wasn't the actual reason.

[meynaf]

Only logical reason is ability to shift by 32. With 5-bit, range is only 0-31.

[mschulz]

Originally Posted by meynaf

Only logical reason is ability to shift by 32. With 5-bit, range is only 0-31.

This, and also ROXL/ROXR rotations, where CPU deals with 33-bit number.

[meynaf]

Originally Posted by mschulz

This, and also ROXL/ROXR rotations, where CPU deals with 33-bit number.

Didn't think about it, but indeed, there maxing out at 31 would have missed something.
Actually, it is of course 9, 17 or 33 bits depending on the size.
One could think it is logical to cut at 6-bit for .l, 5-bit for .w, 4-bit for .b, but it's not what the cpu does - it's always 6 regardless of the operand size.
Note that PowerPC uses 6 bits as well, but not x86 (didn't check though, this is what i've read).

[ross]

Originally Posted by meynaf

.., but not x86 (didn't check though, this is what i've read).

From this page: https://c9x.me/x86/html/file_module_x86_id_273.html
it seems that starting from Intel 286 processor, the rotation is masked to 5 bits. and the masking is done in all operating modes, including the virtual-8086 mode (see note at the bottom of the page).
EDIT: of course the same for shift instructions (https://c9x.me/x86/html/file_module_x86_id_285.html)
I've written code for x86 several times, in a distant past, but never bothered about it and probably never considered it. Nice sh*t...

But we are off-topic

[Don_Adan]

Based on this 6502 routine:

;Divide by 24 for 6502 CPU
;15 bytes, 27 cycles
 lsr
 lsr
 lsr
 sta temp
 lsr
 lsr
 adc temp
 ror
 lsr
 adc temp
 ror
 lsr

I wrote 68000 version, maybe useful for something.

; divide by 24, no rest, no overflow
 lsr.l #3,D0
 move.l D0,D1
 lsr.l #2,D0
 addx.l D1,D0
 lsr.l #2,D0
 addx.l D1,D0
 lsr.l #2,D0

Here is divide by 3:

; divide by 3, no rest, no overflow
 move.l D0,D1
 lsr.l #2,D0
 addx.l D1,D0
 lsr.l #2,D0
 addx.l D1,D0
 lsr.l #2,D0

Modified versions can handle divide by 3, 6, 12, 24, 48, 96 etc.
Not tested, but seems to be OK.

[Don_Adan]

Here is divide by 3 with rest:

; divide by 3 with rest, no overflow
 move.l D0,D1
 lsr.l  #2,D0
 addx.l D1,D0
 lsr.l  #2,D0
 addx.l D1,D0
 lsr.l #2,D0 ; score
 sub.l D0,D1
 sub.l D0,D1
 sub.l D0,D1 ; rest