(TECH) 68030 execptions

(TECH) 68030 execptions

Post by Neil Forsy » Sun, 24 Jun 1990 01:05:19



Apparently the 68030 has a different execption stack frame to the 68000
one. Does anyone know how they differ? Programs that intercept the system
TRAPs are going to break on the TT unless they take this into account.

There's a nice simple, no *ing question for you.

+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
!                                                                            !


! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK           "How do you know so much about swallows?"!
+----------------------------------------------------------------------------+

 
 
 

(TECH) 68030 execptions

Post by Ignac Kolen » Sun, 24 Jun 1990 05:12:20



>Apparently the 68030 has a different execption stack frame to the 68000
>one. Does anyone know how they differ? Programs that intercept the system
>TRAPs are going to break on the TT unless they take this into account.

>There's a nice simple, no *ing question for you.

cool!

anyways, TOS 1.4 and higher, i believe, check a new system variable which
indicates to the ROM exception handlers what type of stack frame to
look out for. Thus i think TOS 1.4 will run correctly on the TT. (which
is rumoured to be shipped with TOS 1.4 anyways)

and yes, pretty well all trap handlers are going to break under the TT
because of this fact.

--
========Ignac A. Kolenko (The Ig)=======watmath!watcgl!electro!ignac=========

      "Blowed up REAL good!" - Big Jim McBob (Celebrity Blowup - SCTV)
=============================================================================

 
 
 

(TECH) 68030 execptions

Post by Alex Kiern » Mon, 25 Jun 1990 05:57:52



>Apparently the 68030 has a different execption stack frame to the 68000
>one. Does anyone know how they differ? Programs that intercept the system
>TRAPs are going to break on the TT unless they take this into account.

>There's a nice simple, no *ing question for you.

A copy of the 68030 manual is totally essential, the stack frames are
completely different, and include stack format information which is
just not present. I don't now of any de*s which will work,
although it is generally a simple task to take into account these
things.

Alex.

 
 
 

(TECH) 68030 execptions

Post by Brian Walk » Mon, 25 Jun 1990 07:08:24



>Apparently the 68030 has a different execption stack frame to the 68000
>one. Does anyone know how they differ? Programs that intercept the system
>TRAPs are going to break on the TT unless they take this into account.

>There's a nice simple, no *ing question for you.

The exception stack frame changed with the 68010/68012 processors.  Among
other things, the new format allows virtual memory support which did not
exist on the 68000.  User mode operation is, of course, mostly unaffect.

The differences between the 68000 and its sucessors can be summed up in the
inclusion of the format/vector offset word.

              68000                                 68010++
_________________________________      __________________________________
|________STATUS_REGISTER________|      |________STATUS_REGISTER_________|
|_____PROGRAM_COUNTER_HIGH______|      |_____PROGRAM_COUNTER_HIGH_______|
|_____PROGRAM_COUNTER_LOW_______|      |_____PROGRAM_COUNTER_LOW________|
        variables follow               |FORMAT_|_____VECTOR_OFFSET______|
                                       |_______other information________|
                                       |_____depending on exception_____|
                                                variables follow

The FORMAT field is four bits in length and defines the length of the stack
frame.  Of the possible formats, two are defined for the 68010.
0000    Short format:  Stack frame is four bytes in length.
1000    Long format:   Stack frame is 29 bytes in length

"The number of words actually stacked depends on the exception type.  Group 0
[Address Error, Bus Error but not Reset] stack 29 words and group 1 (Trace,
Interrupt, Illegal Instruction and Privledge violation) and [group] 2
exceptions (TRAP, TRAPV, CHK and divide by zero) stack four words.  In order
to support generic exception handlers, the processor also places the vector
offset in the exception stack frame.  The format code field allows the RTE
(return from exception) instruction to identify what information is on the
stack so that it may be properly restored. ... Although some formats are
peculiar to a particular M68000 Family processor, the format 0000 is always
legal and indicates that just the first four words of the frame are present."
- _M68000 8-/16-/32-Bit Microprocessors Programmer's Reference Manual_
  fifth edition, pg. 4-7

--
Brian Walker                          There come a time in the history

..!ncar!boulder!*!walkerb        necessary to shoot the engineers
University of Colorado, Boulder       and begin production.

 
 
 

