equivalencing character*8 and double precision
in [Fortran]
|
From: dpb on 21 Jun 2010 16:25 Lynn McGuire wrote: .... > I would guess that we are closer to running a heap. We are > still on a f77 compiler at this time so we dont have access > to ALLOCATABLE. .... As I noted in the earlier thread in ow ng, the example usages I've seen so far don't show specifically where the EQUIVALENCE becomes important to discern how a substitute structure could work around it. I'll note specific to the above that OW _DOES_ have allocatable arrays; it just doesn't have precisely the Standard implementation. (I presume they either implemented their proposal or another early proposal that wasn't quite what ended up getting adopted.) OW declares them with simply the use of the colon in the dimensions w/o the ALLOCATABLE statement so it is missing, true. But, ALLOCATE/DEALLOCATE (alas, also w/ slightly different syntax than was finally adopted) and the intrinsic ALLOCATED() are in the OW extensions. One could at least, it would seem, be able to explore recasting the app w/ Standard-like if not precisely Standard-conforming syntax as an intermediary step. I considered the earlier construct some but didn't have any other useful comments owing to not seeing enough of the problem to have any trail of bread crumbs to the edge of the forest... :) --
From: mecej4 on 21 Jun 2010 16:35 On 6/21/2010 3:18 PM, Louis Krupp wrote: > On 6/21/2010 1:28 PM, Gordon Sande wrote: >> On 2010-06-21 16:04:50 -0300, Lynn McGuire <lmc(a)winsim.com> said: >> >>>> The real question, then, is: how often is this >>>> non-standards-compliant feature used in your code, how much effort >>>> are you willing to >>>> expend to fix the code, and what is the estimated cost of going >>>> forward without excising this cancer _now_? >>> >>> Extensively. We actually use: >>> >>> structure / type64 / >>> union >>> map >>> character c >>> end map >>> map >>> double precision d >>> end map >>> map >>> integer i >>> integer i_low >>> end map >>> map >>> logical l >>> integer l_low >>> end map >>> map >>> character*8 s >>> end map >>> end union >>> end structure >>> >>> and I was looking for an alternate. We cannot live without >>> this data structure or something functionally equivalent to it. >>> >>> Thanks, >>> Lynn >> FWIW, the OP has been there before: > > http://www.mofeel.net/849-comp-lang-fortran/5853.aspx > > Louis > In one of those exchanges, dating to 2005, OP stated "BTW, it only took me a couple months to move to the structure and we could move away from it in a couple of weeks if we needed to." What happened between 2005 and 2010 that the same feature has acquired the attribute "cannot live without"? -- mecej4
From: Lynn McGuire on 21 Jun 2010 16:54 > In one of those exchanges, dating to 2005, OP stated "BTW, it only took me a couple months to move to the structure and we could move > away from it in a couple of weeks if we needed to." > > What happened between 2005 and 2010 that the same feature has acquired the attribute "cannot live without"? I am thinking about moving us to: COMMON/VDYN/IERR,L8W7K1,VDY(2) EQUIVALENCE (VDY (1), IVDY (1, 1)) EQUIVALENCE (VDY (1), LVDY (1, 1)) double precision VDY integer ivdy (2,2) logical lvdy (2,2) character*8 svdy (2) character*1 cvdy (2,8) equivalence (vdy (1), svdy (1)) equivalence (vdy (1), cvdy (1,1)) But as noted, the equivalence between vdy and svdy appears to be a major extension to only some compilers. I dont want to jump from one compiler extension to another. We are slowly removing the last of the Hollerith code out of our code and have used our type64 ivdy.s extensively as a replacement in our dynamically allocated memory. Thanks, Lynn
From: Lynn McGuire on 21 Jun 2010 17:10 > Back in the good old days, memory was scarce and expensive. > Now, it's cheap. I'd try getting away from the EQUIVALENCE > and just declare 6 or so large arrays of the basic types > you need. dfbk can still work just as it does now. But, > it will effectively "allocate" ncp double words in each of > the large arrays, wasting 5/6th of them. But, so what. I wish ! I have seen us use up to 0.5 GB of allocated space. > This assumes you have good name discipline after calling > dfbk and don't do something like > do i = 1,ncp > ivdy(location+i) = 0 > enddo > as a quick/dirty/lazy way to zero out vdy or lvdy. We would never do that <g> ! Actually, we do have some code such as: do i = 1, ncp ivdy(location+i).i = 0 ivdy(location+i).i_low = 0 end do Thanks, Lynn
From: Lynn McGuire on 21 Jun 2010 17:21
> Back in the good old days, memory was scarce and expensive. > Now, it's cheap. I'd try getting away from the EQUIVALENCE > and just declare 6 or so large arrays of the basic types > you need. dfbk can still work just as it does now. But, > it will effectively "allocate" ncp double words in each of > the large arrays, wasting 5/6th of them. But, so what. On 2nd thought, this would not work since the value location is a return value to a heap location from malloc. If svdy, vdy and ivdy are not the same memory location then one would need a separate location pointer for each memory type. Thanks, Lynn |