🚀 go-pugleaf

In <ggk.657327711@tirith.UUCP>, ggk@tirith.UUCP (Gregory Kritsch) 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?
>>>
>>	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.  

Maintenance code, in this case, is anything the system routine wants to do to
perform its function.

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

You are decidedly mistaken. The CCR is not defined as part of the return
conditions in any of the Amiga's system calls. If a routine is intercepted with
SetFunction(), it is up to the programmer as to whether he wishes to set the
CCR according to the returned value in D0 or not. If he does, no problem.
If he doesn't, it won't matter, since properly written proograms calling the
function will explicitly test for the contents of D0 if applicable.

>From the "Amiga ROM Kernel Reference Manual; Includes and Autodocs; Revised and
Updated" (the blue RKM), page 'Introduction-5':

o Except as noted, system library functions use registers D0, D1, A0, and A1 as
  scratch registers and you must consider their former contents to be lost
  after a system library call.  The contents of all other registers will be
  preserved.  System functions which provide a result will return the result in
  D0.

o System functions that return a result may not necessarily affect the
  processor condition codes.  The caller must test the returned value before
  acting on a condition code.  This is usually done with a TST or MOVE
  instruction.

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

Doesn't matter if they do or not. If they do now, under 1.3, they may not under
2.0, or 2.1, or 8.9, at which time, code depending on the CCR will break, with
nobody to blame but the application programmer.

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

Maybe so, but if you want your programs to work, release after release, you
will follow the rules and test the returned value. It is no different than any
of the other system library interface rules. Basically, that's the way it
works, and that's the way it is guaranteed to work.

-larry

--
It is not possible to both understand and appreciate Intel CPUs.
    -D.Wolfskill
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+