Functions with side effects
in [Fortran]
|
From: nmm1 on 22 Jul 2010 04:29 In article <1jlzyj8.9l4gqa1c5ca9cN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: > >Heck, I've heard discussions about how exceeding array bounds could >accidentally hit memory-mapped I/O devices and cause no end of strange >results; this is usually in conjunction with comments made in jest about >how such a programming error could possibly starting WW III. But the >people discussing it also tended to be aware of possibilities that were >more plausible, but could still cause pretty nasty computer crashes. I have actually invoked a completely bogus system call, which is as potentially catastrophic as hitting an I/O register. The result was a little weird .... Regards, Nick Maclaren.
From: Richard Maine on 22 Jul 2010 11:32 <nmm1(a)cam.ac.uk> wrote: > In article <1jlzyj8.9l4gqa1c5ca9cN%nospam(a)see.signature>, > Richard Maine <nospam(a)see.signature> wrote: > > > >Heck, I've heard discussions about how exceeding array bounds could > >accidentally hit memory-mapped I/O devices and cause no end of strange > >results; this is usually in conjunction with comments made in jest about > >how such a programming error could possibly starting WW III. But the > >people discussing it also tended to be aware of possibilities that were > >more plausible, but could still cause pretty nasty computer crashes. > > I have actually invoked a completely bogus system call, which is as > potentially catastrophic as hitting an I/O register. The result was > a little weird .... Easy to do by accident on an old CDC, where you invoked a system call by writing something to address zero. Accidentally use data as an address and you had decent odds of hitting address zero. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Mike Hore on 22 Jul 2010 19:44 On 22/07/10 5:15 PM, Louis Krupp wrote: > On 7/21/2010 10:27 PM, Mike Hore wrote: >> On 22/07/10 8:42 AM, Ex-FE wrote: >> >... >>> >>> From fourth Program Dump d(1) = 3.1 >>> Note: Tag 2 indicating Double Precision normalized >>> 0024 (03,0002) C 200000 00248B Desc: Present-mom, ASD=012459, Length=2 >>> 0(0000) 2 263199 99999A 2 000000 000000 >>> >>> >> >> Ummm, I know the FP format is a bit weird on these machines, but I might >> have expected the DP value to be >> >> 2 263199 999999 2 99999 99999A > > ... which it might have been had d(1) been set to 3.1d0 instead of just > 3.1. My guess is that the compiler emits the XTND operator and the > single precision value > > "... is converted to double precision representation by appending a > second word whose fields are initialized to zero; the double precision > result is left on the stack. Note that its numeric value is not > changed." (Clearpath Epsilon Architecture Support Reference Manual, Nov. > 2008) Yes, I'm sure you're right. It would make sense for the compiler to take 3.1 as a single precision value. Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
From: Richard Maine on 23 Jul 2010 13:57 Mike Hore <mike_horeREM(a)OVE.invalid.aapt.net.au> wrote: > It would make sense for the compiler to > take 3.1 as a single precision value. "Make sense" seems a bit of an understatement. The standard specifies that 3.1 as a single precision value. (The details of how single precision values get converted to double precision on assignment are not specified by the standard, but that 3.1 is a single preciion value is). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Mike Hore on 23 Jul 2010 19:45
On 24/07/10 3:27 AM, Richard Maine wrote: > Mike Hore<mike_horeREM(a)OVE.invalid.aapt.net.au> wrote: > >> It would make sense for the compiler to >> take 3.1 as a single precision value. > > "Make sense" seems a bit of an understatement. The standard specifies > that 3.1 as a single precision value. (The details of how single > precision values get converted to double precision on assignment are not > specified by the standard, but that 3.1 is a single preciion value is). > No worries - I'm reading this on comp.sys.unisys -- I haven't used Fortran for 40 years! Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au --------------------------------------------------------------- |