Functions with side effects
in [Fortran]
|
From: dpb on 2 Aug 2010 22:27 ralf.schaa wrote: .... > I am confused after reading the thread - if there is an illegal > statement, is it that global variable n is modified in the function? > Or is it rather in the statement f(3) + f(3) ? The latter. Reread Richard M's very first response. --
From: Mike Hore on 2 Aug 2010 22:56 On 2/08/10 8:39 AM, Paul Kimpel wrote: [snip] > ... > As I mentioned in the beginning, I was in Mike Hore's camp -- I would > have thought that this would produce a bounds violation fault, as the > hardware found r(2) to have a DP tag value, and consequently tried to > fetch the second word, which would have been outside the bounds of the > array. Surprise, surprise, it completed without generating a fault. > ... > > For the answer, it turns out that one need only RTFM, although in the > case of the Architecture Reference Manual, that is not normally a > trivial task. Mike was on the right track with the "aFOP" common action > (under Read Evaluation Operators in Section 5, Operator Set), but you > have to look at the entire text. Whoops, I was in too much of a hurry... Thanks Paul for the fascinating analysis, and also for the work on DP floating point. I've never used one of these machines, but have had a very long-term interest in them, because they're, well, fascinating and brilliant! Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
From: Larry Krablin on 3 Aug 2010 15:10 Paul's explanation is correct. When accessing operands through a data descriptor, the "size" of the descriptor overrides the tags on the items to which it points (assuming they are in fact operands - tag 0 or 2). When storing, the tags on the data to be stored must agree with the descriptor, but not necessarily with the stuff being overwritten. Yes, you can get apparently mismatched doubles that way, but since you're going to aceess the data with a descriptor also, it really doesn't matter. FORTRAN equivalence facilities do give you the ability to look at the separate halves of a double this way. I don't know what FORTRAN's rules are for normalizing floating point items, but the MCP system implementations do NOT guarantee a normalized result unless it is explicitly called for by a NORM operator. The only cases where the result format is guaranteed without explicit coercion is that ADD, SUBT, and MULT are required to return their result in integer format if both arguments were in single precision integer format (distinct from just integer value) and the result can be represented in (single) integer format. Otherwise, the only requirement is a numerically correct answer. There are no such normalization rules for floating point, although you will find lots of instances where there appear, on any given implementation, to be some rules in play. DON'T DEPEND ON THEM! Larry Krablin Unisys MCP Architecture "Mike Hore" <mike_horeREM(a)OVE.invalid.aapt.net.au> wrote in message news:i380ge$ovf$1(a)news.eternal-september.org... > On 2/08/10 8:39 AM, Paul Kimpel wrote: > > [snip] > >> ... >> As I mentioned in the beginning, I was in Mike Hore's camp -- I would >> have thought that this would produce a bounds violation fault, as the >> hardware found r(2) to have a DP tag value, and consequently tried to >> fetch the second word, which would have been outside the bounds of the >> array. Surprise, surprise, it completed without generating a fault. >> ... >> >> For the answer, it turns out that one need only RTFM, although in the >> case of the Architecture Reference Manual, that is not normally a >> trivial task. Mike was on the right track with the "aFOP" common action >> (under Read Evaluation Operators in Section 5, Operator Set), but you >> have to look at the entire text. > > Whoops, I was in too much of a hurry... > > Thanks Paul for the fascinating analysis, and also for the work on DP > floating point. I've never used one of these machines, but have had a > very long-term interest in them, because they're, well, fascinating and > brilliant! > > Cheers, Mike. > > --------------------------------------------------------------- > Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au > ---------------------------------------------------------------
From: glen herrmannsfeldt on 3 Aug 2010 15:27 In comp.lang.fortran Larry Krablin <larry.krablin(a)unisys.com> wrote: (snip) > I don't know what FORTRAN's rules are for normalizing floating point items, > but the MCP system implementations do NOT guarantee a normalized result > unless it is explicitly called for by a NORM operator. Well, the Fortran standard pretty much doesn't say anything about the results of floating point operations. Even so, people will expect the right results, and normalization can matter. For S/360 (and HFP in its successors) unnormalized values are allowed, but are generated only by the Add and Subtract Unnormalized instructions. For addition and subtraction, prenormalization is done based on the exponent values. The Fortran AINT function is implemented by adding 0*16**7 such that prenormalization will shift out any digits past the hexadecimal point, add zero, and then post-normalize the result. Similar for DINT, but 0*16**15 instead. So, unless prenormalization is done based on both the exponent and leading zeros in the significand, you will get the wrong results from unnormalized operands. S/360 multiply and divide prenormalize any unnormalized operands, such that the correct results are generated. > The only cases where > the result format is guaranteed without explicit coercion is that ADD, SUBT, > and MULT are required to return their result in integer format if both > arguments were in single precision integer format (distinct from just > integer value) and the result can be represented in (single) integer format. > Otherwise, the only requirement is a numerically correct answer. There are > no such normalization rules for floating point, although you will find lots > of instances where there appear, on any given implementation, to be some > rules in play. DON'T DEPEND ON THEM! (snip) -- glen
From: Nick Maclaren on 3 Aug 2010 15:45
In article <i39qje$cvr$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >In comp.lang.fortran Larry Krablin <larry.krablin(a)unisys.com> wrote: > >> I don't know what FORTRAN's rules are for normalizing floating point items, >> but the MCP system implementations do NOT guarantee a normalized result >> unless it is explicitly called for by a NORM operator. > >Well, the Fortran standard pretty much doesn't say anything about >the results of floating point operations. Even so, people will >expect the right results, and normalization can matter. Ah, but what is 'right'? >S/360 multiply and divide prenormalize any unnormalized operands, >such that the correct results are generated. Don't bet on it. The gotcha with prenormalisation on some operations only is that a program can check for an error condition, find no error, only to have it then occur! IF (b /= 0.0) c = a/b I had some amusement with such code in LAPACK on a Hitachi SR2201; with my background, it was trivial to find and fix, but some users got very confused by the same gotcha. Regards, Nick Maclaren. |