[Info-vax] Roadmap

[John Reagan]

On Sunday, January 6, 2019 at 11:16:49 AM UTC-5, geze... at rlgsc.com wrote:
> On Sunday, January 6, 2019 at 6:56:16 AM UTC-5, geze... at rlgsc.com wrote:
> > On Saturday, January 5, 2019 at 9:19:06 PM UTC-5, Arne Vajhøj wrote:
> > > On 1/5/2019 8:23 PM, Dave Froble wrote:
> > > > On 1/5/2019 1:48 PM, John Reagan wrote:
> > > >>        The format of the REAL_SIZE qualifier is as follows:
> > > >>
> > > >>           /REAL_SIZE={SINGLE}
> > > >>                      {DOUBLE}
> > > >>                      {GFLOAT}
> > > >>                      {SFLOAT}
> > > >>                      {TFLOAT}
> > > >>                      {XFLOAT}
> > > 
> > > >> So Dave's "OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )" which was 
> > > >> originally used to say "I want extra precision on my REALs" locks into 
> > > >> you Dfloat on Itanium.
> > > 
> > > >> What a horrible design decision.  So people who didn't say anything on 
> > > >> Itanium, get fast Sfloat but the moment you want more precision and 
> > > >> blindly say "REAL DOUBLE", you get your extra precision (but no extra 
> > > >> range) and a performance hit.
> > > 
> > > > Maybe the D_FLOAT isn't so bad, if you're not doing a lot of work with it.
> > > 
> > > Basic is probably not a favorite language for number crunchers, so
> > > most likely the practical impact is minimal.
> > > 
> > > It is possible though to create an example showing a difference:
> > > 
> > > $ type dbl.bas
> > >          option type = explicit
> > >          declare long constant n = 10000000
> > >          external long function pas$clock2
> > >          dim real x(n)
> > >          declare long j, i, t1, t2
> > >          t1 = pas$clock2()
> > >          for j = 1 to 10
> > >            x(1) = 1.0
> > >            for i = 2 to n
> > >              x(i) = (x(i - 1) * 2 + 2) / 2
> > >            next i
> > >          next j
> > >          t2 = pas$clock2()
> > >          print using "#### (##########.#)"; (t2 - t1); x(n)
> > >          end
> > > $ bas/real=double dbl
> > > $ lin dbl
> > > $ r dbl
> > > 5810 (  10000000.0)
> > > $ bas/real=tfloat dbl
> > > $ lin dbl
> > > $ r dbl
> > > 3000 (  10000000.0)
> > > 
> > > (forgive me for any basic Basic blunders - it is not a language
> > > I am using)
> > > 
> > > Arne
> > 
> > Arne,
> > 
> > BASIC is still popular in some quarters, where it is used for serious systems. I have had more than a few clients who meet this description.
> > 
> > In many ways, interoperability of one form or another is the most important use of the different formats. Some have historical data files. Some have mixed-architecture OpenVMS clusters. Others exchange binary data with other systems, on the same or different machine, of the same or different organization.
> > 
> > OpenVMS standards also mean that these differences can arise due to different parts of the same software image being written in different languages.
> > 
> > It is thus not a debate of "which is better", but a debate of "which is needed". This situation argues for provision of both defaults (e.g., compiler switches, implicit declarations) and explicit data types, as well as the obvious cross-type conversions.
> > 
> > - Bob Gezelter, http://www.rlgsc.com
> 
> A clarification:
> 
> C/C++ has had long-time challenges with the use of keywords such as "long", "double", etc.
> 
> In the case of floating point, perhaps all (repeat ALL) OpenVMS compilers should support a non-standard keyword "IEEE754" as an adjunct to REAL and DOUBLE. A "C"-ish example would be:
> 
>           IEEE754 float X;
>           IEEE754 double Y;
> 
> in FORTRAN:
> 
>           IEEE754 REAL*4 X;
>           IEEE754 REAL*8 Y;
> 
> This would allow the clarity in documenting mixed representation programs, e.g., programs which read/write one format while working internally in another. Often, such situations are, as I have noted elsewhere, not a voluntary choice. Historical data exists, libraries expect certain formats, etc.
> 
> Doing this consistently across multiple compilers is, I admit, a chore. However, it is also a problem best addressed in a consistent manner, than ad hoc for each different compiler.
> 
> My apologies to John for adding to his work queue.
> 
> - Bob Gezelter, http://www.rlgsc.com

Already done years ago for Pascal.

REAL - single-precision, compiler choice for format
DOUBLE - double-precision, compiler choice for format
QUADRUPLE - quad-preicsion, compiler choice for format
F_FLOAT
S_FLOAT (not on VAX)
D_FLOAT
G_FLOAT
T_FLOAT (not on VAX)
X_FLOAT (not on VAX)
H_FLOAT (VAX only)

and matching %?_FLOAT directives to give an explicit format to floating constants.  It lets you use %F_FLOAT to call LIB$WAIT on OpenVMS Itanium while still using the default of S_FLOAT everywhere else.

And Pascal allows both VAX and IEEE formats to be used in the same routine but you can't let them touch. :)