size of a derived type containing pointers...
in [Fortran]
|
Prev: calling a recursive function in fortran 77 ?
Next: equivalent in fortran of the IDL "where" function
From: Tim Prince on 26 Mar 2010 09:49 On 3/26/2010 12:26 AM, glen herrmannsfeldt wrote: > Richard Maine<nospam(a)see.signature> wrote: >> <robert.corbett(a)sun.com> wrote: > >>> One bit of >>> nastiness regarding numeric sequence types is that the >>> standards require them to be laid out in ways that can >>> violate some machines' data alignment requirements. > >> That kind of issue isn't new to numeric sequence types either. Common >> has had that issue for a long time, notably with double precision, which >> can end up misaligned. > > I haven't heard about this one recently, so I thought that > the standard may have changed. What's different from previous decades is the widespread availability of CPUs with hardware fixup for mis-aligned data, and compilers which try to fix up alignments at run time. The machines I learned on (GE6xx/H6xxx) simply took the data from the next lower aligned address. No address fault, but not the data you might have expected. The machines persisted into the f77 era, but I never saw a production f77 or C compiler. > > As for newer machines, most RISC processors require data to > be appropriately aligned. IA32 does not, but does indicate > that aligned data will likely run faster. This will come around again next year with the introduction of hardware support for 256-bit parallel operations. -- Tim Prince
From: Tim Prince on 26 Mar 2010 09:55 On 3/26/2010 12:15 AM, robert.corbett(a)sun.com wrote: > On Mar 25, 11:57 pm, nos...(a)see.signature (Richard Maine) wrote: >> <robert.corb...(a)sun.com> wrote: > >> And if one allows f77 compilers, then lots of them didn't have LOC, >> paticularly if one looks for that exact spelling. > > Yes, I can think of a few Fortran vendors in this area who > went out of business refusing to support the nonstandard > extensions their customers wanted. > Why would any compiler have introduced LOC in recent years, when the standard spells it c_loc() ? The question now is whether customers will demand the warnings for non-standard usage. -- Tim Prince
From: Phred Phungus on 28 Mar 2010 00:44 Paul Thomas wrote: [nothing too precious in the context] > gfortran --version $ gfortran --version GNU Fortran (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ This surprises me, because I thought my OS had told me before that it was done with 4.3, but I find many such erroneous moments as a person in his first year with linux. So I go to the gfortran page to see what one does here to modernize. # Download the GFortran binary # Go into directory under which you want to put GFortran # Unpack the package using tar xvfz gcc-trunk-x86_64.tar.gz, which unpacks it into the directory gcc-trunk. This sounds easy, and I'm sure it is for persons who have done it before. The links to the latest builds did not fire for me, and so one is left to find one thing there but is faced with many choices that look very similar. http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ I can't tell what's C here and what's Fortran. Of course, I would put the binary in /usr/bin I currently have no directory called gcc-trunk. I have one question before I create it: they talk about a trunk over in gcc development as well. Is the process I do here with gfortran going to conflict with the same process, if done with gcc? Also, why isn't it called gfortran-trunk? Thanks for your comment, and cheers, -- fred
From: Richard Maine on 28 Mar 2010 02:49 Phred Phungus <Phred(a)example.invalid> wrote: > What I don't get is that I thought that Nag was still commercially > viable. It is. That was sort of the point - to cite it as a counterexample to Bob's suggestion that an implementation without LOC would not be viable. NAG has sold f90/f95 compilers for longer than any other vendor. One can (and people do, but I won't) debate things such as the speed of executables, but that's not the main definition of commercial viability. Nag does sell compilers. I'm not privy to sales information, but I know that people make their living from its sales. That pretty much does define commercial viability. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Phred Phungus on 28 Mar 2010 03:48
Richard Maine wrote: > Phred Phungus <Phred(a)example.invalid> wrote: > >> What I don't get is that I thought that Nag was still commercially >> viable. > > It is. That was sort of the point - to cite it as a counterexample to > Bob's suggestion that an implementation without LOC would not be viable. > NAG has sold f90/f95 compilers for longer than any other vendor. One can > (and people do, but I won't) debate things such as the speed of > executables, but that's not the main definition of commercial viability. > Nag does sell compilers. I'm not privy to sales information, but I know > that people make their living from its sales. That pretty much does > define commercial viability. > Doesn't the C from MR&C work there? I've heard you talk of Malcolm as an innovator of particular prodigousness. -- fred |