Roadmap

[Jan-Erik Söderholm]

Not trying to be negative now on the last day of the year, but...

I thought it was said that the VSI roadmap would have a quartely
update, not? I notice that the current roadmap is form June.

Even just a new copy with the date updated would tell that the
plan is still valid.

[Dave Froble]

I'm guessing they are so busy with the port that other things may not
get their attention. Some info on the progress of the port was posted
recently, and I'd think that was the most important information. After
all, without the port, any roadmap is useless.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Jan-Erik Söderholm]

Den 2018-12-31 kl. 17:40, skrev Dave Froble:
> On 12/31/2018 7:16 AM, Jan-Erik Söderholm wrote:
>> Not trying to be negative now on the last day of the year, but...
>>
>> I thought it was said that the VSI roadmap would have a quartely
>> update, not? I notice that the current roadmap is form June.
>>
>> Even just a new copy with the date updated would tell that the
>> plan is still valid.
>
> I'm guessing they are so busy with the port that other things may not get
> their attention.  Some info on the progress of the port was posted
> recently, and I'd think that was the most important information.  After
> all, without the port, any roadmap is useless.
>

It is not useless when you try to calm a customer
worrying about what is happening with VMS. Showing
that VSI (at least) can produce an updated (even
if it is only the date that changes) helps...

The porting updates might be interesting for *me*,
but my customer could't care less...

[Dave Froble]

And you are entirely correct. This is an issue where VSI has fallen
down. When VSI says they will do something, and then doesn't, it's
reasonable to feel concern. Dotting "I"s and crossing "T"s is
important. Perhaps you should communicate your concerns directly with VSI?

> The porting updates might be interesting for *me*,
> but my customer could't care less...
>

However, if your customer has half a clue, they will come to you for
your view of the future. Since you can then tell them that things are
progressing well, they can gain confidence from your advice. Note that
the customer that doesn't refer to their technical support is most
likely to cause themselves problems.

[clairg...@gmail.com]

We decided that the quarterly updates were a big waste of time. Starting in a few weeks we will be updating the roadmap when there is something new to post or we just need to put a new date/time stamp on what is already there. This has been the plan for a while now but the holidays just in the way.

[geze...@rlgsc.com]

Clair,

On a technical basis, unchanged roadmaps are not a problem for me.

However, on the management/psychology side, updated dates, which show progress on schedule, would be helpful with managers.

Unchanged items are inherently ambiguous. It could be that that the item has not been updated, or it could be that everything is as predicted. It is the ambiguity that causes unease.

Thank you in advance for the updated dates.

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

[Arne Vajhøj]

On 1/1/2019 9:57 AM, geze...@rlgsc.com wrote:
> On Tuesday, January 1, 2019 at 8:14:19 AM UTC-5,

> clair...@vmssoftware.com wrote: We decided that the quarterly updates

> were a big waste of time. Starting in a few weeks we will be updating
> the roadmap when there is something new to post or we just need to
> put a new date/time stamp on what is already there. This has been the
> plan for a while now but the holidays just in the way.

> On a technical basis, unchanged roadmaps are not a problem for me.
>
> However, on the management/psychology side, updated dates, which show
> progress on schedule, would be helpful with managers.
>
> Unchanged items are inherently ambiguous. It could be that that the
> item has not been updated, or it could be that everything is as
> predicted. It is the ambiguity that causes unease.

Perception matters.

I will recommend:
* update fixed day every quarter
* if no real changes to plans then:
- update date
- update a small story about technical progress being made

Arne

[Bill Gunshannon]

Note that these people are also getting inundated by the press,
salesdroids, their peers, conference presentations, etc. It's
not the guaranteed sell some people think it is. I have been
burned by this and, trust me, saying "I told you so" after the
fact brings little if any comfort.

bill

[John Reagan]

I'll stop short of offering Snapchat of me typing in my cubicle.

Here's a 'blog' entry for you New Year's enjoyment.

I've been working on the build of the math RTL. It uses lots of C macros to allow the code to be portable (DPML stands for Digital Portable Math Library after all). On Alpha, the C macros use Alpha instruction builtins. On Itanium, the macros use standard C code but lots of C routines have been replaced with Itanium assemble. For x86, I need to pick pieces from both flavors. I describe it as Mister Potato Head. Im making header changes as well as build file changes. The core algorithms are exactly the same ones on Alpha. Should take just another day or so to get a complete DPML$SHR.EXE

[Dave Froble]

Ayep!

We have this very problem. The two biggest customers, now managed by
the children of the founders, (key point), who are hearing from their
"auditors" (likes of KPMG, Price Waterhouse, et al) they cannot go with
unreliable vendors. Of course, these are the same vendors who got the
companies where they are today.

So, yeah, it can be the little things that make a difference.

If it were me, I'd have a procedure that updated the dates periodically,
monthly, whatever. Can't be that hard.

[Richard Maher]

Cool!

And you added that new/optional parameter to math$random right?

[John Reagan]

I'm not falling for that again... The last time I suggested such a thing, I got schooled in PRNGs.

Seriously, we've been talking about PRNGs, entropy pools, OpenSSL, etc. Having access to the underlying x86 instructions (either as C builtins, new MATH$ entry points, enhanced MATH$ entry points, etc.) will be a part of that.

[Stephen Hoffman]

On 2019-01-02 14:51:01 +0000, John Reagan said:

> Seriously, we've been talking about PRNGs, entropy pools, OpenSSL, etc.
> Having access to the underlying x86 instructions (either as C
> builtins, new MATH$ entry points, enhanced MATH$ entry points, etc.)
> will be a part of that.

