🚀 go-pugleaf

lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
> dfrancis@tronsbox.xei.com (Dennis Francis Heffernan) writes:
[...]
>>	As for checking the condition codes, I was under the impression that
>>any time you moved a zero into a data register, the zero flag was set.  I 
>>don't see then how the system calls could NOT set the flag, but I'll take your
>>words for it.

>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?

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

In article <1990Oct29.205140.28826@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>lphillips@lpami.wimsey.bc.ca (Larry Phillips) 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?
                  ^^^^^^^
He didn't talk about a context switch but about returning from a
system function called by your program, and this hasn't anything
to do with multitasking and task switching. He explained what can
happen near the very end of such a library routine, shortly before
the finishing RTS. The simple summary is: Do a TSTB or other check
for the flags by your own, but don't rely on the flags being set
just after RTSing.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

In article <1990Oct29.205140.28826@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>> dfrancis@tronsbox.xei.com (Dennis Francis Heffernan) writes:
>[...]
>>>	As for checking the condition codes, I was under the impression that
>>>any time you moved a zero into a data register, the zero flag was set.  I 
>>>don't see then how the system calls could NOT set the flag, but I'll take your
>>>words for it.
>
>>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?
>
>Kent, the man from xanth.
><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

	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.

	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.


=========================================================================
Eduardo Horvath				eeh@btr.com
					..!{decwrl,mips,fernwood}!btr!eeh
	"Trust me, I know what I'm doing." - Sledge Hammer
=========================================================================

In article <1990Oct29.205140.28826@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>lphillips@lpami.wimsey.bc.ca (Larry Phillips) 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). 
>
>WHAT? How can you do multitasking at  all, ...

Picture the end of an OS call.

     MOVE.L   RESULT,D0
     MOVE.L   SOMETHINGELSE,D1
     RTS
 
------------------------

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