From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 21 Feb 2007 00:50:25 -0500 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] NaN(2) In-Reply-To: <9c9d07436eff1c038450ca310ea13a7a@plan9.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9c9d07436eff1c038450ca310ea13a7a@plan9.jp> Topicbox-Message-UUID: 11baab6c-ead2-11e9-9d60-3106f5b1d025 On 2/20/07, Joel Salomon wrote: > My system doesn't seem to like it when I call NaN(2): That is the default behavior. See getfcr(2). In particular, if you add setfcr(getfcr()&~FPINVAL); to your program then you can carry NaNs around willy-nilly without causing exceptions. On 2/20/07, Joel Salomon wrote: > > this might be an alignment problem. but that's a wild guess. > > I think not: > acid: SP > 0x00000044 This tells you that SP's "address" is 0x44. (The registers appear to have memory addresses starting at 0 in acid.) If you want to find out what SP is, you have to dereference it, as in *SP. On 2/20/07, erik quanstrom wrote: > after a bit of actual thought, i think that NaN > is supposed to generate a note. if you do catch > the note, the program should work fine. This is true too, though setfcr will avoid the notes entirely. Russ