One of the referenced instructions:
https://en.wikipedia.org/wiki/RDRAND — feeding that entropy into Yarrow
or Fortuna is likely preferable, though trusting RDRAND will be simpler
to code.

As has been discussed previously, there's LibreSSL/libtls and some
other options in addition to OpenSSL.
http://www.openbsd.org/papers/libtls-fsec-2015/mgp00001.html

Higher-level API and related abstractions are being provided by various
grpoups. Here is one:
https://developer.apple.com/documentation/security/secure_transport
LibreSSL is another.

I'd expect folks many folks would prefer to use a higher-level and a
different abstraction than what the OpenSSL APIs offer, though there is
more than a little existing code that already uses those OpenSSL APIs.


--
Pure Personal Opinion | HoffmanLabs LLC

[geze...@rlgsc.com]

John,

My recommendation would be for an essentially "flat" port, with changes deferred to a later point.

[DeanW]

On Tue, Jan 1, 2019 at 9:15 AM John Reagan via Info-vax <info...@rbnsn.com>
wrote:

> Here's a 'blog' entry for you New Year's enjoyment.
>
> I've been working on the build of the math RTL.

In my previous job, if I had a task and went dark, my customers knew I was
on it and work was forthcoming. In my latest job, where I'm a little more
removed from the customer, I've found that little updates like that mean a
lot to them. They don't care if they understand much of it as long as
there's an indication progress is being made.

ObFunnyProgressIndicator: Another team in my group has an app being brought
in-house (written under contract... which the vendor did with offshore
"talent") with a progress bar. They thought it odd that it always got hung
up at about the same place no matter what the task was and decided to dig a
little.

Turns out basically initiating a progress bar makes it spin itself up to
72%; turning it off makes it finish the progress up to 100% before going
away.

[Dave Froble]

Well, yeah ....

We fools that build homebuilt experimental aircraft have a term for such.

90% done, 90% to go ....

Tasks usually work out best if sticking to the design goals, and
avoiding requirement creep. It can go on forever.

The other side of the argument is, "it will be easiest to do it right
the first time". Never black or white, always gray.

[Bill Gunshannon]

On 1/3/19 12:29 PM, Dave Froble wrote:
>
> Tasks usually work out best if sticking to the design goals, and
> avoiding requirement creep.  It can go on forever.

That's not what the Agile experts tell us.

Sorry, just couldn't resist.... :-)


bill

[Dave Froble]

Well, I guess that there can even be "experts" at being fools ...

[Simon Clubley]

The problem with that is that while it can apply to much of VMS,
security is an ever changing goal and VMS needs various things
to be fixed as soon as possible.

I would also hope VSI isn't exclusively using the Intel hardware
generator by default for security critical functionality.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Craig A. Berry]

On 1/3/19 12:32 PM, Simon Clubley wrote:
> On 2019-01-03, geze...@rlgsc.com <geze...@rlgsc.com> wrote:
>> On Wednesday, January 2, 2019 at 9:51:03 AM UTC-5, John Reagan wrote:
>>> On Tuesday, January 1, 2019 at 8:26:51 PM UTC-5, Richard Maher wrote:
>>>>
>>>> And you added that new/optional parameter to math$random right?
>>>
>>> I'm not falling for that again... The last time I suggested such a thing, I got schooled in PRNGs.
>>>
>>> Seriously, we've been talking about PRNGs, entropy pools, OpenSSL, etc. Having access to the underlying x86 instructions (either as C builtins, new MATH$ entry points, enhanced MATH$ entry points, etc.) will be a part of that.
>>
>> John,
>>
>> My recommendation would be for an essentially "flat" port, with changes deferred to a later point.
>>
>
> The problem with that is that while it can apply to much of VMS,
> security is an ever changing goal and VMS needs various things
> to be fixed as soon as possible.
>
> I would also hope VSI isn't exclusively using the Intel hardware
> generator by default for security critical functionality.

There are also cases where staying flat means writing a lot of code for
a different platform. Long doubles might be one of those cases. If
they stay with T_FLOAT (which I suspect they will for compatibility),
they can't necessarily just use the same software emulation they had for
Alpha (maybe, if it was written in C, but obviously not if it was Alpha
assembler). Compiler switches that make optionally available the 80-bit
long doubles more familiar to x86 users might be nice, but that would be
front-end changes they're unlikely to have time for now.

[geze...@rlgsc.com]

Simon,

Just to be clear: My reference to "flat" was not a long-term recommendation, but a short-term tactic for the initial boot/EAK.

Long-term, there is no shortage of things to be done. However, none of them should detract from the short-term goal of First Boot/EAK.

[Dave Froble]

There is also the concept of being exactly the same, for testing to see
if anything was broke.

As for Simon's concerns, if the possibilities were port with no security
enhancements, or, no port at all, it might be interesting to see his
preference. Me, I think the priority is the port, over anything else.
But what do I know?

[John Reagan]

On Thursday, January 3, 2019 at 2:45:30 PM UTC-5, Craig A. Berry wrote:
> On 1/3/19 12:32 PM, Simon Clubley wrote:

Ugh, "long double"... We had yet another discussion about that today.

The 128-bit support we have is written mostly in C but GEM knows it and does some operations inline. clang/LLVM can do the "leave a 128-bit hole but put an 80-bit float in it" just fine. If we want to retain our full 128-bit floating, we would just deal with it like we do with COBOL packed decimal (ie, call RTL routines for every operation) but we would need additional RTL routines. Or use T_FLOAT in a 64-bit hole (our current behavior for the C cross-compiler) or T_FLOAT in a 128-bit hole or ...

