Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!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: <2182@lpami.wimsey.bc.ca> Date: 1 Nov 90 19:55:16 GMT Lines: 84 Return-Path: To: van-bc!rnews In , 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 | +-----------------------------------------------------------------------+