Functions with side effects
in [Fortran]
|
From: nmm1 on 20 Jul 2010 10:36 In article <2010072011131116807-GordonSande(a)gmailcom>, Gordon Sande <Gordon.Sande(a)gmail.com> wrote: >On 2010-07-20 02:24:10 -0300, nospam(a)see.signature (Richard Maine) said: >> Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: >> >>>> As "undefined" basically means "does not have a value according to the >>>> standard" and to reference a variable means "to use its value", it is >>>> sensible that referencing an undefined variable might be problematic. >>> >>> As I said before, I think this is all correct, but there is still this >>> nagging issue that the variable had a defined value before, nothing was >>> done to change that value, and afterwards the value is undefined. > >Isn't processor dependent a property of the programm while undefined is >a property of (really prohibition on) the programmer? Sometimes it is possible >to also view undefined as a property of the program. This all relates back to >the notion that the Fortran statndard is as much about what the programmer is >allowed to do as what the program is expected to do. I wish :-( No. The term "processor dependent" was introduced in Fortran 77 for I/O aspects that were well-defined but where each system varied wildly. Unfortunately, there were some historical restrictions that conveyed essentially the same meaning (of which the impure function call was by far the most important). Once the standard expected all processor-dependent behaviour to be documented, the opportunity for making that processor-dependent was lost. As far as I know, "undefined" is used only for values in Fortran, and not for behaviour. Regards, Nick Maclaren.
From: glen herrmannsfeldt on 20 Jul 2010 14:01 Gordon Sande <Gordon.Sande(a)gmail.com> wrote: (snip) > Isn't processor dependent a property of the programm while > undefined is a property of (really prohibition on) the programmer? > Sometimes it is possible to also view undefined as a property > of the program. This all relates back to the notion that the > Fortran statndard is as much about what the programmer is > allowed to do as what the program is expected to do. For IOSTAT, and other status values, it does seem that they are properties of the system, and so programs running on that system. As I noted before, though, using the sign bit with bitwise intrinsic functions is processor dependent. It should work fine with twos complement, but can give surprising results with ones complement and sign magnitude systems. (It would seem possible for a twos complement system to give special treatment to the most negative value, but I don't know any that do that.) Ones complement and sign magnitude systems could give special treatment to negative zero, such as use it for a trap value. Otherwise, it has to compare equal to positive zero. So, this could be considered a restriction on the programmer, or program, if the program runs on such a system. -- glen
From: Ex-FE on 20 Jul 2010 19:41 Hi, Did the following on my MCP LX140 with Fortran77 Did a Div by 0 to cause a program Dump. COMMENT PROGRAM AREA implicit none integer i, j, k real r(2) double precision d(1) equivalence (r, d) k = i/j STOP END 0033 (01,000A) 0 000000 000000 0 0032 (01,0009) 2 000000 000000 Double: 2nd word:0 0 0031 (01,0008) 2 000000 000000 Double: 1st word:0 , Double:0 0.0 0 0030 (01,0007) 0 000000 000001 Op: Dec: 1 0 002F (01,0006) 0 000000 000000 0 002E (01,0005) 0 000000 000000 0 002D (01,0004) 0 000000 000000 0 002C (01,0003) 0 000000 000000 Format in above is messed up. Ex-FE uis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote in news:aOOdnf9KwqlfNtnRnZ2dnUVZ_tKdnZ2d(a)indra.net: Hi E > On 7/19/2010 12:02 PM, glen herrmannsfeldt wrote: > <snip> >> Before TRANSFER this was often done because it was pretty much >> the only way to do it. I can find a few ways that undefined >> results should come from the EQUIVALENCE case, but TRANSFER >> should give the right result. In years past there were processors >> with tagged storage. Additional bits indicate the type of value >> stored in a given storage location. Most likely there is a way >> on such machines to do TRANSFER, but EQUIVALENCE won't do the >> appropriate operation. > <snip> > > Unisys MCP systems still use tag fields: 0 for single precision, 2 for > double precision. Anyone have access to a FORTRAN compiler on one of > these? It seems like this would be valid code: > > implicit none > real r(2) > double precision d(1) > equivalence (r, d) > > My guess is that accessing an element of d after setting an overlapping > element of r (or vice versa) would give surprising results. > > I used FORTRAN on this architecture's predecessor (Burroughs Large > Systems) years ago, but I never tried doing this. (We didn't use double > precision that much, as I recall. Not enough memory, and the 39-bit > single-precision mantissa was usually good enough.) > > Louis >
From: Mike Hore on 20 Jul 2010 22:38 On 21/07/10 9:11 AM, Ex-FE wrote: > Hi, > > Did the following on my MCP LX140 with Fortran77 > > Did a Div by 0 to cause a program Dump. > > COMMENT PROGRAM AREA > implicit none > integer i, j, k > real r(2) > double precision d(1) > equivalence (r, d) > k = i/j > STOP > END > > > > > > 0033 (01,000A) 0 000000 000000 > 0 > 0032 (01,0009) 2 000000 000000 Double: 2nd word:0 > 0 > 0031 (01,0008) 2 000000 000000 Double: 1st word:0 , > Double:0 > 0.0 > 0 > 0030 (01,0007) 0 000000 000001 Op: Dec: 1 > 0 > 002F (01,0006) 0 000000 000000 > 0 > 002E (01,0005) 0 000000 000000 > 0 > 002D (01,0004) 0 000000 000000 > 0 > 002C (01,0003) 0 000000 000000 > > Format in above is messed up. > > Ex-FE Hi - I'm guessing as to the dump format, but would the column on the end be the address (or offset)? In that case it looks like it's ignored the equivalence, maybe because it wouldn't make sense on that hardware? Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
From: Ex-FE on 21 Jul 2010 19:12
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 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 Ex-FE $1(a)news.eternal-september.org: > On 21/07/10 9:11 AM, Ex-FE wrote: >> Hi, >> >> Did the following on my MCP LX140 with Fortran77 >> >> Did a Div by 0 to cause a program Dump. >> >> COMMENT PROGRAM AREA >> implicit none >> integer i, j, k >> real r(2) >> double precision d(1) >> equivalence (r, d) >> k = i/j >> STOP >> END >> >> >> >> >> >> 0033 (01,000A) 0 000000 000000 >> 0 >> 0032 (01,0009) 2 000000 000000 Double: 2nd word:0 >> 0 >> 0031 (01,0008) 2 000000 000000 Double: 1st word:0 , >> Double:0 >> 0.0 >> 0 >> 0030 (01,0007) 0 000000 000001 Op: Dec: 1 >> 0 >> 002F (01,0006) 0 000000 000000 >> 0 >> 002E (01,0005) 0 000000 000000 >> 0 >> 002D (01,0004) 0 000000 000000 >> 0 >> 002C (01,0003) 0 000000 000000 >> >> Format in above is messed up. >> >> Ex-FE > > Hi - I'm guessing as to the dump format, but would the column on the end > be the address (or offset)? In that case it looks like it's ignored the > equivalence, maybe because it wouldn't make sense on that hardware? > > Cheers, Mike. > > --------------------------------------------------------------- > Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au > --------------------------------------------------------------- > |