Fortunately it isn't needed for first boot and later clang/LLVMs have better support. We'll probably wait until we bootstrap native to make a final decision.

And would we need some support to convert the 128-bit binary format into the 80-bit format in CVT$CONVERT_FLOAT and CVT$FTOF routines?

If somebody has a strong opinion, write it on the back of a $100 bill and send it to me.

[John Reagan]

I just checked and even for a simple add, GEM calls OTS$ADD_X on Itanium (part of LIBOTS, not LIBRTL). I also got Pascal/GEM to call MATH$SIN_X, MATH$SQRT_X, etc. on Itanium and they work fine.

[Stephen Hoffman]

On 2019-01-03 22:35:55 +0000, John Reagan said:

> I just checked and even for a simple add, GEM calls OTS$ADD_X on
> Itanium (part of LIBOTS, not LIBRTL). I also got Pascal/GEM to call
> MATH$SIN_X, MATH$SQRT_X, etc. on Itanium and they work fine.

OpenSSL has some multiple-precision math support, as do various BSD-
and MIT-licensed libraries.

No shortage of tooling, some of which has compatible licensing. But
you've undoubtedly seen all this.

https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software

Some folks are going to want IEEE quad and __float128, but how many and
how soon? Donno. Extended-precision support has long been a hole on
OpenVMS, excludiing the admittedly ugly approach of string math.

[Arne Vajhøj]

On 1/3/2019 2:45 PM, Craig A. Berry wrote:
> There are also cases where staying flat means writing a lot of code for
> a different platform.  Long doubles might be one of those cases.  If
> they stay with T_FLOAT (which I suspect they will for compatibility),

????

T-float is double.

Do you mean X-float?

> they can't necessarily just use the same software emulation they had for
> Alpha (maybe, if it was written in C, but obviously not if it was Alpha
> assembler).  Compiler switches that make optionally available the 80-bit
> long doubles more familiar to x86 users might be nice, but that would be
> front-end changes they're unlikely to have time for now.

????

x86 use 80 bit for calculations.

But x86-64 does not (I believe technically they are only deprecated in
user mode and prohibited in kernel mode).

And VMS will only support x86-64.

Arne

[Arne Vajhøj]

On 1/3/2019 3:44 PM, Dave Froble wrote:
> On 1/3/2019 3:11 PM, geze...@rlgsc.com wrote:
>> On Thursday, January 3, 2019 at 1:32:43 PM UTC-5, Simon Clubley wrote:
>>> On 2019-01-03, geze...@rlgsc.com <geze...@rlgsc.com> wrote:
>>>> My recommendation would be for an essentially "flat" port, with
>>>> changes deferred to a later point.
>>>>
>>>
>>> The problem with that is that while it can apply to much of VMS,
>>> security is an ever changing goal and VMS needs various things
>>> to be fixed as soon as possible.
>>>
>>> I would also hope VSI isn't exclusively using the Intel hardware
>>> generator by default for security critical functionality.

>> Just to be clear: My reference to "flat" was not a long-term
>> recommendation, but a short-term tactic for the initial boot/EAK.
>>
>> Long-term, there is no shortage of things to be done. However, none of
>> them should detract from the short-term goal of First Boot/EAK.

> As for Simon's concerns, if the possibilities were port with no security
> enhancements, or, no port at all, it might be interesting to see his
> preference.  Me, I think the priority is the port, over anything else.
> But what do I know?

There are lots of security enhancements to be made.

But security is not the only area that need enhancements.

And VSI need to get the x86-64 version out to survive financially.

So prioritization need to be made.

I think VSI need to got for the low hanging fruits in the
security area for the first releases and postpone the
more tricky ones to later.

Otherwise they will not make it.

They should focus on what:
* is easy to fix without triggers change all over VMS
* is noted a problems by customers in their security audits

Arne

[Craig A. Berry]

On 1/3/19 7:27 PM, Arne Vajhøj wrote:
> On 1/3/2019 2:45 PM, Craig A. Berry wrote:
>> There are also cases where staying flat means writing a lot of code for
>> a different platform.  Long doubles might be one of those cases.  If
>> they stay with T_FLOAT (which I suspect they will for compatibility),
>
> ????
>
> T-float is double.
>
> Do you mean X-float?

Yes, my mistake, I did mean X_FLOAT. H_FLOAT was also 128-bit double but
I think that died with the VAX.

[Bob Koehler]

In article <q0mfpv$mqc$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:
>
> Yes, my mistake, I did mean X_FLOAT. H_FLOAT was also 128-bit double but
> I think that died with the VAX.
>

IIRC, Alpha supported all the VAX floating point formats, plus the
IEEE, except that IEEE 128 bit wasn't actually implemented in
hardware. Or at least not in EV4.

Or did they do the same to H_FLOAT?

[Phillip Helbig (undress to reply)]

In article <nxgT6CmNy+$X...@eisner.encompasserve.org>,

koe...@eisner.nospam.decuserve.org (Bob Koehler) writes:

> IIRC, Alpha supported all the VAX floating point formats, plus the
> IEEE, except that IEEE 128 bit wasn't actually implemented in
> hardware. Or at least not in EV4.

I believe that there were two 64-bit floating-point types on VAX, but
only one was really supported on ALPHA. The other could be read and
written, but internally was converted to the other type and back.

