unlk sp

[alexh]

Just something which I came across today, a 68000 re-implementation which fails Toni's cputest with opcode 0x4e5f (unlk SP)

Is that a valid operation?

I've only ever used this instruction with address registers upto A6 (which are pointing to the stack frame).

CPUlvl=0, Mask=00ffffff Code=007c0000 SP=007ffbc0 ISP=00800000
 Low: 00000000-00008000 High: 00ff8000-01000000
Test: 00780000-00800000 Safe: ffffffff-ffffffff
UNLK.L:
data/68000/UNLK.L/0000.dat. 0...

8:	4e5f    unlk     sp
A7: expected f01f007c but got e993f600
Registers before:
D0: 00000010 D1: 00000000 D2: ffffffff D3: ffffff00
D4: ffff0000 D5: 80008080 D6: 7fff7fff D7: aaaaaaaa
A0: 00000000 A1: 00000080 A2: 00008000 A3: 00007fff
A4: fffffffe A5: ffffff00 A6: 007bff00 A7:*007ffbc0
SR: 0000   PC: 007c0000 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
000   PC: 007c0000 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*0 Z!0 V*0 C=0

Registers after:
SR:*000e   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*1 Z!1 V*1 C=0
OK: No exception generated
Registers after:
SR:*000e   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*1 Z!1 V*1 C=0
OK: No exception generated
Registers after:
A4: fffffffe A5: ffffff00 A6: 007bff00 A7:*e993f600
SR: 0000   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
OK: No exception generated ```

[grond]

Why should it not be valid? What do you do with the old SP you get in An when you need An for other purposes? You push it on the new stack. Unless I misunderstand the UNLK instruction, you can read back the old SP from the stack on leaving the subroutine where you use LINK/UNLK directly into the SP using "UNLK SP" without needing a scratch address register. To be honest, I would have expected this to be rather common (if we want to consider LINK/UNLK common at all).

EDIT: what 68000 reimplementation is that?

[Thomas Richter]

Originally Posted by alexh

Just something which I came across today, a 68000 re-implementation which fails Toni's cputest with opcode 0x4e5f (unlk SP)

Is that a valid operation?

It is a valid instruction, though a bit unusual as it uses A7 both as the (implicit) source and destination. While the 68K family guide is quite clear on what this instruction should perform, I would not be overly surprised if, in reality, it works a little bit different in this specific case, maybe even depending on the member of the family.

[meynaf]

UNLK A7 does not look very useful...
In theory it should just pop A7 out of the stack, something regular MOVE can do.
Also it does not look safe to use accross different cpu models, like MOVE.L (A7)+,A7.

[Toni Wilen]

There is chance this report is bogus. I have seen same error sometimes but also UNLK SP test succeeding. Does it report same error if you only generate UNLK tests?

LINK has undefined behavior between CPU models but UNLK should work identically in all CPU models.

[alexh]

Originally Posted by grond

what 68000 reimplementation is that?

FX68K a SystemVerilog open source synthesisable cycle accurate 68000 reimplementation. Used originally in FXCast a cycle accurate Atari ST reimplementation for FPGA but now in lots of other reimplementations that require cycle accuracy including Megadrive/Genesis and arcade machines

[grond]

Originally Posted by meynaf

Also it does not look safe to use accross different cpu models, like MOVE.L (A7)+,A7.

What value will end up in A7 in your example? The post-incremented old stack pointer, the post-incremented new stack pointer or the non-incremented new stack pointer? And is that really the same as UNLK A7?

[meynaf]

Originally Posted by grond

What value will end up in A7 in your example? The post-incremented old stack pointer, the post-incremented new stack pointer or the non-incremented new stack pointer? And is that really the same as UNLK A7?

Here is precisely the problem : it is ambiguous and one can't answer for sure to these questions without testing every cpu model.

IIRC, on 020-030 it would be non-incremented new stack pointer (like on 68000). However, MOVEM would give post-incremented new stack pointer, where on 68000 there is no difference.
I didn't test how UNLK A7 behaves but i would bet it is like MOVE.

[ross]

a real example:
a7 = $3FFFC
(a7)=($3FFFC)=$50000

unlk a7 microcode:

An -> SP;          a7=$3FFFC -> a7 
[M(SP)] -> tmp;    (a7)=($3FFFC)=$50000 -> tmp
SP+4 -> SP;        a7+4=$3FFFc+4=$40000 -> a7 
tmp -> SP;         tmp=$50000 -> a7

same result as

movea.l (a7)+,a7

or

movea.l (a7),a7

for all 68k family processors

[grond]

Originally Posted by ross

a real example:
a7 = $3FFFC
(a7)=($3FFFC)=$50000

unlk a7 microcode:

SP<-An;          a7<-a7<-$3FFFC
tmp<-[M(SP)];    a7<-(a7)<-($3FFFC)<-$50000
SP<-SP+4;        a7<-$40000
SP<-tmp;         a7<-$50000

same result as

movea.l (a7)+,a7

or

movea.l (a7),a7

for all 68k family processors

Interesting! How did you test that?

[ross]

Originally Posted by grond

Interesting! How did you test that?

WinUAE

The Motorola manuals report this internal sequence and it seems that this is respected throughout the full processors family.

[alexh]

I thought it was an interesting thing because I've never knowingly seen "unlk sp" in any disassembly I've come across (but then I've not seen a lot and I wasn't actively looking).

But potentially given the discussion here, I imagine that higher language compilers (not assemblers) could have produced the same functionality using a different opcode.

I fed back to the reporter and they are going to try to re-run with UNLK tests only.

[ross]

Originally Posted by alexh

But potentially given the discussion here, I imagine that higher language compilers (not assemblers) could have produced the same functionality using a different opcode.

This is not possible because no compiler would generate (voluntarily) that (op)code.
Nor can it be thought of as coupled with a

link a7,#n

because this link doesn't make any sense and also it doesn't behave the same way in the 68k processors family.

If you want a

 movea.l (a7),a7

operation (which is perfectly legitimate) you use

2E57

opcode that is dedicated and faster