Functions with side effects
in [Fortran]
|
From: glen herrmannsfeldt on 19 Jul 2010 16:09 In comp.lang.fortran Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: (snip, I wrote) >> 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. As I understand it, Unisys is one of the last to produce ones complement machines, maybe with some still in production. > 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. Or maybe not so surprising. It might use the tag and load the appropriate sized value, independent of the declaration. Though R(2) might be pretty strange. > 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.) I believe that some Burroughs machines store integers as appropriately normalized floating point values, with zero for the exponent. That is, such that 1 and 1.0 have the same bitwise representation. -- glen
From: Louis Krupp on 19 Jul 2010 16:43 On 7/19/2010 2:09 PM, glen herrmannsfeldt wrote: > In comp.lang.fortran Louis Krupp<lkrupp_nospam(a)indra.com.invalid> wrote: > (snip, I wrote) >>> 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. > > As I understand it, Unisys is one of the last to produce ones > complement machines, maybe with some still in production. The MCP series, FWIW, uses sign-magnitude. I've never used the other (Sperry) architecture. > >> 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. > > Or maybe not so surprising. It might use the tag and load the > appropriate sized value, independent of the declaration. > Though R(2) might be pretty strange. It could go boom. Either it would notice the misaligned address, or it could try to index off the end of the array to get the second word, or it could see that the second word doesn't have tag 2. > >> 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.) > > I believe that some Burroughs machines store integers as > appropriately normalized floating point values, with zero for > the exponent. That is, such that 1 and 1.0 have the same bitwise > representation. Integer 1 will be interpreted as floating point 1.0, but floating point "normalization" has a specific meaning for this architecture: Shift the mantissa to the left until the high-order octade is non-zero, and decrease the exponent correspondingly. So integer 1 and normalized 1.0 will look different but would be treated as equal; in Unisys extended FORTRAN, they would pass the .eq. test but not the .is. test. (I don't have access to a Unisys system to verify this.) (I never could figure out when floating point values were normalized, or why. There's an operator to force normalization if that's what's needed for some reason. The only time I ever used it was when porting code that used low-order bits to store metadata.) Louis
From: Stephen Fuld on 19 Jul 2010 18:58 On 7/19/2010 1:43 PM, Louis Krupp wrote: > On 7/19/2010 2:09 PM, glen herrmannsfeldt wrote: snip >> As I understand it, Unisys is one of the last to produce ones >> complement machines, maybe with some still in production. > > The MCP series, FWIW, uses sign-magnitude. I've never used the other > (Sperry) architecture. The Sperry descendant systems do indeed use ones complement arithmetic. And they are still in production. -- - Stephen Fuld (e-mail address disguised to prevent spam)
From: glen herrmannsfeldt on 19 Jul 2010 19:45 In comp.lang.fortran Stephen Fuld <SFuld(a)alumni.cmu.edu.invalid> wrote: (snip, I wrote) >>> As I understand it, Unisys is one of the last to produce ones >>> complement machines, maybe with some still in production. (snip) > The Sperry descendant systems do indeed use ones complement > arithmetic. And they are still in production. It was some years ago that I last knew that, and so wasn't sure that it was still true. Thanks for the confirmation. (and warning to those who write twos-complement only code.) -- glen
From: Gary L. Scott on 19 Jul 2010 19:59
On 7/19/2010 5:58 PM, Stephen Fuld wrote: > On 7/19/2010 1:43 PM, Louis Krupp wrote: >> On 7/19/2010 2:09 PM, glen herrmannsfeldt wrote: > > snip > > >>> As I understand it, Unisys is one of the last to produce ones >>> complement machines, maybe with some still in production. >> >> The MCP series, FWIW, uses sign-magnitude. I've never used the other >> (Sperry) architecture. > > The Sperry descendant systems do indeed use ones complement arithmetic. > And they are still in production. > > wull, there outta be a law! |