From HELP FORTRAN:

OpenVMS VAX systems support D_floating and
G_floating implementations of the DOUBLE
PRECISION (REAL(KIND=8)) data type in memory.
OpenVMS Alpha systems can store REAL(KIND=8)
floating-point data in memory in D_floating,
G_floating, or T_floating format.

Because the Alpha instruction set does not
support D_floating computations, D_floating data
is converted to G_floating format for arithmetic
computations and then converted back to
D_floating format. For programs that perform
many REAL(KIND=8) computations, using D_floating
data is slower than using G_floating or
T_floating data and the results will differ from
VAX D_floating computations and results.

Unless a program uses unformatted data files in
D_floating format, do not use the /FLOAT=D_FLOAT
option. If range and accuracy constraints do not
disallow the use of the other REAL(KIND=8) data
types, consider converting existing unformatted
files that contain D_floating data to another
format, such as G_floating, T_floating, or
X_floating to optimize performance. (For more
information, see your user manual.)

[John Reagan]

No software support for H on Alpha, only X. As Phillip just mentioned, only D was to convert to/from G. [VEST did support H for translated VAX images]

On Itanium, F converts to IEEE S for operations and back to F. D/G convert to IEEE T and back to F. Software support for X.

On Itanium, the default switched to IEEE floating and almost nobody noticed. Anybody here have to use /FLOAT=G on Itanium?

[Dave Froble]

Well, just to be contrary, we still use D-float on the itanic ....

I think ....

[John Reagan]

D_float?!? Ugh. The DtoT sequence is the longest. Depending on your floating operations, it could be 10x slower than just using native T_float.

Why use D? Do you have binary data you are using?

[Craig A. Berry]

On 1/4/19 1:01 PM, John Reagan wrote:

> On Itanium, F converts to IEEE S for operations and back to F. D/G convert to IEEE T and back to F. Software support for X.

Really? I thought the only good thing about Itanium was its native
support for IEEE 128-bit floating point.

> On Itanium, the default switched to IEEE floating and almost nobody noticed. Anybody here have to use /FLOAT=G on Itanium?

We had to do BASIC/REAL_SIZE=SINGLE, which I believe gives you F_FLOAT
rather than S_FLOAT. I forget what broke; possibly we could have
avoided this with a data conversion effort, but floating point was very
rare in the applications, which mostly used decimal, so it didn't seem
worth the effort.

[Dave Froble]

On 1/4/2019 10:40 PM, John Reagan wrote:
> D_float?!? Ugh. The DtoT sequence is the longest. Depending on your floating operations, it could be 10x slower than just using native T_float.
>
> Why use D? Do you have binary data you are using?
>

We use Basic ...

OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )

As far as I know, the above used D_FLOAT.

We have historical data files, with data from VAX, Alpha, and itanic.
We never have done any conversions, and so I'm assuming that we're still
using D_FLOAT, or, we've been screwed up for years ....

[John Reagan]

Ok, so I just learned something else that I think BASIC does wrong.

The default for /REAL_SIZE is essentially "give me the best single-precision format for this platform". F on VAX and Alpha, S on Itanium.

The confusion is that the qualifier is used to provide BOTH the size of a real (single precision vs double precision) AND the format.

I assumed that if you explicitly say /REAL_SIZE=SINGLE, it would mean the same as the default, namely I want REALs to be single-precision, compiler's choice on best format.

I also assumed that if you explicitly say /REAL_SIZE=DOUBLE (or the equivalent OPTION SIZE directive), you would get "I want REALs to be double-precision, compiler's choice on the best format".

Alas, nope.

The HELP file was the first hint that I was wrong.

The format of the REAL_SIZE qualifier is as follows:

/REAL_SIZE={SINGLE}
{DOUBLE}
{GFLOAT}
{SFLOAT}
{TFLOAT}
{XFLOAT}

I said to myself, "where are the explicit FFLOAT or DFLOAT keywords?"

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.

Another item for my "time machine" list.

[Dave Froble]

Probably would be good to have keywords for all supported real data
types. Defaults can be so annoying.

> 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.

There was a time in the past that D_FLOAT was the only 8 byte real.
Then things got "interesting".

> 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.
>
> Another item for my "time machine" list.
>

Surprised ??

VAX Basic used D_FLOAT for 8 byte real. As you may have noticed, Basic
hasn't gotten a lot of attention through the years. Part of that means
that architecture changed, but the floating point types did not. Not a
really bad thing, since older data files, historical stuff, is in the
formats available when the data was written.

If users were to embrace different floating point format(s), there would
be rather significant work in going back to convert data fields in
historical data files. Frankly, that would be a lot of work, for no
return value.

I don't know when /REAL_SIZE was introduced. For lo these many years,
I've been using REAL DOUBLE. Did I mention I don't get out much, or
read release notes?

:-)

Horror story: 2011 files with one format, 2012 files with another, 2013
files with another, ..............

Maybe the D_FLOAT isn't so bad, if you're not doing a lot of work with it.

[Arne Vajhøj]

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}
>>
>> I said to myself, "where are the explicit FFLOAT or DFLOAT keywords?"
>
> Probably would be good to have keywords for all supported real data
> types.  Defaults can be so annoying.
>
>> 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.
>
> There was a time in the past that D_FLOAT was the only 8 byte real. Then
> things got "interesting".

PDP-11 ?

I believe all VAX had both D and G.

Arne

[Arne Vajhøj]

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

[geze...@rlgsc.com]

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.

