Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: MitchAlsup Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more Date: Sun, 12 Feb 2012 12:35:03 -0800 (PST) Organization: http://groups.google.com Lines: 23 Message-ID: <25559897.205.1329078903762.JavaMail.geo-discussion-forums@ynlp12> References: <4F3720F1.2040808@SPAM.comp-arch.net> NNTP-Posting-Host: 72.177.28.22 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1329078903 5899 127.0.0.1 (12 Feb 2012 20:35:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 12 Feb 2012 20:35:03 +0000 (UTC) Cc: nmm1@cam.ac.uk In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=72.177.28.22; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.arch:5898 On Sunday, February 12, 2012 1:16:57 PM UTC-6, nm...@cam.ac.uk wrote: > In article <4F3720F1.2040808@SPAM.comp-arch.net>, > Andy (Super) Glew wrote: > >(By the way, it annoys the heck out of me when people talk about user=20 > >level interrupt handlers. Usually they mean things like floating point= =20 > >exceptions - synchronous events, not asynch interrupts.) >=20 > Er, why should floating-point exceptions be synchronous? :-) Indeed! However, allowing FP exceptions to be asynchronous creates the need for SW = to understant that there may be more than one FP exception raised concurren= tly. This breakes the "fix one thing and return" exception handling philoso= ply. It can also make it difficult to identify the order of instructions wr= t the raised exceptionis. {That is a FP Multiply might take an exception in= loop 7 while a FP add might take an exception in loop 8, but since the com= piler unrolled the loops, whether the FP add or the FP mul came first is no= t determinable by looking at the source code. This creates "momentum" to st= ick with the "Precise exceptionis now and forever" rat hole.} Mitch