clr.b -(SP) followed by bsr...

[Photon]

Fixing up someone's old code that gurus on 68040 (all caches off) but not on 68000.

I have this "interesting" code segment:

 (BSR's to here)
 clr.b -(SP)
 bsr.s LoadHunkWr
 move.b (SP)+,d0
 RTS

It IS called, so I'm suspecting the differing behavior between the CPUs for this seemingly brainless piece of code to be the cause of the gurus.

1) What is the expected behavior on 68000?

2) What is the expected behavior on 68040?

Nothing in the manual. I have some guesses, but I'm not sure how to make a 100% compatible replacement. Just pre- or post-incrementing doesn't fix it on 68040.

[Galahad/FLT]

I would have expected the exact opposite, i.e. I would have expected that piece of code to fail on 68000 as it sets the stack pointer to an uneven address before it calls the BSR, so any subsequent move.l/movem.l to the stack would cause it to crash, and the processor moving the return address would also be moved into a negative address.

Very odd code indeed!

[StingRay]

Originally Posted by Galahad/FLT

I would have expected the exact opposite, i.e. I would have expected that piece of code to fail on 68000 as it sets the stack pointer to an uneven address before it calls the BSR

It doesn't since byte moves to the stack are a special case and words instead of bytes are transferred. Also, I don't see why this code should cause crashes on 680x0.

[Galahad/FLT]

Originally Posted by StingRay

It doesn't since byte moves to the stack are a special case and words instead of bytes are transferred. Also, I don't see why this code should cause crashes on 680x0.

Well I never.....

I just automatically never did anything with bytes on the stack thinking it was an incredibly stupid thing to do.

[StingRay]

It's not as stupid as it might look, you can use this "feature" to shift a word by 8 bits:

move.w #$1234,d0
move.b d0,-(a7)
bsr whatever
move.w (a7)+,d0 ; d0.w: $34xx

[Photon]

Originally Posted by StingRay

It doesn't since byte moves to the stack are a special case and words instead of bytes are transferred. Also, I don't see why this code should cause crashes on 680x0.

Yes, that's what I remembered and that's what seems to be happening - on both CPUs.

Discovered also that it loads 1/2/4 bytes of file data into this stack address. I feel like I'm on another planet. Like on Foie Gras Gamma where they have 3 limbs, that's where they load data from files to the stack using dos.library. They also chew rock like bubblegum.

Oh well, I'll dig some more

[Leffmann]

This is described in the PRM under addressing modes. All instructions will do byte operations like expected, but -(A7) and (A7)+ will decrease and increase by 2, and it only applies to those two addressing modes.

[TheDarkCoder]

Originally Posted by StingRay

It doesn't since byte moves to the stack are a special case and words instead of bytes are transferred. Also, I don't see why this code should cause crashes on 680x0.

is a word transfert what exactly happens, or (just in the example you have done in another post) what happens is that SP is inc/decremented by 2 but just a single byte in memory is modified?

I.e. after:
move #$1234,-2(sp)
clr.b -(sp)
move (sp),d0

which is the value of (the low word of) d0?
a) $0000
b) $0034
c) $1200
d) none of the above, TDC has completely lost ASM knowledge
e) undefined behavior (nope, too much ISO C reading)

I would say that b is the right one...

[Photon]

b, yes.

But if this is not the cause for the guru (=different behavior on different CPUs) I can't find anything else. I've narrowed it down pretty well, all the subroutine does is load 1/2/4 bytes to wherever SP is with dos.library.

Edit: did some testing. Can't make it guru on 68030 or 68060, even with all caches on. So maybe a combination of old kickstart and 68040. OK, so now I know I have the hardest Amiga to code for in the world And people wonder why coders are slashing their wrists in the restroom (c). Will report back if it gurus on another beast. Would be nice to know if it's the 68040 specifically, or dos.library of kick 2.0+68040 combo that makes it regurgitate...

[Leffmann]

Originally Posted by Photon

But if this is not the cause for the guru (=different behavior on different CPUs) I can't find anything else. I've narrowed it down pretty well, all the subroutine does is load 1/2/4 bytes to wherever SP is with dos.library.

Does it load data to there directly after the BSR without offseting the stack pointer one more time? If so then that's the problem, it will overwrite the subroutine return address. Check that the stack pointer is used correctly too, because of the flaw in exec's task scheduler.

[StingRay]

Originally Posted by Leffmann

Does it load data to there directly after the BSR without offseting the stack pointer one more time? If so then that's the problem, it will overwrite the subroutine return address.

Can't be the problem as it would crash on each and every CPU.

[Leffmann]

Hmm are you sure, because on the 68000, 010, and possibly the EC020 under certain conditions, the most significant byte of any address referred should be ignored due to their 24 bit address bus, and if this subroutine only loads 1 byte of data like Photon said it could, then it should be fine right?