[geze...@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.

[Arne Vajhøj]

On 1/6/2019 11:16 AM, geze...@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.

Arne

[Arne Vajhøj]

On 1/6/2019 6:56 AM, geze...@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:
>>> 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:

> 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.

I am sure.

But I would expect most of them to be in the business domain
not in the number crunching domain.

> 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.

Of course. But that is more IO than calculation.

And then it does not matter.

Arne

[John Reagan]

All the compilers got attention when moving to GEM/Alpha. We had joint meetings with people from all the frontends. I thought the plan was "F/D/H" on VAX and "F/G/X" on Alpha as the defaults. BASIC incorrectly pushed D_float back on your on Alpha instead of G.

As already pointed out, unless you are dealing with existing binary data, the vast majority of programs won't notice the "D" to "G" difference or even the "F/S" and "G/T" difference. D on Alpha is slightly worse than G but not by much. You don't get full D since there aren't enough mantissa bits.

[John Reagan]

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. :)

[Dave Froble]

This issue has two main parts.

1) data in memory
2) data stored in files

The types of floating point numbers supported on different HW might
cause one to pick the most efficient for calculations, and that has
changed, as HW has changed. One can determine if any performance hit is
meaningful, and plan accordingly.

As for data stored in files, it's a different problem. The issue is
whether one can accurately retrieve data.

One solution might be some type of identifier for each piece of floating
point data, which would be respected by whatever code moved data from
file to memory, and back. I'd expect some type of performance hit from
such a scheme.

Pick only one of two, performance or accuracy ....

:-)

Perhaps the /REAL_SIZE should be /REAL_TYPE ?

[Dave Froble]

Maybe the D_FLOAT was retained because many depended upon it?

The problem is, we do have "existing binary data". In business, one
does not use numbers to crunch some data, numbers are used to save data
for later retrieval. Performance usually is not an issue.

In Basic, if floating point is stored in string format, the CVTF$() and
CVT$F() functions are used for the conversion. I have to wonder if
these functions respect data types, or, are only D_FLOAT and perhaps
S_FLOAT (which we just don't use). One more item in the issue, huh?

Blame it all on RSTS, that's where it came from ..

:-)

[Phillip Helbig (undress to reply)]

In article <q0tseg$srm$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> In business, one
> does not use numbers to crunch some data, numbers are used to save data
> for later retrieval.

Depends on the business.

> Performance usually is not an issue.

In some businesses, it is a very big issue.

[geze...@rlgsc.com]

Arne,

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.

However, the need that I noted is very common. Data compatibility is frequently needed, and data morphing is a common need.

In some languages (e.g., C/C++) the portability issue can be handled with lexical macros.

[John Reagan]

On Sunday, January 6, 2019 at 4:37:21 PM UTC-5, Dave Froble wrote:

>
> Maybe the D_FLOAT was retained because many depended upon it?
>

Perhaps, but that was trashed on Itanium where the default went from F to S. If binary compatibility for BASIC was important, I would have expected single to say as F as well as double saying with D.

/REAL_SIZE evolved from /SINGLE and /DOUBLE which control what whether floating was single precision or double precision.

I'd love to change it but BASIC is so VMS-specific, that is a place where tree-hugging isn't a problem. (Although, you might argue that all the CLASS_D descriptors should turn into 64-bit variants).

I'm not going to suggesting anything now, just getting a feel for the continue use (intentional and accidental) of VAX floating formats.

[Craig A. Berry]

Maybe so, but the non-portable types should really not use language
keywords like float, double, and REAL. Go ahead and call them by their
VMS names if you're going to implement non-portable types.

[Arne Vajhøj]

On 1/6/2019 5:15 PM, geze...@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, geze...@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 Vajhøj]

I would expect the number of business applications where
floating point calculation performance is important to
be pretty small.

At least if we exclude analytics from being a business
application.

Arne

[Simon Clubley]

On 2019-01-06, Dave Froble <da...@tsoft-inc.com> wrote:
>
> Pick only one of two, performance or accuracy ....
>

Does VMS Basic support fixed point ?

(I've never used VMS Basic, so I don't know the answer).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Arne Vajhøj]

On 1/6/2019 7:57 PM, Simon Clubley wrote:
> On 2019-01-06, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> Pick only one of two, performance or accuracy ....
>>
>
> Does VMS Basic support fixed point ?
>
> (I've never used VMS Basic, so I don't know the answer).

VMS Basic has a DECIMAL type that is BCD.

Good for business usage.

Arne

[Dave Froble]

On 1/6/2019 4:46 PM, Phillip Helbig (undress to reply) wrote:

One can always declare the variables whatever one wants in the programs.
If no storage of the data is involved, then format doesn't really
matter. Use what is best.

But if you have historical data for the past 20 years, it won't be in
T_FLOAT.

Or one could fork the programs, having a copy for each type of data, or
differentiate inside a single program. Then again, if you have 50+
programs using the data, well, the job does seem to grow to perhaps
unmanageable proportions.

I don't see any easy answers.

[Dave Froble]

On 1/6/2019 7:57 PM, Simon Clubley wrote:

> On 2019-01-06, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> Pick only one of two, performance or accuracy ....
>>
>
> Does VMS Basic support fixed point ?
>
> (I've never used VMS Basic, so I don't know the answer).
>
> Simon.
>

Please define "fixed-point".

DECIMAL is supported.

There can be user defined data types. Perhaps not with compiler
support, but with support provided by library routines.

Ok, no laughing, or I'll feel hurt. There is a large amount of this in
our app storage.

