Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!newsfeed.freenet.ag!news2.euro.net!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!216.196.98.144.MISMATCH!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: Thu, 23 Feb 2012 22:09:40 -0600 Message-ID: <4F470D85.9010102@SPAM.comp-arch.net> Date: Thu, 23 Feb 2012 20:09:41 -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: 80 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-z74DIaqvy49/U4V8IC9Y87BdBNyXVT8Q3TCqXsKt4L4WY2phbdkzPKESPLq17RA70WCz4Fb+WDtsSAl!qnE/+F6LfJ4vj738o7p6YS9vW06iCNK7ufLqtKTGnDdOijA/ee4vlKNNNtJd6GQ= 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: 4429 Xref: x330-a1.tempe.blueboxinc.net comp.arch:6051 On 2/23/2012 3:24 PM, Stephen Fuld wrote: > On 2/22/2012 10:17 AM, nmm1@cam.ac.uk wrote: > > snip > >> Also, as you know, I wouldn't propose using uniformly small and >> slow CPUs. I really don't see why you can't have a couple of >> high-powered ones and a large number of small and simple ones >> for where that simplifies device control etc. Indeed, for most >> general-purpose systems and many embedded ones, the former need >> not include any privileged instructions (except as needed for >> TLB and floating-point fixup) or even be arbitrarily interruptible, >> and the latter need not have fancy floating-point etc. >> >> 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. This discussion is boring. Nick thinks he is proposing something radical, like going back to a I/O model that failed long ago. Sure, create offload processors. But eliminating external asynchronous interrupts such as those from I/O and timers, and internal synchronous exceptions such as those from page faults and floating point (two concepts Nick always seems to confuse) COMPLETELY is a dead end. (Similarly for the smaller class of asynchronous or delayed internal exceptions, such as delayed context switches (doable, but here I agree with Nick that people f**k these up), and delayed floating point exceptions (IMHO proven to be a bad idea - precise exceptions at the point of the instruction are best, or possibly, coprocesor style, reported on a subsequent instruction / coprocessor interaction). Reason: your offload processors eventually need to grab the attention of the main processor(s). They can do this a) cooperative multithreading style - a la transputer. E.g. on every taken branch. Overall, bad idea. You may have straightline code that is gigabytes of instructions long. (Hmm, define such an "interrupt safe state" on every taken branch, or on every megabyte crossing. I.e. batch. But why...) b) on a timer interrupt. If you do this, you still have to do interrupts. Maybe not so often, but you still need to do them correctly. Perhaps you won't be as tempted to try to "optimize" interrupts in the umpteen ways that fail because they don't occur so often. But you still need to do timer interrupts. Note also that modern OSes are tickless. They don't take timer interrupts at a fixed rate. I may not have seen all of the interrupt and exception problems that Nick says he has seen. But those that IO have seen are usually due to premature optimization - to trying to cut corners. Since we can't eliminate interrupts completely, might as well buckle down and do them properly and correctly. And then introduce offload processors as a performance enhancement. But do not depend on such for correctness.