MPYHW definitely performs a faithful multiplication, but exactly how it behaves when extending off the left side of the register is something I’m gonna have to investigate further in the morning.
In the mean time, have a ROM! All controls are done with the left D-Pad. Up and down change the value of the current digit, and left and right change the digit.
Attachments:
I put together a program to answer this once and for all. It tests all register-based instructions with a simple assembly loop:
# s32 CycleTest(s32 arg1, s32 arg2, s32 num);
vueFunction(_CycleTest)
# r2 = 0x02000000, base address for hardware control ports
# r6 = arg1
# r7 = arg2
# r8 = num, also used as the loop iterator
# Configure the hardware timer
MOVHI 0x0200, r0, r2
MOV -1, r1
ST.B r1, 0x0018[r2] # Count/reload low = 0xFF
ST.B r1, 0x001C[r2] # Count/reload high = 0xFF
# Enable and clear the instruction cache
MOVEA 0x0803, r0, r1
LDSR r1, CHCW
# Enable the timer with 20-microsecond ticks
MOVEA 0x0011, r0, r1
ST.B r1, 0x0020[r2]
# Execute the instruction 10 times for the given number of iterations
.Lcycle_loop:
MOV r6, r9
MOV r7, r10
# This comment is located 32 bytes into the function.
# When the function is not modified, nothing happens in this loop
# The following bytes are meant to be overwritten in RAM
BR .Lcycle_end; NOP; NOP; NOP; # Written by 16- and 32-bit instructions
BR .Lcycle_end; NOP; NOP; NOP; # Written by 32-bit instructions
BR .Lcycle_end # Always present for consistency
# End-of-loop code for 32-bit instructions (3 16-bit instructions)
.Lcycle_end:
ADD -1, r8
BNZ .Lcycle_loop
# End-of-loop label
# Disable the timer and instruction cache
ST.B r0, 0x0020[r2]
LDSR r0, CHCW
# Retrieve and return the number of timer ticks taken
IN.B 0x0018[r2], r6 # Timer count low
IN.B 0x001C[r2], r7 # Timer count high
SHL 8, r7 # r7 = r7 << 8 | r6;
OR r6, r7
MOV -1, r10 # r10 = -1 - r7 & 0xFFFF;
SUB r7, r10
ANDI 0xFFFF, r10, r10
JMP [r31]
vueEnd(_CycleTest)
This function gets copied into RAM at run-time. Those NOPs are dummy bytes that are replaced with meaningful instructions by the program. The reason there are two sets of NOPs is to accommodate both 16- and 32-bit instructions. The following BR instruction is always present to ensure that the loop takes the same number of cycles always except for the desired instructions.
The C code that drives this looks like this:
// Gets the number of timer ticks for a loop of 4 instances of an instruction
s32 GetCount(const INST *inst, s32 num) {
s32 len = (SIZE_CYCLETEST + 3) / 4;
u32 arg1 = 0, arg2 = 0;
s32 x, y, offset = 32;
u8 func[len];
u16 bits[2];
// Copy the function into memory
memcpy32(func, &CycleTest, len);
// If we're not overwriting with an instruction, ignore this all
if (inst != NULL) {
// Encode the instruction into data bits and get its size
len = FORMATS[inst->format](inst, bits);
// Copy the instruction into the function buffer 4 times
for (x = 0; x < 4; x++) for (y = 0; y < len; y++) {
*(u16 *)(&func[offset]) = bits[y];
offset += 2;
}
// Grab the instruction's pre-defined operands
arg1 = inst->val1;
arg2 = inst->val2;
}
// Call the function from the byte buffer
return ((s32 (*)(u32, u32, s32)) func)(arg1, arg2, num);
}
My main function calls this function 5 times for each instruction (predefined in a const table at the top of the program), and averages the counts. It then subtracts the count from a null call (no instruction overwritten), then divides by the count for ADD, which is known to be 1 cycle.
The output on the hardware looks like this:
ADD (Immediate) 051E = 1 cycle ADD (Register) 051E = 1 cycle ADDF.S 6F5C = 22 cycles ADDI 051F = 1 cycle AND 051E = 1 cycle ANDI 051E = 1 cycle CLI 3D71 = 12 cycles CMP (Immediate) 06ED = 1 cycle CMP (Register) 051E = 1 cycle CMPF.S 228F = 7 cycles CVT.SW 4666 = 14 cycles CVT.WS 27AE = 8 cycles DIV C148 = 38 cycles DIVF.S DFFF = 44 cycles DIVU B70A = 36 cycles LDSR 28F6 = 8 cycles MOV (Immediate) 051F = 1 cycle MOV (Register) 051E = 1 cycle MOVEA 051F = 1 cycle MOVHI 051E = 1 cycle MPYHW 2CCC = 9 cycles MUL 4148 = 13 cycles MULF.S 83D7 = 26 cycles MULU 4147 = 13 cycles NOT 051E = 1 cycle OR 051E = 1 cycle ORI 051F = 1 cycle REV 6F5C = 22 cycles SAR (Immediate) 051E = 1 cycle SAR (Register) 051E = 1 cycle SEI 3D70 = 12 cycles SETF 051E = 1 cycle SHL (Immediate) 051E = 1 cycle SHL (Register) 051E = 1 cycle SHR (Immediate) 051F = 1 cycle SHR (Register) 051E = 1 cycle STSR 28F5 = 8 cycles SUB 051E = 1 cycle SUBF.S 83D7 = 26 cycles TRNC.SW 4147 = 13 cycles XB 1D70 = 6 cycles XH 051F = 1 cycle XOR 051E = 1 cycle XORI 051E = 1 cycle
All instructions with documented cycle counts have the correct count, so that's a relief. The floating-point instructions fall within their given range. The undocumented cycle counts? Well, that's why I made this program.
LDSR and STSR are 8 cycles each. I was expecting 1 cycle. This is how we learn things, though. Suddenly the CLI and SEI instructions being 12 cycles don't sound so bad.
MPYHW is 9 cycles as seen before. Likewise for XB at 6 cycles, XH at 1 cycle and REV at 22 cycles.
A ROM of this program is attached to this post. After the test is finished, up and down on the left D-Pad scroll the list of instructions.
