[Info-vax] Roadmap

[gezelter at rlgsc.com]

On Sunday, January 6, 2019 at 6:45:04 PM UTC-5, Arne Vajhøj wrote:
> On 1/6/2019 5:15 PM, gezelter at rlgsc.com wrote:
> > On Sunday, January 6, 2019 at 12:16:48 PM UTC-5, Arne Vajhøj wrote:
> >> On 1/6/2019 11:16 AM, gezelter at rlgsc.com wrote:
> >>> 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.
> >>
> >> It would also make the code non-portable.
> >>
> >> Probably not a problem for Basic, Pascal etc..
> >>
> >> But for C, Fortran etc. then I see it as a problem.
> 
> > Having written a large amount of portable code over the years, I can
> > assure you that portability (to different platforms) is not an issue
> > in these cases.
> Really?
> 
> John Reagan introduces IEEE754 keyword in VMS Fortran,
> I write a program that use it, I move that program to Linux
> and tries to compile it. What happens?
> 
> > However, the need that I noted is very common. Data compatibility is
> > frequently needed, and data morphing is a common need.
> The need to read and write foreign formats is common. VMS also
> has some support for it.
> 
> The solution you provided is not common.
> 
> > In some languages (e.g., C/C++) the portability issue can be handled with lexical macros.
> 
> It is often possible to make C/C++ code "portable" by adding a number of
> #ifdef/#define.
> 
> Quotation marks on "portable" on purpose.
> 
> Arne

Arne,

With all due respect, I believe that what I wrote was misconstrued.

First, I was not in any way proposing that REAL*8 (representation controlled by compiler switch) be replaced by IEEE REAL*8 or IEEE SINGLE. Nothing I proposed is mandatory. Thus, if ones goal is to write portable code, there is nothing to obstruct.

However, in some cases, a program compiled with IEEE floating point may need to access a binary file or a memory-resident data structure with a VAX floating point representation. It is for this reason that I proposed adding the OpenVMS-specific optional qualifier.

I recall a discussion with the Oracle team that various databases stored floating point data in VAX F format for historical and compatibility reasons. When constructing software libraries, it is not unusual to find mismatches in floating formats. The include files used to describe structures and parameter lists would benefit from such extensions. If the library is multi-platform, such modifications in the platform-specific bindings would often be transparent to the application programmer (at least outside of the debugger).

This is not just a floating point issue. In C, there was a long standing challenge with 16/32/64 bit interpretations of the keyword "long". Try specifying a fixed length data structure (e.g., 32 bits) when the header file will be used by different processors with different default word lengths. The solution was a new set of specifiable types, uint8, uint16, uint32, and uint64 which are guaranteed to be unsigned integers of the specified length, regardless of the native word size of the processor.

What I proposed is essentially the same concept, needed in certain circumstances to accomplish certain purposes.

- Bob Gezelter, http://www.rlgsc.com