It was just a suggestion to help pinpoint a difficult to find problem.

[StingRay]

Originally Posted by Leffmann

Hmm are you sure, because on the 68000, 010, and possibly the EC020 under certain conditions, the most significant byte of any address referred should be ignored due to their 24 bit address bus, and if this subroutine only loads 1 byte of data like Photon said it could, then it should be fine right?

Well, he wrote that it works on 030/060 so any 24 bit problem is ruled out.

Originally Posted by Leffmann

It was just a suggestion to help pinpoint a difficult to find problem.

I know and my comment wasn't meant bad in any way.

[Wepl]

you should check if changing the code to

clr.l -(SP)
bsr.s LoadHunkWr
move.l (SP)+,d0

fixes the issue on 68040

(assumed in supervisor mode) stackpointer accesses are special in regard to caches and store/load buffers (similar to vector fetches and table searches)

besides that it would be interesting if the code in LoadHunkWr does anything regarding the stack space

[Photon]

On return (from LoadHunk called by LoadHunkWr(apper)), the SP is where it was before the call, if that's what you mean. There's no recursing. But of course it later accesses 8(SP) to get the 'value'.

There are a number of places where sub-routines accesses registers pushed a bit up the stack.

I will try your code right now and report.

Didn't think it would work, I did test a positive before trying the negative. Tried both with and without cache.

The result was the loading failing and retrying forever, whereas the original code loads and plays until it gurus, which is about every 3rd or 4th song. That's at least interesting! Well, maybe not. I guess any 'didn't work' result could simply cause the loading to fail, many code-changes could cause that, I mean.

There's no difference between kick 1.3 and 2.0, both fail on 68040 and work on 68000.

68000 and 68030 works, 68040 not. Since it's tested with caches of, it has nothing to do with the copied-to-stack code and other nice features of the source Unfortunately my A1200-060 is disassembled so I can't check if it has something to do with 'CPU is too fast'. And the ACA630 is way faster at loading from disk anyway so that's not likely. (But only if the error is related to loading-speed, of course.)

It works in WinUAE, but next step is to check on a real A1200-060. I will finish the soldering and test. If it works there, I won't bother.

[Wepl]

And LoadHunkWr writes his return value at the correct address in the stackframe (e.g. (4,a7).b)?

I tend to think there is somewhere else a problem but not with this code, it should execute the same way on all cpus.

[Photon]

Yeah, it was established at the start of the thread that 68040 executes clr.b -(SP) the same on all CPUs. Yet I established that the difference is not with caches or other things normally found in newer CPUs, and that it's not related to Kickstart version. So it should be a 68040-specific property/behavior that causes the error. The code in the program (or possibly some non-68040-compatible libcall in the OS) MUST execute differently specifically on 68040.

Anyone made a nice list of tricky-dicky CPU-differences (instructions executed differently, ie. giving different 'result') in the Motorola family somewhere, perhaps?

If I have time I will _try_ to rig up the source somehow so it can be debugged on 68040. Debugger in AsmOne 1.20 should probably work fine, but this source is 'special' so I have to rig up something to make the OS give it what it wants so it even reaches the load routine.

Right now it's not a priority, since I didn't write the code. If it were my code I wouldn't have problems debugging it nor stop until the bug was squashed. Likely also, there wouldn't be a 68040-specific bug since I have an 040

[Wepl]

to me the are no such bugs known with m68k processors, the errata lists I have are here http://whdload.de/whdload/docs/ don't know if these or newer ones are still available at the motorola websites

[Photon]

Well, either the code somehow 'changes' when run on 68040, or the code is the same. If the code is the same, it is executed differently on 68040. Since it's the same binary, the code is the same there. Since it works with the same Kickstart in the same machine, no code differs there. What's left is the 'environment'. If the binary is tested in the same environment (not startup-sequence), no code except ROM code and the binary is executed. If the 68040 as you say executes code different from others of this same code, only hardware differences coud cause it.

I doubt adding 4MB more accelerator RAM would instantly wreck the behavor, but it's possible but very unlikely there's a ram error (it has run software well since 2007). Besides, all the code is in chipmem - although code is copied to the stack and executed there, and the stack will be in fastmem. I doubt a memory error would give an error isolated to the same section of code every time, so I will rule that out for now.

The only other CPU difference I can think of is speed, but the ACA630 is much faster than 68040 A500 with caches off.

I'll try to narrow it down further, hoping the debugger will play nice.

[Photon]

The debugger worked on 68040 with caches off, sort of (very strange behavior compared to 68000 and 68030). Suffice to say I don't have the oomph in me to overcome the behavior and narrow it down, since the guru levitates randomly. I can't waste the time needed on this, perhaps a fix after release. I usually do not like such cop-outs, but I will make an exception in this case - it's not my code. Shoot me.

Could be an interesting find, perhaps - will release the source with the demo so you can try some masochism if interested.