Functions with side effects
in [Fortran]
|
From: Louis Krupp on 21 Jul 2010 22:05 On 7/21/2010 5:12 PM, Ex-FE wrote: > Hi, > Since I haven't used Fortran since 1967-68 on an IBM 1620, I decided to > read the Fortran77 Manual. > Changed Fortran77 program to: > > Notice compiler now allocates 1 array for r and d as result of > equivalance statement and generates appropriate code for single precision > r and double precision code for d using the same memory offset (3,0002). > > PROGRAM Test > implicit none > real r(2) > double precision d(1) > equivalence (r, d) > r(1) = 4.0 > Debug Programdump(all) > d(1) = 5.0 > Debug Programdump(all) > r(1) = 3.1 > Debug Programdump(all) > d(1) = 3.1 > Debug Programdump(all) > STOP > END > > > ***** LOCAL AND GLOBAL VARIABLES FOR TEST ***** > REAL ARRAY R REL.ADDR.= (3,0002) > > From first Program Dump r(1) = 4.0 > Note: Tag 0 indicating Single Precision > 0024 (03,0002) C 200000 00248B Desc: Present-mom, ASD=012459, Length=2 > 0(0000) 0 000000 000004 0 000000 000000 > > From second Program Dump d(1) = 5.0 > Note: Tag 2 indicating Double Precision > 0024 (03,0002) C 200000 00248B Desc: Present-mom, ASD=012459, Length=2 > 0(0000) 2 000000 000005 2 000000 000000 > > From third Program Dump r(1) = 3.1 > Note: Tag 0 indicting single precision normalized > 0024 (03,0002) C 200000 00248B Desc: Present-mom, ASD=012459, Length=2 > 0(0000) 0 263199 99999A 2 000000 000000 So the second word still has tag 2. According to the standard, it sounds like r(2) should be undefined, and referencing r(2) at this point on this system could cause a more dramatic failure than the standard writers ever dreamed of. (The same would happen if nothing had been stored to either d or r, since as I recall both words had their tag initialized to 2.) Louis
From: Richard Maine on 21 Jul 2010 23:50 Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: > According to the standard, it > sounds like r(2) should be undefined, and referencing r(2) at this point > on this system could cause a more dramatic failure than the standard > writers ever dreamed of. I think you underestimate the imagination of the standard writers on that matter. The standard really does say that absolutely anything can happen when you reference an undefined variable. That specification came in long before I was involved in standards activities, but I've known enough of the standard writers to have a pretty good idea that it was written that way intentionally and with full knowledge of some of the "nasty" possibilities. While I didn't know the writers of the original words, which date back to at least f77 and probably to f66, I did know all of the more recent writers (and was one myself) and I *KNOW* that some of the them are aware of such issues; I have heard such issues discussed by them. 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. -- 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 00:23 On 22/07/10 11:35 AM, Louis Krupp wrote: >... >> From third Program Dump r(1) = 3.1 >> Note: Tag 0 indicting single precision normalized >> 0024 (03,0002) C 200000 00248B Desc: Present-mom, ASD=012459, Length=2 >> 0(0000) 0 263199 99999A 2 000000 000000 > > So the second word still has tag 2. According to the standard, it sounds > like r(2) should be undefined, and referencing r(2) at this point on > this system could cause a more dramatic failure than the standard > writers ever dreamed of. My guess would be a bounds violation error -- the hardware on seeing the tag 2 would try to fetch the next word, which would be outside the array. If r had been declared bigger, then on my reading of the Level Epsilon manual under aFOP <fetch operand value>, the next word would be fetched, and its tag of zero wouldn't give an error since the manual just says the tag must be in {0, 2}, and the result is simply set to tag 2 regardless. So basically you'd get garbage in the lower half of your DP operand. But I don't have an MCP machine here, so I can't check for sure. Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
From: Mike Hore on 22 Jul 2010 00:27 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 (On the PowerPC's 64-bit IEEE FP, I get 4008 CCCC CCCC CCCD but that wouldn't agree with the Burroughs format. Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
From: Louis Krupp on 22 Jul 2010 03:45
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) Louis |