Path: utzoo!utgpu!watserv1!watmath!att!att!bu.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Assembly question from turnip
Keywords: can allocmem crash?
Message-ID: <2176@lpami.wimsey.bc.ca>
Date: 29 Oct 90 11:34:21 GMT
Lines: 58
Return-Path: <lpami!lphillips>
To: van-bc!rnews

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

We are speaking of calling a system routine here, and staying within one task.
There is no context switch at all. The sequence is something like this...


	set up regs, remembering that D0, d1, a0, and a1 are 'scratch'
	call system routine 
	check for return code in d0, if applicable
  act on result

The condition codes at the return from the system routine reflect _something_
the routine did before it returned control to us. The thing is, we know what
the system routine did, at least to the extent that is documented in the
autodocs (or in any library), but we do not have any knowledge of how it did
what it does. Because the condition codes are not guaranteed to reflect the
returned value in D0, we cannot do a test as the first operation after thr
return, and expect it to always show the result. This is in spite of any
observed behaviour on programs that work.

A good example is (if I remember correctly), DoIO. In 1.3, the condition code
was set to reflect the contents of D0 (an observation borne out by a program I
wrote when run on my particular system). The same program broke under 2.0,
because the condition code no longer reflected the return value.  It did not
break because CBM did something wrong, but because I made the mistake of
ass-u-m(e)-ing that the condition code acted in the observed way.  From the
documentation supplied by CBM, it can be argued that not only did they not do
anything wrong, but that they actually _did not change DoIO at all_, from its
documented behaviour.

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