🚀 go-pugleaf

eeh@public.BTR.COM (Eduardo E. Horvath  eeh@btr.com) writes:
>>>There is no guarantee that the last operation to affect the condition codes is
>>>the one you are interested in (the move of the result to D0). In other words,
>>>the result might be moved to D0, then something else moved to or from another
>>>data reg, before control is returned to your program.
>>
>>WHAT? How can you do multitasking at  all,  if  whatever's  the  68000's
>>version of the program status register's set of condition  flags,  isn't
>>restored after a context switch? I guess my ignorance  is  showing,  but
>>this sure isn't how the world used to look the last time I worked at the
>>assembly  level.  What  did  I  miss?

My definition of "context switch" includes ALL the 68xxx registers, for
all the 68xxx processors in the system (ie 68030 + 68882).  This is, to
the best of my knowledge, what Exec does for the 68000 alone.  I've
checked this in Markus Wandel's Exec 1.2 disassembly.  I believe the
other processors are handled appropriately.

>	Multitasking has nothing to do with it.  The problem is that there is no
>guarantee that the last executed that affects the condition codes in the library
>call consists of loading the return value.  It is quite concievable that there
>is other internal maintenance code that has the side-effect of changing the CCR.
>It is also possible that someone has SetFunction()'ed that particular routine or
>has installed some code to monitor all system calls.  If there is an enveloping
>routine installed, it almost certainly does not load the return code as the last
>intruction before the function return.  It is always better to be safe than to
>visit the Guru.

Define "Mainenance code"?  As far as I know, there is none.  

Unless I'm mistaken (if I am, someone correct me please), but CCR is
part of the return value definition of a function.  Therefore, if the
SetFunction() code didn't appropriately set the CCR, it would be
considered broken.

I actually think many of the functions do end in something which will
set the CCR, or they end with a tst.l d0.

>	If you really don't like adding an additional compare instruction, you
>can store the result to memory and branch on the result of that.  Since you will
>need to move the return value anyway, it does not create any additional
>overhead.

Useless point: Perhaps I don't want to store a failure code, and
besides, that store would not be done otherwise, and it does take
processor time to do the store.

>=========================================================================
>Eduardo Horvath				eeh@btr.com
>					..!{decwrl,mips,fernwood}!btr!eeh
>	"Trust me, I know what I'm doing." - Sledge Hammer
>=========================================================================
--
  Gregory Kritsch                          | University of Waterloo
    Fido:  1:221/208.11110  [1:163/109.30] | 1A Computer Engineering
    UUCP:  ggk@tirith.UUCP                 |--------------------------
           ...!watmath!xenitec!tirith!ggk  | Amiga Fanatic