[comp.arch] Help with 68020/68881 Stack problem

gsarff@sarek.UUCP (Gary Sarff) (09/23/89)

I have a problem that I came across at work, and this is the only group I get
for which this might be appropriate.  The problem concerns the 68020's stack
in relation to the MC68881 Math Co-Processor, when the 881 is doing a move
multiple of its floating point registers.  Here is the situation,
Using the 68851, our page size is 4K
68020 A7, Stack pointer contains 01EE004, just above bottom of a 4k page.
PC is pointing to instruction  fmovem.x  fp4-fp7,-(sp)

Upon execution of this instruction I get a bus error, and trap to my
routine in the kernel that handles such to see if auto-stack expansion
is needed.  Examining the bus error cycle stack frame that the 020 put on
the stack (it is a long-type frame, format code 1011 (Bhex)) the access
address is listed as 01EDFF8, which is 12 bytes below the stack-pointer,
on the next lower 4K page that has not been allocated yet.  The problem is
the code was written assuming this particular kind of thing couldn't
happen because the Motorola 68881 User's manual clearly states on page
5-16, that "..the designated stack pointer is decremented by 12 bytes
before transfer of each register."  The curious thing is that the stack
pointer, saved in the frame, is still 01EE004.  It is as if the write of
the fp register is being attempted _before_ the stack pointer is
decremented, in direct contradiction to the documentation.  This has been
tested with low level-debugger and a hardware emulator, and there is an
attempt to access a location 12 bytes below the stack pointer, before the
sp has been decremented.  Any comments from anyone? Am I going crazy, is
this happening, or an artifact of something else?  It seems like the
020/881 wants to write a fp register to memory and _then_ decrement the
sp.  I would appreciate it if anyone who has a clue would post, or email
if it is not deemed of general interest.  (probably not.)

  Note: if emailing, use the path listed in Path:   or
     ..uunet!utah-cs!utah-gr!uplherc!wicat!sarek!gsarff,

because sarek isn't registered yet, so it is doubtful that gsarff@sarek
will work.

-----------------------------------------------------------------------------
The best swords can cut you and you don't even know you have been cut until
you start to bleed.