[Info-vax] Roadmap

[gezelter at rlgsc.com]

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