Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.westnet.com.au!news.westnet.com.au.POSTED!not-for-mail NNTP-Posting-Date: Wed, 29 Feb 2012 03:20:05 -0600 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <51fe1e15-cae2-4b64-8047-f581f84bef35@p6g2000yqi.googlegroups.com> <415d56a1-a8bb-49cd-9b3c-0d53b2a9e171@gr6g2000vbb.googlegroups.com> <22689371.4694.1330447517208.JavaMail.geo-discussion-forums@ynkz21> <9r598uFkvhU1@mid.individual.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit From: Bernd Felsche User-Agent: nn/6.7.3 Date: Wed, 29 Feb 2012 17:17:21 +0800 Message-ID: <127129xcig.ln2@innovative.iinet.net.au> Lines: 48 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 203.59.162.4 X-Trace: sv3-DXu+RJhgIJD6mFmYo6ofYq7SEjWJbkmIKccMemBVbkmT2IgMJU8i4AHMEGGmuMS9sKfaWe79D5qcGJz!qyy5eDaTJUDBrc3J1bgNTEdXkhsGzm0+7LZecLm5jGZ9zr/nON7MGdTvKq4eDzHva0/gnU7OQnkZ!rQ5PmuM= X-Complaints-To: abuse@westnet.com.au 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: 3494 Xref: x330-a1.tempe.blueboxinc.net comp.arch:6166 Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Andrew Reilly wrote: >> On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: >>> Of course, writing schedulers and spin-loops is complicated by >>> having to allow for interrupts, but it's not as truly evil as >>> writing handlers. >> But at least the interrupt handlers generally only have to be >> written by people who are up to the task, and who understand the >> issues. >I think I'm somewhere in the middle here: >I think interrupts are _fine_, but I really don't want them to have >(immediate) user-visible consequences. >I.e. except for the task switch interrupt, I would like _all_ interrupt >handlers to be of the absolute minimal form: >Read a status port or two to figure out exactly what needs to be done, >save away any critical data in a fifo buffer and send a signal to a >regular thread to do the rest of the work, before returning cleanly. Interrupt handling should be only a matter of preserving the context within which the interrupt occurred and assigning/scheduling a thread to do the heavy lifting, outside of the interrupt handler. >Async callbacks to user code is of course absolutely out of the question! >With such a model it is easy to (manually) make sure that there are no >side effects and no way for the interrupted program to be perturbed. There is no technical reason why a user-level program should not be able to be assign a thread to be event-driven; either by internal events (e.g. floating-point exceptions) or external (e.g. mouse events, interrupts and async-io-completion). Few "regular programmers" are able to work effectively in an event-driven environment; because so much code base to which they are routinely exposed is predominately procedural. It takes a different frame of mind to undertake efficient, event-driven programming. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | For every complex problem there is an X against HTML mail | answer that is clear, simple, and wrong. / \ and postings | --HL Mencken