Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 03 Apr 2012 19:51:31 -0500 Message-ID: <4F7B9B0F.6060906@SPAM.comp-arch.net> Date: Tue, 03 Apr 2012 17:51:27 -0700 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <9thhmnFdvbU1@mid.individual.net> <3c05c00c-c54f-4ce3-bc2f-a66293740d10@ms3g2000pbb.googlegroups.com> In-Reply-To: <3c05c00c-c54f-4ce3-bc2f-a66293740d10@ms3g2000pbb.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 46 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-q5La90GhPE19D9pAERd62gSR58VOBsy2++r6eyoeY8eoRGbdyAyoXqRq5R0JOFjo3niLxlKY6BX9cyh!8gza4p0/xBFqXxAUAnpCtHedbHW+t8Wz8uFHTE3Npc6keC4W/XoHKaNAZlYw X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3625 Xref: csiph.com comp.arch:6428 On 4/3/2012 12:31 PM, Quadibloc wrote: > On Apr 3, 9:31 am, ChrisQ wrote: >> Assuming that any registers used are saved on int entry, >> then restored on exit, there is no way that there can be any undefined, >> smoke and mirrors side effects in terms of mainline code execution. > > In a word, no. Saving all registers on entry and restoring all > registers on exit is what subroutines do. Nitpicking: subroutines often (usually) have some registers and other state that is defined to be either smashed, unreliable, after exit (i.e. which needs to be caller saved if it is required to be preserved), as well as state, registers and, e.g. .condition codes or IEEE sticky flags, that may reflect the values returned. An interrupt routine had > better also save and restore the Program Status Word - the flags, like > the carry and overflow bit. An interrupt should arrange so that NO architectural register state in an interruptee is affected (except possibly for performance counters, e.g. counting number of interrupts). It can do this by saving and restoring, or by using shadow state, switching register and flag sets, etc. The latter approach can be fast, but does not scale to deeply nested interrupts - and also tends to slow down normal code if the shadow register set is in the same physical register file. If the shadow register set is physically separate, and the moral equivalent of microcode copies between the L1 and L2 register sets... (Note that I said "interruptee architectural register state". Memory state is highly likely to be changed.) Certain interrupts may not be so transparent - e.g. "halt waiting for interrupt systems", where one expects the interrupt to arrive and does not require all interruptee state to be preserved. For that matter "run while waiting for interrupt, doing something low priority that does not use all registers" I am a big advocate of there being defined code sequences that will save and restore all state. Even state that did not exist at the time the interrupt handler was written.