English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. General (http://eab.abime.net/forumdisplay.php?f=37)
-   -   68040 MMU jsr/bsr (http://eab.abime.net/showthread.php?t=52391)

Toni Wilen 24 April 2010 15:32

68040 MMU jsr/bsr
 
(I guess this is too difficult question as usual..)

68040's bus error handling is partial restart (stop reading if you don't know what it means :D) and bus errors caused by writes usually happen after instruction has completed and before next (possibly later) instruction starts. Reads always restart current instruction (after exception ends)

Question: what does JSR and BSR do if stack write causes bus error exception? Is it considered normal delayed write? (no restart)

1) SP gets adjusted (SP=SP-4) and PC changed before exception starts, exception returns to new PC. (=no restart)
2) SP and PC not touched. Restart instruction after exception returns.
3) something else?

(remember that 68060 is full restart, not same as 68040)

matthey 25 April 2010 18:41

The best person to answer that question would be Thomas Richter. He has not turned to the dark side yet. His e-mail is the same as in all his mu programs on Aminet or you could post your question on http://www.natami.net which he frequents. I take it that the information was not in the 68040 User Manual? You could always find out by testing.

Wepl 28 April 2010 00:01

I assume:
in supervisor it will lock the machine by a double bus fault
in user mode it will create standard format $7 frame with wb2 set and pc will point to the destination address of bsr/jsr

if you are interested on the stack frame generated I could test it here

Toni Wilen 28 April 2010 11:56

Quote:

Originally Posted by matthey (Post 663955)
The best person to answer that question would be Thomas Richter. He has not turned to the dark side yet. His e-mail is the same as in all his mu programs on Aminet or you could post your question on http://www.natami.net which he frequents. I take it that the information was not in the 68040 User Manual? You could always find out by testing.

I don't post in other Amiga related forums, sorry. Thomas probably knows, thanks :)

User manual is quite useless in this situation. I don't have a 68040.

Quote:

Originally Posted by Wepl (Post 664578)
I assume:
in supervisor it will lock the machine by a double bus fault

Double bus fault even if current exception is non-bus exception? (too lazy to check manuals just now..)

Quote:

in user mode it will create standard format $7 frame with wb2 set and pc will point to the destination address of bsr/jsr

if you are interested on the stack frame generated I could test it here
That is what Aranym does but because most programs won't care (even netbsd and linux) I only trust real CPUs.

Please check it if you really feel bored enough :)

Wepl 28 April 2010 21:13

1 Attachment(s)
Quote:

Originally Posted by Toni Wilen (Post 664658)
Double bus fault even if current exception is non-bus exception? (too lazy to check manuals just now..)

if the supervisor stack cannot be written, writing the stackframe will fail too (except using the msp maybe)
Quote:

Originally Posted by Toni Wilen (Post 664658)
That is what Aranym does but because most programs won't care (even netbsd and linux) I only trust real CPUs.

Please check it if you really feel bored enough :)

Code:

ShadowMem  735BE50 -  739BE50 ( 262144) AbsolutMem    40000 -    40000 (      0)
Resload    7FB8000 -  7FC2160 (  41312) at 7FB8000  GL=$7FD5000
Slave      7FDE000 -  7FDE0B0 (    176) at 7FDE000  BaseMemSize=$40000
ExpMem    7FC4000 -  7FD4000 (  65536) at 7FC4000
attn=7F(40,82) fc=65535 kn=1000 cs=B847 rw=0 zpt=-1 ep=0 ei=0
setcpu=33D(DC,IC,SCB,ECB,BNC)

Exception "Access Fault" ($7008) PC = $7FDE08C (Slave $8C) Long Write to $40FFC

$07fde082 move        #0,sr
$07fde086 bsr.b        $7fde08c
$07fde088 illegal
$07fde08a nop
$07fde08c illegal
$07fde08e illegal

exception stackframe:
$07FD3DC4 000007FD E08C7008 07FB894C 04810001 00810005 00040FFC 00040FFC 07FDE088
$07FD3DE4 00040FFC 07FDE088 DDDDDDDD DDDDDDDD DDDDDDDD DDDDDDDD DDDDDDDD

  ----0---- ----1---- ----2---- ----3---- ----4---- ----5---- ----6---- ----7----
Dx D0D0D0D0  D1D1D1D1  D2D2D2D2  D3D3D3D3  D4D4D4D4  D5D5D5D5  D6D6D6D6  D7D7D7D7
Ax    41000  7FDE090  A2A2A2A2  A3A3A3A3    BFE001  7FB8000    DFF000

                TTSM III  XNZVC
PC= 7FDE08C  SR %0000000000000000  USP=40FFC  ISP=7FD3DC4  MSP=3F800
VBR=7FD6000  SFC=5  DFC=1  CACR=80008000 
TC=8000  URP=07FB6000  SRP=07FB6000  MMUSR=00000000
DTT0=00000000  DTT1=00000000  ITT0=00000000  ITT1=00000000


Toni Wilen 28 April 2010 21:57

Thanks, it was as expected but unfortunately this does not fix remaining problem (in some situations stack is either corrupted or stack pointer address is incorrrect) but at least JSR/BSR behavior is confirmed.


All times are GMT +2. The time now is 14:14.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04193 seconds with 11 queries