This is from RSTS days.

100 !************************************************************
! Map Real Number into DI String
!************************************************************
!
FUNCTION STRING DIIN( Z , Z% , ERROR% )
!
! Z - Real value
! Z% - Scale factor
! ERROR% - Completion status
!
! DIIN ret val - DI mapped string
!
!************************************************************
!
OPTION SIZE=( INTEGER WORD , REAL DOUBLE )

200 ON ERROR GOTO 900 ! Error trapping
ERROR% = 0% ! Clear error flag
Z0 = Z * 10^Z% + SGN(Z)*.500001 ! Scale to an
integer
Z1% = Z0 / 32768. ! High word value
Z2% = Z0 - 32768.*Z1% ! Low word value
DIIN = CVT%$(Z1%) + CVT%$(Z2%) ! Map into string
GOTO 999 ! Exit
!
900 ERROR% = ERR ! Set error flag
DIIN = STRING$(4%,0%) ! Set no value
RESUME 999 ! Exit
!
999 END FUNCTION

100 !************************************************************
! Un-map DI String to a real number
!************************************************************
!
FUNCTION DOUBLE DIOUT( Z$ , Z% )
!
! Z$ - DI mapped string
! Z% - Scale factor
!
! DIOUT - Real value
!
!************************************************************
!
OPTION SIZE=( INTEGER WORD , REAL DOUBLE )

200 Z = 32768. * CVT$%(Z$) + CVT$%(MID(Z$,3%,2%)) ! Unmap string
GOTO 300 UNLESS Z% ! Exit if not
scaled
Z = Z / 10.^Z% ! Scale value
CALL NROUND( Z , Z% ) ! Round value
!
300 DIOUT = Z ! Set Fn value
!
999 END FUNCTION

[Simon Clubley]

On 2019-01-06, Dave Froble <da...@tsoft-inc.com> wrote:
> On 1/6/2019 7:57 PM, Simon Clubley wrote:
>> On 2019-01-06, Dave Froble <da...@tsoft-inc.com> wrote:
>>>
>>> Pick only one of two, performance or accuracy ....
>>>
>>
>> Does VMS Basic support fixed point ?
>>
>> (I've never used VMS Basic, so I don't know the answer).
>>
>

> Please define "fixed-point".
>
> DECIMAL is supported.
>

In this case that is the answer because I was looking to see if
VMS Basic had a way to store non-integer values without having to
use an approximation for the value so, with the decimal data type
support, the answer is yes.

[John Reagan]

Yes. Floating in BASIC is in the minority vs DECIMAL. You see the same thing in COBOL where you have to out of your way to get true floating vs packed decimal.

I'm still shocked that we didn't seem to get this right since we had official language-wide meetings to discuss things like this, aligned record layouts, etc. when we all ported from our VAX-specific backends to GEM Alpha. And that it has taken this long for me to spot it. I'm afraid to look more.... :)

[Stephen Hoffman]

On 2019-01-06 01:31:20 +0000, Arne Vajh j said:

> I believe all VAX had both D and G.

That belief is only approximately correct.

There were a few VAX configurations that supported D_Floating or
G_Floating in hardware, but not both.

q.v. VAXCRTLG and the other lingering fallout of the MicroVAX I
hardware floating point implementation.


--
Pure Personal Opinion | HoffmanLabs LLC

[geze...@rlgsc.com]

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.

[Arne Vajhøj]

On 1/7/2019 11:59 AM, Stephen Hoffman wrote:
> On 2019-01-06 01:31:20 +0000, Arne Vajh j said:
>> I believe all VAX had both D and G.
>
> That belief is only approximately correct.
>
> There were a few VAX configurations that supported D_Floating or
> G_Floating in hardware, but not both.
>
> q.v. VAXCRTLG and the other lingering fallout of the MicroVAX I hardware
> floating point implementation.

I thought all VAX supported G instructions.

Most in true HW but some (7xx if I remember correct) in emulation.
(similar to H and other stuff in some later models).

Of course the difference in the OS emulating instructions
via some code and the compiler generating calls to similar
code can be considered a technicality.

Arne

[Stephen Hoffman]

On 2019-01-06 21:22:26 +0000, Dave Froble said:

> As for data stored in files, it's a different problem. The issue is
> whether one can accurately retrieve data.
>
> One solution might be some type of identifier for each piece of
> floating point data, which would be respected by whatever code moved
> data from file to memory, and back. I'd expect some type of
> performance hit from such a scheme.

That's heading closer to object storage. On OpenVMS, a descriptor
might be chosen, given the lack of support for objects. There are
descriptors for different sorts of data, beyond the ASCII-oriented
string "fun" that can be familiar to OpenVMS developers. And yes,
there's overhead involved here in the serialization and
deserialization. There are various factors obviously lurking, around
frequency of access and performance requirements and storage and... all
the usual sorts of design and implementation trade-offs.

json, yaml, xml, tlv or csv file storage would be typical text archival
and transportable formats in recent years, or—depending on what the
particular requirements might be—a text file of SQL or database-related
commands, and where the overhead of an HDD I/O request can mask a whole
lot of overhead from serialization/marshalling/export related
text-binary conversion processing.

I'd steer away from tlv and definitely away from csv, but those can work.

And it's not just tagging floating point here, as integer sizes and
character encoding defaults and languages can vary. OpenVMS and most
apps just don't use or don't consider UTF-8 encoding, and similarly
don't often consider language-specific sorting and related "fun".

