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!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 24 Feb 2012 11:54:49 -0600 Message-ID: <4F47CEE5.6000107@SPAM.comp-arch.net> Date: Fri, 24 Feb 2012 09:54:45 -0800 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:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <4F451687.2080101@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 58 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-KHyV/m7FADFUmEm0QsbfU+VSEkl39JlYZYJSSmjuIoHI9Hd/801r4rK6YK1vdQP19R6qX7N/4VmGj5O!CRqutW1ndkES3rt/RuCvev5tK5jn1ClwIMUtV8a2KnOdzG8/OVFz6ZyRRd1pzxI= 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: 3741 Xref: x330-a1.tempe.blueboxinc.net comp.arch:6055 On 2/24/2012 5:07 AM, nmm1@cam.ac.uk wrote: > In article, > Stephen Fuld wrote: >>> >>> I hate interrupts, because nobody gets them right :-( >> >> I think I understand what your attempting to do here. You want to >> eliminate the interrupt from the "main" CPU and off load the device >> driver code to a smaller, yet essentially compatible core. > > No, not at all. Still, you have understood orders of magnitude better > than Andy Glew, who seems to be very confused about the principles. > > What I am proposing is the complete abolition of asynchronous interrupts > that seize a core and then go and do something else, This is what I understood you to be saying. And this is what I am saying is an intellectual dead end. > because it is very > well-known that those are both theoretically and practically almost > impossible to get right. Proof? In particular the theoretical part. > Similarly, time-slice and debugger interrupts an be made semi-synchronous > by a different approach (or any one of several, actually), which > eliminates all of the RAS degradation introduced by their implementation > as interrupts. Timing/performance-dependent RAS issues remain, but are > the same whether polling, interrupts, coroutines or whatever are used. What are these mechanisms, please? Let's make it specific: what is such a mechanism for timer (not time-slice) interrupts, that makes them synchronous? That dies not amount to hardware cooperative multithreading? The only possibility I see is (a) hardware cooperative multithreading for normal preemption, e.g. interrupt only on regular events such as taken branches (and "Interrupt safe" spots scattered through the code) (b) non-recoverable error interrupts if the "interrupt safe" spot does not occur for too long a period of time. Although note that "non-recoverable" part can only mean "the suer process state is non-recoverable". It most be possible for the OS to kill the user process and reuse the processor, if only via a reset like mechanism, to prevent denial of service security problems. This I think can be theoretically proven. If you have any other techniques, please share them. Anecdotal references to "well known" techniques that are well known not accepted.