[Info-vax] Roadmap

[Arne Vajhøj]

On 1/7/2019 12:48 PM, gezelter at rlgsc.com wrote:
> 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.

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

That was not my intention.

But I still find it very difficult to understand why a platform
specific qualifier on data types is not an issue for portability.

> 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.
That feature X does not have portability issues because it
is optional to use is definitely not how I interpret "no
portability issues".

> 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.
Sometimes that is needed.

But if solved via platform specific qualifiers it is still
non portable.

And I don't think tying it to the variable declaration
instead of the IO operation is a good design.

> 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.
I assume you mean uint8_t, uint16_t, uint32_t, and uint64_t.

Those are portable because they got in C99.

Arne