Marshalling and unmarshalling APIs are commonly available on various
(other) platforms. Some with opaque storage, some with transportable
storage, some with both.

This whole area can also be quite problematic around security too,
particularly whenever untrusted data is being
deserialized/imported/unmarshalled. Simon's CVE is far from the only
example of security bugs secondary to parsing errors or incautiousness.

Where performance is a factor, binary storage formats are usually
preferable. But that's usually part of the database, and not part of
the archival processing. SQLite is handy here for some cases too, as
the database format is transportable across platforms.

[Bob Koehler]

In article <8e34e423-4b9d-4a1d...@googlegroups.com>, geze...@rlgsc.com writes:
>
> However, in some cases, a program compiled with IEEE floating point may nee=
> d to access a binary file or a memory-resident data structure with a VAX fl=
> oating point representation. It is for this reason that I proposed adding t=
> he OpenVMS-specific optional qualifier.
>

Or write in Fortran, where the I/O subsystem will convert on the fly,
even to/from formats only supported by hardware VMS never ran on.

[Dave Froble]

On 1/7/2019 1:19 PM, Stephen Hoffman wrote:
> On 2019-01-06 21:22:26 +0000, Dave Froble said:
>
>> As for data stored in files, it's a different problem. The issue is
>> whether one can accurately retrieve data.
>>
>> One solution might be some type of identifier for each piece of
>> floating point data, which would be respected by whatever code moved
>> data from file to memory, and back. I'd expect some type of
>> performance hit from such a scheme.
>
> That's heading closer to object storage. On OpenVMS, a descriptor might
> be chosen, given the lack of support for objects.

Thank you for that idea. It's one I didn't think of.

Regardless, it doesn't seem to solve the issue of binary data on storage
devices. Unless the descriptor was included in the storage.

I'm not sure how much of a problem this is. For me, there isn't much,
(but that's not none), storage of real numbers. But for when there is,
I don't see any easy solutions. By now, somebody somewhere has written
new code to look at archived binary data, and gotten erroneous data.
Then the question becomes, do they even know they are working with bogus
data?

No easy solutions, and I'm not sure there are even hard solutions for
data that is already stored.

[John Reagan]

I was avoiding mentioning this feature since it involves DFOR$ "feature logicals" :)

SORT /KEY knows the floating types as well (F/D/G/S/T but not X for some reason) on Alpha and Itanium.

[Stephen Hoffman]

On 2019-01-07 19:28:22 +0000, Dave Froble said:

> On 1/7/2019 1:19 PM, Stephen Hoffman wrote:
>>
>> That's heading closer to object storage. On OpenVMS, a descriptor
>> might be chosen, given the lack of support for objects.
>
> Thank you for that idea. It's one I didn't think of.
>
> Regardless, it doesn't seem to solve the issue of binary data on
> storage devices. Unless the descriptor was included in the storage.

The OpenVMS approach classically involved CDD/Repository, though
CDD/Repository is not going to be a particularly inviting approach for
the current world, and that for various reasons.
The non-OpenVMS approach tends to be embedding the declaration into the
data, akin to what—for instance—SQLite implements.
Or yes, tagging the data in some manner, either with each record or
within the fields within a file, with the field definitions either
embedded or stored separately.