(TECH) 68030 execptions

Post by Claus Bro » Tue, 26 Jun 1990 05:25:28



>cool!
>anyways, TOS 1.4 and higher, i believe, check a new system variable which
>indicates to the ROM exception handlers what type of stack frame to
>look out for. Thus i think TOS 1.4 will run correctly on the TT. (which
>is rumoured to be shipped with TOS 1.4 anyways)

TOS 1.4 doesn't check anything. TOS 1.6 does. The TT will come TT 030
which is more like TOS 1.6 than TOS 1.4.

Quote:>and yes, pretty well all trap handlers are going to break under the TT
>because of this fact.

The 68030 places two additional bytes on the stack if I remember this
right. If you want to read out your function parameters on the trap
stack, you'll have to adjust your frame pointer like this:

        movea.l a7,a5
        lea offset(a5),a5       ; adjust a5 for 68000 trap
        tst.w processor         ; flag that tells you whether there's a 68030
        beq.s goon
        addq.l #2,a5
goon:
        ...

Just to show the principle...

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,                  Things. Take. Time.
D-8772 Marktheidenfeld, West Germany            (Piet Hein)

----------------------------------------------------------------------

 
 
 

(TECH) 68030 execptions

Post by Dave Hayn » Thu, 28 Jun 1990 01:11:38



>Apparently the 68030 has a different execption stack frame to the 68000
>one. Does anyone know how they differ? Programs that intercept the system
>TRAPs are going to break on the TT unless they take this into account.

All 68000 traps are format 0.  The 68030 can produce formats 0, 1, 2, 9,
A, and B.  Line A traps are format 0, so system traps using the line A
exception are not a problem.

--
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
        "I have been given the freedom to do as I see fit" -REM

 
 
 

(TECH) 68030 execptions

Post by Hartmut Semk » Thu, 28 Jun 1990 16:04:36



>Apparently the 68030 has a different execption stack frame to the 68000
>one. Does anyone know how they differ? Programs that intercept the system
>TRAPs are going to break on the TT unless they take this into account.

The 030 has more registers than a 000. So it will save more on the stack
when hit by an exception.
It's the same with 010 and 020 MPUs: for example the 010 saves her
workspacepointer (register indicating the starting adress of the
exception vectors) and the state of the decoding pipeline on the stack
when hit by a BUSERR or the like.

So any program that tries to pop something of the stack by ADDing to the
stackpointer, will probably break, cause the 010,020 and 030 put more on
the stack than the program exspected.

hase
--

Hi! (Zaphod Beeblebrox)

 
 
 

1. 68030 execptions


]The differences between the 68000 and its sucessors can be summed up in the
]inclusion of the format/vector offset word.
]              68000                                 68010++
]_________________________________      __________________________________
]|________STATUS_REGISTER________|      |________STATUS_REGISTER_________|
]|_____PROGRAM_COUNTER_HIGH______|      |_____PROGRAM_COUNTER_HIGH_______|
]|_____PROGRAM_COUNTER_LOW_______|      |_____PROGRAM_COUNTER_LOW________|
]       variables follow               |FORMAT_|_____VECTOR_OFFSET______|
]                                       |_______other information________|
]                                       |_____depending on exception_____|
]                                                variables follow

Thanks Brian! That's exactly what I wanted to know. So basically it's just
variable access that is affected seriously. Now I can avoid any TT pitfalls.

]Brian Walker                          There come a time in the history

]..!ncar!boulder!tramp!walkerb        necessary to shoot the engineers
]University of Colorado, Boulder       and begin production.

+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
!                                                                            !


! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK           "spam spaM spAM sPAM SPAM, lovely SPAM"  !
+----------------------------------------------------------------------------+

2. The Perfect Christmas Gift 8126

3. atari st: low-tech music for high-tech people

4. how to include an encapsulated postscript picture ??

5. FS: 68030 accelerator, plus..

6. win2000 applicatipn

7. 68030 pinout...

8. Looking for DB SW (Summ

9. overclock 68030?

10. CPU 68030 32 Bits/75 MHz !

11. 68030/882 50 MHz

12. linux 68 k on st's with 68030 cards

13. PAK 68030 ... WHERE !!!???