curious about 8 byte LOGICAL...
in [Fortran]
|
Prev: CVF help -- was: Re: It Hurts When I Do This -- diversion...
Next: Reading unknown number of lines in unknown number of files
From: James Van Buskirk on 24 Apr 2008 04:13 <robert.corbett(a)sun.com> wrote in message news:a8cdc142-7ea0-4fac-9bff-027056cd6070(a)r9g2000prd.googlegroups.com... > It has already been a problem for users of Sun Fortran. > They have let us know it. If you need > 32 bits it's just agony to have to work around it. E.g. KRNKNN seems much more manageable with 64-bit indices. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: robert.corbett on 24 Apr 2008 04:53 On Apr 24, 12:44 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > robert.corb...(a)sun.com wrote: > > (I wrote) > > >>Actually, I think it will still be a little while before it is > >>really a problem. For C, pointer variables will have to go to 64 > >>bits, but it will be much less important for subscript values. > >>For four byte integer and eight byte real, you can address > >>8GB and 16GB respectively with a signed 32 bit integer. > >>(Double that if you allow negative values.) > >>Most programs need more than one array, so the needed size will > >>be even smaller. For a square matrix, even 16 bit integers will > >>be big enough for 4GB. The subscript calculation still has > >>to be done in more than 32 bits, and compilers should adjust > >>to that. > > It has already been a problem for users of Sun Fortran. > > They have let us know it. > > Which problem? That the default integer isn't 8 bytes, > or that no integer is eight bytes. The problem is that the default integer is not 64 bits. Sun Fortran supports 8-byte signed and unsigned integers. > I claimed that for most programs it wouldn't be a problem, > which leaves room for those where it is. My first thought > would be that for those either some or all integer variables > would change to 64 bits. That does assume that 64 bit > integer subscripts are supported. Sun Fortran supports 64-bit integer subscripts. When code is compiled for 64-bit machines, subscript calaculations are done using 64-bit arithmetic, even if the subscript expressions use only 32-bit or shorter integer primaries. Bob Corbett
From: robert.corbett on 24 Apr 2008 04:59 On Apr 23, 11:35 am, "jamesgi...(a)att.net" <jamesgi...(a)att.net> wrote: > Given that both integer and floating point is getting to need more > than 32-bit values, I don't think it's unlikely at all that 64-bit > defaults would soon be common. Perhaps, but I don't expect 128-bit floating-point hardware to become common any time soon. Physical constraints make fast 128-bit hardware impractical. Hardware implementations of 128-bit floating-point have been done, but they were always much slower than 64-bit floating-point on the same machine. Bob Corbett
From: David Thompson on 5 May 2008 00:10 On Wed, 23 Apr 2008 12:05:30 -0800, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > When computing the national debt of the US, is there any point Assuming national means federal, and AIUI excluding some minor (only billions!) special-purpose and/or off-budget entities ... > in computing it down to the cent, or even dollar? > The nearest million dollars might be possible. > http://www.treasurydirect.gov/NP/BPDLogin?application=np <G!> Semiseriously, BPD (Bureau of the Public Debt) is one of the few significant US Federal departments/agencies to get a 'clean' (unqualified) audit opinion from the GAO (now Government Accountability Office), and they seem to be rather proud of it, in the muted, impersonal, and opaque way large bureaucracies express pride. I think this as-you-imply not-too-meaningful datum is intended to demonstrate that they do have good accounting systems, up to private sector standards or even better, unlike e.g. Defense and Interior and such, who have 'lost' on their books many many billions of assets. (Although accounting valuation of many government assets that are inherently unmarketable and often irreplaceable is a fiction anyway.) <Ob> I have no information if (any of) their accounting systems, and/or web server, are in Fortran, but I'd be rather surprised. - formerly david.thompson1 || achar(64) || worldnet.att.net
From: glen herrmannsfeldt on 5 May 2008 04:28
David Thompson wrote: (snip, I wrote) >> a=bool(b,c,d); >>d is between 0 and 15 to select the appropriate operation. >>(It is converted to a BIT(4) value.) > DEC PDP-10 (and -6) had all 16 bitops (on 36-bit words) in hardware, > with the truth table as four bits in the opcode field. The assembler > mnemonics for the unusual ones were things like "AND with (left) > operand Complemented". (Of course the hardware doesn't know about > mnemonics, it just sees machine code.) I notice the past tense. I presume that PDP-10s still have such instruction. It seems that there are still some real machines running, along with software emulation. There is not a long discussion on alt.sys.pdp10 about getting gcc to run. I haven't asked, but I presume that includes gfortran. Having it as four opcode bits isn't convenient for the BOOL function, though. Unless you want self modifying code, most obvious is an indexed XCT and 16 different instructions. > The -10/6 also had jump and skip instructions with a partly-bit-coded > condition field, somewhat similar to S/360 et seq "Branch Condition" > except that it was based on a new comparison or test rather than a > previously-set condition-code register/field. But S/360 BAL made the > most convenient mnemonic BR x = BC 15,x = branch always; while There is, though, BR 0 which doesn't branch, but runs very slowly on pipelined machines. > MACRO-10 assembled JUMP or SKIP as condition 0 = never = nop; you had > to write JUMPA and SKIPA for Always, versus JUMPE if Equal/zero etc. > (But JUMPA wasn't the preferred way of doing an unconditional jump > anyway; that was JRST = Jump and ReSeT with reset/special = nothing! > And SKIPA wasn't the best unconditional skip either, although in > general unconditional skips are less often needed.) There is some story I don't quite remember, something like the processor where jump doesn't jump and skip doesn't skip. -- glen |