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: andrej.panjkov on 22 Apr 2008 19:28 Quite a few compilers support different representations for LOGICAL types: 1 byte, 2 byte 4 byte...and 8 byte? What applications are there for 8 byte LOGICAL types? (Or for 2 byte types?) I understand that the default size is often 4 bytes for likely performance reasons (register loads and stores, address alignment). Smaller sizes are useful for packing data, but if space is an issue, why pack logicals into two bytes and not one? Just curious... Andrej
From: FX on 22 Apr 2008 19:34 > Quite a few compilers support different representations for LOGICAL > types: 1 byte, 2 byte 4 byte...and 8 byte? Even 128-bit. -- FX
From: James Van Buskirk on 22 Apr 2008 21:15 <andrej.panjkov(a)climatechange.qld.gov.au> wrote in message news:a8338933-0afe-4e7f-b106-04cb2d84d492(a)a23g2000hsc.googlegroups.com... > Quite a few compilers support different representations for LOGICAL > types: 1 byte, 2 byte 4 byte...and 8 byte? > What applications are there for 8 byte LOGICAL types? (Or for 2 byte > types?) Storage association rules require than a default INTEGER takes up the same space as a default LOGICAL. N1601.pdf, section 16.4.3.1: "In a storage association context (1) A nonpointer scalar object of type default integer, default real, or default logical occupies a single numeric storage unit;" Thus if your default INTEGERs are 4 bytes, then default LOGICAL must also occupy 4 bytes. There is a complication: we are at the cusp of systems growing to the point where your home PC can have more than 4GB of virtual address space. At around this size it's going to be necessary for array bounds and indices to be bigger than 4 byte INTEGERs permits, and it's awkward to modify code throughout to update everything to 8 byte INTEGERs, although f03 provide support if you chose to do so with KIND= optional arguments to array inquiry functions. It's much easier to just recompile so the default INTEGERs are now 8 bytes, but there is the problem that default INTEGERs may be storage associated with other things. If the other things are allowed to grow as well, that's OK. If you don't support 8 byte LOGICALs this is not possible if default INTEGERs are storage associated with default LOGICALs. Of course the big problem is what happens if the default INTEGERs are storage associated with default REALs because you normally have chosen the size of your REALs for good reasons and that's much more difficult to change. For new code it may prove worthwhile to examine which arrays can just grow arbitrarily and define a KIND parameter that can be used for their bounds, indices, and array inquiry results. If this KIND parameter can be switched to 8 byte integers when necessity dictates without any more fuss than changing a single character in a module somewhere, it could make for an easy port to 64-bit code in the future. Of course it has to be tested with big integers right now if the port is to be easy in the future... -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: e p chandler on 23 Apr 2008 00:01 On Apr 22, 9:15 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > <andrej.panj...(a)climatechange.qld.gov.au> wrote in message > > news:a8338933-0afe-4e7f-b106-04cb2d84d492(a)a23g2000hsc.googlegroups.com... > > > Quite a few compilers support different representations for LOGICAL > > types: 1 byte, 2 byte 4 byte...and 8 byte? > > What applications are there for 8 byte LOGICAL types? (Or for 2 byte > > types?) > > Storage association rules require than a default INTEGER takes up > the same space as a default LOGICAL. N1601.pdf, section 16.4.3.1: > > "In a storage association context > (1) A nonpointer scalar object of type default integer, default > real, or default logical occupies a single numeric storage unit;" > > Thus if your default INTEGERs are 4 bytes, then default LOGICAL > must also occupy 4 bytes. There is a complication: we are at the > cusp of systems growing to the point where your home PC can have > more than 4GB of virtual address space. At around this size it's > going to be necessary for array bounds and indices to be bigger > than 4 byte INTEGERs permits, and it's awkward to modify code > throughout to update everything to 8 byte INTEGERs, although f03 > provide support if you chose to do so with KIND= optional arguments > to array inquiry functions. > > It's much easier to just recompile so the default INTEGERs are > now 8 bytes, but there is the problem that default INTEGERs may > be storage associated with other things. If the other things > are allowed to grow as well, that's OK. If you don't support 8 > byte LOGICALs this is not possible if default INTEGERs are storage > associated with default LOGICALs. Of course the big problem > is what happens if the default INTEGERs are storage associated > with default REALs because you normally have chosen the size of > your REALs for good reasons and that's much more difficult to > change. 1. So when the default numeric storage unit is 8 bytes on PCs, what happens to DOUBLE PRECISION? 2. Is it legal to set aside 8 bytes for a REAL but use only 4? 3. Computers with 64 bit words ... we've never had _that_ before, have we? -- e
From: Richard Maine on 23 Apr 2008 00:08
e p chandler <epc8(a)juno.com> wrote: > 2. Is it legal to set aside 8 bytes for a REAL but use only 4? Yes, though that would be a slightly odd choice for reals, which can often use the extra precision. Still, it is definitely legal. Comparable things have been done with various compilers in the past. I don't recall that exact one, but I have seen: Integers that take 4 bytes of storage, but only use 2 of them. Double precision reals that take 128 bytes of storage, but only use 80 of them. Considering the subject of the thread, logicals that take any of several sizes, but only use one bit. And a few other such variants, which have been mentioned here in the past. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain |