> Date: Tue, 30 Mar 2004 23:58:55 -0500 (EST)
> From: [log in to unmask]
> In a message dated 3/9/04 4:13:05 PM, [log in to unmask] writes:
>
> >In the huge majority of existing codes, people don't start out by asking
> >for a precision of p and a range of r. Instead, they ask for 32-bit
> >or 64-bit reals and then have to translate their request into the
> >standard's terms. I find selected_real_kind(12,30) to be a pretty
> >verbose and nonintuitive spelling of 64-bit real. It is clear to
> >me that so do a lot of other people. But 64-bit reals are such a common
> >requirement that I think we should provide a simpler way to spell it,
> >even though that spelling will be pretty duplicative of
> >selected_real_kind(12,30). Yes, I know that they don't say exactly the
> >same thing in theory, but they are sure pretty close in practice.
> >
> Those Fortran users that have to deal directly, or even indirectly, with data
> often find Fortran to be very awkward for similar reasons. The Fortran
> standard rightly puts a large emphasis on portability, but that emphasis makes it
> awkward to express key concepts in a form that maps directly to machine
> characteristics. That despite the fact that computer architectures (at least those
> Fortran needs to interface to) have greatly decreased in diversity. For better
> or worse Fortran is not used to program microcontollers.
>
> It would be a great convenience for such users if there were a "standard"
> means of interfacing to a generic binary computer, with two's complement
> integers, byte sized characters, 16, 32, and 64 bit integers and logicals, 32, 64, and
> 128(?)
80 is a common size.
> bit reals with well defined byte orderings, and the ability to
> equivalence the different intrinsic types.
This is currently readily available with REAL and
DOUBLE PRECISION.
If you stick with these, you're pretty safe.
> The byte ordering definitions should allow
> simple mapping to and from big and little endian processors. The natural way
> to express this is with a standard module, say ISO_binary_2scomplement_system.
> The module should be defined so that in principle it can be implemented on
> any processor (albeit at great inefficiency on a signed magnitude base 10
> system), and so the processor can easily report that it does not support the
> capabilities the module is intended to supply, but the capabilities should have a
> simple enough mapping to the types of hardware that Fortran is currently
> available on that vendors would rapidly adopt it.
|