> I'm not sure how much of a problem this is. For me, there isn't much,
> (but that's not none), storage of real numbers. But for when there is,
> I don't see any easy solutions. By now, somebody somewhere has written
> new code to look at archived binary data, and gotten erroneous data.
> Then the question becomes, do they even know they are working with
> bogus data?

Some don't ever access the archives. Some do. Some notice. Some
don't. Some believe what the computer tells them. Same as usual.

> No easy solutions, and I'm not sure there are even hard solutions for
> data that is already stored.

Archive conversions are the usual approach, though I'd presently prefer
to go to yaml, json or ilk, and let the folks analyzing those files use
those formats and not try to deal with floating point formats and
binary data storage. Flag the current file format with a header too,
so that future data conversions and future imports have something to
work with.

I don't prefer to use floating point for monetary values, as that
approach gets... ugly. Particularly around discounts, taxes,
commissions and other percentages. Integers or BCD are preferred. Or
string numerics and string math, as I used in DEC BASIC an aeon or
three ago, when choices were limited and the finances involved exceeded
the then-current integer range.

[Arne Vajhøj]

> 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

[Dave Froble]

On 1/5/2019 1:48 PM, John Reagan wrote:
> On Saturday, January 5, 2019 at 2:15:15 AM UTC-5, Dave Froble wrote:
>> On 1/4/2019 10:40 PM, John Reagan wrote:
>>> D_float?!? Ugh. The DtoT sequence is the longest. Depending on your floating operations, it could be 10x slower than just using native T_float.
>>>
>>> Why use D? Do you have binary data you are using?
>>>
>>
>> We use Basic ...
>>
>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>
>> As far as I know, the above used D_FLOAT.
>>
>> We have historical data files, with data from VAX, Alpha, and itanic.
>> We never have done any conversions, and so I'm assuming that we're still
>> using D_FLOAT, or, we've been screwed up for years ....
>>

>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
>

> Ok, so I just learned something else that I think BASIC does wrong.
>
> The default for /REAL_SIZE is essentially "give me the best single-precision format for this platform". F on VAX and Alpha, S on Itanium.
>
> The confusion is that the qualifier is used to provide BOTH the size of a real (single precision vs double precision) AND the format.
>
> I assumed that if you explicitly say /REAL_SIZE=SINGLE, it would mean the same as the default, namely I want REALs to be single-precision, compiler's choice on best format.
>
> I also assumed that if you explicitly say /REAL_SIZE=DOUBLE (or the equivalent OPTION SIZE directive), you would get "I want REALs to be double-precision, compiler's choice on the best format".
>
> Alas, nope.
>
> The HELP file was the first hint that I was wrong.
>
> The format of the REAL_SIZE qualifier is as follows:
>
> /REAL_SIZE={SINGLE}
> {DOUBLE}
> {GFLOAT}
> {SFLOAT}
> {TFLOAT}
> {XFLOAT}

From the latest Basic help:

DATA_TYPES

REAL

Floating-point values are stored using a signed exponent and a
binary
fraction. BASIC allows six floating-point formats: single,
double,
gfloat, sfloat, tfloat, and xfloat. These formats correspond
to the
SINGLE, DOUBLE, GFLOAT, SFLOAT, TFLOAT, and XFLOAT keywords.

Keyword Range Precision

SINGLE (32-bit) .29 * 10^-38 to 1.7 * 10^38 6 digits
DOUBLE (64-bit) .29 * 10^-38 to 1.7 * 10^38 16 digits
GFLOAT (64-bit) .56 * 10^-308 to .90 * 10^308 15 digits
SFLOAT (32-bit) 1.18 * 10^-38 to 3.40 * 10^38 6 digits
TFLOAT (64-bit) 2.23 * 10^-308 to 1.80 * 10^308 15 digits
XFLOAT (128-bit) 6.48 * 10^-4966 to 1.19 * 10^4932 33 digits

In declarative statements, the REAL keyword specifies
floating-point

First, I've never used SINGLE, don't see any point.

My understanding is that on VAX D_FLOAT is implemented in HW, at least
on some models.

And G_FLOAT on Alpha is implemented on HW, at least for some models.

What is the best format to use on VAX, Alpha, itanic, and soon x86?

John, I seem to recall that you indicated T_FLOAT would be the best to
use on itanic.

Is X_FLOAT slower? Basic is stuck on 32 bit addresses, but I didn't
think that had anything to do with the size of data types.

Me thinks that it's time to do a bit of testing. Determine if other
than D_FLOAT can be used in programs for better performance.

[Dave Froble]

> I said to myself, "where are the explicit FFLOAT or DFLOAT keywords?"
>

> 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.
>
> Another item for my "time machine" list.
>

It's 3:48 AM, and I think I just fried my brain ...

Might work Ok now, huh?

John, there are two Basic functions that map a real to a string, and a
string to a real. This is used to store data as a string, and retrieve
the data.

CVTF$() takes a real and produces an 8-byte string
CVT$F() takes a string from above and returns the real number

So now the question. Do there functions work for any real, or just
D_FLOAT? I'm thinking it might be just D_FLOAT.

[Bob Koehler]

In article <85022540-54d1-4a23...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
> On Monday, January 7, 2019 at 2:06:29 PM UTC-5, Bob Koehler wrote:
>> In article <8e34e423-4b9d-4a1d...@googlegroups.com>, geze...@rlgsc.com writes:
>> >
>> > However, in some cases, a program compiled with IEEE floating point may nee=
>> > d to access a binary file or a memory-resident data structure with a VAX fl=
>> > oating point representation. It is for this reason that I proposed adding t=
>> > he OpenVMS-specific optional qualifier.
>> >
>>
>> Or write in Fortran, where the I/O subsystem will convert on the fly,
>> even to/from formats only supported by hardware VMS never ran on.
>
> I was avoiding mentioning this feature since it involves DFOR$ "feature logicals" :)

I was under the impression that all of it could be accessed by using
keywords in the OPEN statement.

[Arne Vajhøj]

I would go for T.

It should be true HW on all Alpha, Itanium and x86-86 *and* be
binary compatible with most other platforms.

It is not supported on VAX, but do you really need to support VAX??

Arne

[Stephen Hoffman]

On 2019-01-08 08:53:13 +0000, Dave Froble said:

> John, there are two Basic functions that map a real to a string, and a
> string to a real. This is used to store data as a string, and retrieve
> the data.
>
> CVTF$() takes a real and produces an 8-byte string
> CVT$F() takes a string from above and returns the real number

FWIW... Per the BASIC docs: "CVT functions are supported only for
compatibility with BASIC-PLUS. It is recommended that you use the BASIC
dynamic mapping feature or multiple MAP statements for new program
development."

> So now the question. Do there functions work for any real, or just
> D_FLOAT? I'm thinking it might be just D_FLOAT.

It's whatever the default is for the compilation. The doc expressly
avoids mentioning the floating point format too, which usually means
that assumptions can be hazardous.

Use of the OpenVMS RTL calls including CVT$FTOF, CVT$CONVERT_FLOAT,
LIB$CVT_DX_DX and friends are the usual path for floating point
conversions, if BASIC can't easily manage the operations directly.

IEEE 754 float (S_Float single, T_Float double, etc) would usually be
the preferred format for most binary storage of floating point values,
and that'll work across little-endian systems.

I haven't seen much on OpenVMS that references the IEEE floating point
binary interchange formats unfortunately, nor does OpenVMS support IEEE
754-2008 quite yet.

And I'd usually prefer exporting to text for archival purposes.

Related:
http://neilrieck.net/misc/pdf/vms-docs/i64-floating-pt-wp.pdf
http://neilrieck.net/misc/pdf/vms-docs/t_and_s_float.pdf
etc.