On 1/29/2023 2:41 PM, John Dallman wrote:
> In article <tr6dje$2s9rm$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> Didn't VAX to Alpha migration cause some issues with D floating?
>>
>> If I remember correct then Alpha did not fully support D.
>
> It didn't support D at all,

I thought it could:
- load D from memory
- convert from D to G
- do G math
- convert back from G to D
- store D in memory

Arne

On 1/29/2023 2:41 PM, John Dallman wrote:
> In article <tr6dje$2s9rm$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> Didn't VAX to Alpha migration cause some issues with D floating?
>>
>> If I remember correct then Alpha did not fully support D.
>
> It didn't support D at all, as best I know. VAX had:
>
> F format is 32-bit single-precision, with 8 exponent bits, 1 sign bit,
> and 23 fraction bits, approximately plus or minus 2.9E-39 to plus or
> minus 1.7E+38, with a precision of approximately seven decimal digits.
> The exponent bias is 128. This format was carried forwards into Alpha.
>
> D format is double-precision, with 8 exponent bits, 1 sign bit, and 55
> fraction bits, approximately plus or minus 2.9E-39 to plus or minus
> 1.7E+38, with a precision of approximately 16 decimal digits. It's F
> format with more precision, but no more range. This format was not
> carried forwards into Alpha, and does not seem to have been much used.
>
> G format is also double-precision, with 11 exponent bits, 1 sign bit, and
> 52 fraction bits, approximately plus or minus 5.6E-309 to plus or minus
> 0.9E+308, with a precision of approximately 15 decimal digits. The
> exponent has a bias of 1,024 (not 128). This format was carried forwards
> into Alpha.
>
> H format is quad-precision, with 15 exponent bits, 1 sign bit, and 112
> fraction bits, approximately plus or minus 8.4E-4933 to plus or minus
> 5.9E+4931, with a precision of approximately 33 decimal digits. The
> exponent has a bias of 16,384 (not 1024). This format was not carried
> forwards into Alpha, although the similar 128-bit X format was provided
> there.
>
> Alpha also had S-format, IEEE single-precision which is similar to F but
> not the same, and T format, IEEE double precision, which is similar to G,
> but likewise not the same. The IEEE formats differ in their exponent
> biases.
>
> S format is 32-bit single-precision, with 8 exponent bits, 1 sign bit,
> and 23 fraction bits, approximately plus or minus 1.18E-39 to plus or
> minus 3.4E+38, with a precision of approximately seven decimal digits.
> The exponent bias is 127, not 128.
>
> T format is double-precision, with 11 exponent bits, 1 sign bit, and 52
> fraction bits, approximately plus or minus 2.2E-308 to plus or minus
> 1.8E+308, with a precision of approximately 16 decimal digits. The
> exponent has a bias of 1,023, not 1,024.
>
> This is summarised from
>
> <https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm>
>
> John
>

Hmmmm ......

My AlphaServer 800:

AS800> syh
OpenVMS V8.3 on node AS800 29-JAN-2023 17:36:30.33 Uptime 132 06:18:03

Basic help mentions ...

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

Now, it has been my impression that that DOUBLE is D-float.

Walks like a D-float
Quacks like a D-float
Is it a D-float?

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

On 1/29/2023 5:41 PM, Dave Froble wrote:
> On 1/29/2023 2:41 PM, John Dallman wrote:
>> In article <tr6dje$2s9rm$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> Didn't VAX to Alpha migration cause some issues with D floating?
>>>
>>> If I remember correct then Alpha did not fully support D.
>>
>> It didn't support D at all, as best I know. VAX had:

>> D format is double-precision, with 8 exponent bits, 1 sign bit, and 55
>> fraction bits, approximately plus or minus 2.9E-39 to plus or minus
>> 1.7E+38, with a precision of approximately 16 decimal digits. It's F
>> format with more precision, but no more range. This format was not
>> carried forwards into Alpha, and does not seem to have been much used.
>>
>> G format is also double-precision, with 11 exponent bits, 1 sign bit, and
>> 52 fraction bits, approximately plus or minus 5.6E-309 to plus or minus
>> 0.9E+308, with a precision of approximately 15 decimal digits. The
>> exponent has a bias of 1,024 (not 128). This format was carried forwards
>> into Alpha.

>      gfloat, sfloat, tfloat, and xfloat.  These  formats  correspond
> to  the
>      SINGLE, DOUBLE, GFLOAT, SFLOAT, TFLOAT, and XFLOAT keywords.
>
>      Keyword             Range                                  Precision

>      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

> Now, it has been my impression that that DOUBLE is D-float.
>
> Walks like a D-float
> Quacks like a D-float
> Is it a D-float?

Good question.

It can certainly take D float as input and provide D float
as output.

The question is how.

The Alpha architecture manual says that it only
supports:
- load D from memory
- convert from D to G
- do G math
- convert back from G to D
- store D in memory
which sort of operate on D float but loose 3 bits precision.

The alternative is software emulation, which will be able to do VAX
compatible D math but at a speed cost.

So either hardware G math loosing 3 bits of precision (which is what
I assume when I asked the question above) or software full D math.

Arne

On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
> On 1/29/2023 5:41 PM, Dave Froble wrote:
>>       gfloat, sfloat, tfloat, and xfloat.  These  formats  correspond
>> to  the
>>       SINGLE, DOUBLE, GFLOAT, SFLOAT, TFLOAT, and XFLOAT keywords.
>>
>>       Keyword             Range
>> Precision
>
>>       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
>
>> Now, it has been my impression that that DOUBLE is D-float.
>>
>> Walks like a D-float
>> Quacks like a D-float
>> Is it a D-float?
>
> Good question.
>
> It can certainly take D float as input and provide D float
> as output.
>
> The question is how.
>
> The Alpha architecture manual says that it only
> supports:
> - load D from memory
> - convert from D to G
> - do G math
> - convert back from G to D
> - store D in memory
> which sort of operate on D float but loose 3 bits precision.
>
> The alternative is software emulation, which will be able to do VAX
> compatible D math but at a speed cost.
>
> So either hardware G math loosing 3 bits of precision (which is what
> I assume when I asked the question above) or software full D math.

Experiment:

$ type d.bas
program d

declare double x, y, z

x = 12.34
y = 45.67
z = x + y

print z

end program
$ bas/noop/list/mach d
$ sear d.lis cvtdg,addg,cvtgd
57EA13CA 0060 CVTDG F10, F10
57EB13CB 0068 CVTDG F11, F11
554B140A 0070 ADDG F10, F11, F10
57EA15AA 0074 CVTGD F10, F10

Looks like G math to me.

(it does something smart with /OPT so that is why the /NOOP is used)

Arne

On 1/29/2023 7:24 PM, Arne Vajhøj wrote:
> Experiment:
>
> $ type d.bas
> program d
>
> declare double x, y, z
>
> x = 12.34
> y =  45.67
> z = x + y
>
> print z
>
> end program
> $ bas/noop/list/mach d
> $ sear d.lis cvtdg,addg,cvtgd
> 57EA13CA     0060               CVTDG   F10, F10
> 57EB13CB     0068               CVTDG   F11, F11
> 554B140A     0070               ADDG    F10, F11, F10
> 57EA15AA     0074               CVTGD   F10, F10
>
> Looks like G math to me.
>
> (it does something smart with /OPT so that is why the /NOOP is used)

To prevent the compiler from being smart:

$ type dd.bas
function double add(double x, double y)

add = x + y

end function
$ bas/list/mach dd
$ sear dd.lis cvtdg,addg,cvtgd
57E013C0 00A0 CVTDG F0, F0
57E113C1 00B0 CVTDG F1, F1
54011400 00B4 ADDG F0, F1, F0
57E015A2 00B8 CVTGD F0, ADD
; F0, F2

Arne

On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
> On 1/29/2023 5:41 PM, Dave Froble wrote:
>> On 1/29/2023 2:41 PM, John Dallman wrote:
>>> In article <tr6dje$2s9rm$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>>> wrote:
>>>> Didn't VAX to Alpha migration cause some issues with D floating?
>>>>
>>>> If I remember correct then Alpha did not fully support D.
>>>
>>> It didn't support D at all, as best I know. VAX had:
>
>>> D format is double-precision, with 8 exponent bits, 1 sign bit, and 55
>>> fraction bits, approximately plus or minus 2.9E-39 to plus or minus
>>> 1.7E+38, with a precision of approximately 16 decimal digits. It's F
>>> format with more precision, but no more range. This format was not
>>> carried forwards into Alpha, and does not seem to have been much used.
>>>
>>> G format is also double-precision, with 11 exponent bits, 1 sign bit, and
>>> 52 fraction bits, approximately plus or minus 5.6E-309 to plus or minus
>>> 0.9E+308, with a precision of approximately 15 decimal digits. The
>>> exponent has a bias of 1,024 (not 128). This format was carried forwards
>>> into Alpha.
>
>> gfloat, sfloat, tfloat, and xfloat. These formats correspond to the
>> SINGLE, DOUBLE, GFLOAT, SFLOAT, TFLOAT, and XFLOAT keywords.
>>
>> Keyword Range Precision
>
>> 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
>
>> Now, it has been my impression that that DOUBLE is D-float.
>>
>> Walks like a D-float
>> Quacks like a D-float
>> Is it a D-float?
>
> Good question.
>
> It can certainly take D float as input and provide D float
> as output.
>
> The question is how.
>
> The Alpha architecture manual says that it only
> supports:
> - load D from memory
> - convert from D to G
> - do G math
> - convert back from G to D
> - store D in memory
> which sort of operate on D float but loose 3 bits precision.

Correct, that is how it's provided.

> The alternative is software emulation, which will be able to do VAX
> compatible D math but at a speed cost.

Would you think it would do better than the loss of the 3 bits? Not an issue
most of the time. However, I'm aware of a few instances where things aren't so
good. I seem to recall the 5.9 to 6.0 range having an issue.

But, it was rather nice to move massive amounts of data from a VAX and have it
"just work" on Alpha.

> So either hardware G math loosing 3 bits of precision (which is what
> I assume when I asked the question above) or software full D math.
>
> Arne
>
>

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

On 2023-01-29 01:25, Arne Vajhøj wrote:

> I am not sure that I get your point.
>
> This is how rounding of money works.
>
> Software that operate on money needs to implement
> the rules.
>
> Same reason that good rounding supports different
> rounding mode: UP (round .5 up), EVEN (round .5 to
> even) etc.. Different places has different rules and
> the software need to implement those.

I think it's very important to differentiate between comparison between
two floating point numbers for equality, and the question if two
monetary amounts would round to the same value.

These are two different things.

For the latter, I would first perform the correct rounding for both
values, and then again do a comparison between the two resulting values,
which if stored as floating point, needs to be close enough to each
other to be considered equal.

Johnny

On 1/29/2023 11:16 PM, Dave Froble wrote:
> On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
>> The Alpha architecture manual says that it only
>> supports:
>> - load D from memory
>> - convert from D to G
>> - do G math
>> - convert back from G to D
>> - store D in memory
>> which sort of operate on D float but loose 3 bits precision.
>
> Correct, that is how it's provided.
>
>> The alternative is software emulation, which will be able to do VAX
>> compatible D math but at a speed cost.
>
> Would you think it would do better than the loss of the 3 bits?  Not an
> issue most of the time.  However,  I'm aware of a few instances where
> things aren't so good.  I seem to recall the 5.9 to 6.0 range having an
> issue.

I wonder what Basic on Itanium does and what Basic on x86-64 does / will do.

Convert to T and do T math? Or software emulation?

> But, it was rather nice to move massive amounts of data from a VAX and
> have it "just work" on Alpha.

VMS got a pretty good track record for not breaking things.

Hoff would say *too* good a track record, but ...

Arne

On 2023-01-29 15:57, Simon Clubley wrote:
> On 2023-01-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I find it hard to see why one would bother with the risks
>> of using floating point if a decimal type is available.
>>
>> VMS Basic has a decimal type.
>>
>
> Did RSTS/E Basic ever get a decimal data type, and if so, when ?
>
> PDP-11 DIBOL had a decimal data type, but I don't know when DIBOL
> was introduced to the PDP-11 (ie: was it _after_ David started
> using RSTS/E Basic ?)

RSTS/E BASIC never had fancy data types, however for money calculations,
you usually used strings, and the string math functions, which were exact.

Another option would have been to use fixed point, of course. But since
integers in BASIC+ only were 16 bit, it usually wasn't an option there.

String math really was the thing for financial stuff in BASIC.

Johnny

On 2023-01-29 04:39, Dave Froble wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>>     Who cares what the numbers represent?  For example, if you
>>>>>> round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>> --scott
>>
>
> What if you didn't have a choice?
>
> RSTS/E V04b
>
> Signed word integers
> Strings
> Single and double D-float
>
> That's all there was ...

BASIC2

help fun b sum

FUNCTIONS

BUILT-IN

SUM$

The SUM$ function returns a string whose value is the sum of two numeric
strings.

Format

str-vbl = SUM$(str-exp1, str-exp2)

Example

600 Sigma$ = SUM$("234.444", A$)

Topic?

Johnny

On 2023-01-29 04:44, Arne Vajhøj wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to
>>> represent
>>> money.
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>
> There is always integers and implied decimal.
>
> Not fun though.
>
> And one need an integer with enough bits ...
>
> Could PDP-11 do 32 bit integers?

Slightly wrong question. Of course the machine could do 32-bit integers,
or any other number of bits, if you want to. But the question really is
about the language you use, and how much effort it is.

RSTS/E BASIC+ do not have 32-bit integers. But it do have string math.

I can't remember the limit, but I think it's something like 31 decimal
digits. Which should be plenty for everyone.

Johnny

On 2023-01-29 14:50, Arne Vajhøj wrote:
> On 1/29/2023 1:21 AM, Dave Froble wrote:
>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>> One of the absolute FIRST things that I was told about floating point
>>>>> variables in my first programming class was to NEVER use them to
>>>>> represent
>>>>> money.
>>>>
>>>> What if you didn't have a choice?
>>>>
>>>> RSTS/E V04b
>>>>
>>>> Signed word integers
>>>> Strings
>>>> Single and double D-float
>>>>
>>>> That's all there was ...
>>>
>>> There is always integers and implied decimal.
>>>
>>> Not fun though.
>>>
>>> And one need an integer with enough bits ...
>>>
>>> Could PDP-11 do 32 bit integers?
>>
>> What part of "signed word integers" didn't you understand?  As in 16
>> bits. -32768 to 32767.
>
> I sort of had guessed that word was the same as on VAX,
> but I don't understand how it can't have a 32 bit integer.

BASIC+ do not have much of a type system in general. You imply the types
by appending $, % or nothing, for string, integer or float. That's about
it. You cannot declare variables to be of specific, or other types.

But the PDP-11 as such can of course do 32-bit math.

> How does one work with file sizes and file position
> in bytes on PDP-11?

It depends on the OS and language.

> I know you don't do C, but I believe C was invented on
> PDP-11.

Correct. And yes, you do have long there.

Johnny

On 2023-01-29 20:40, John Dallman wrote:
> In article <tr6dje$2s9rm$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> Didn't VAX to Alpha migration cause some issues with D floating?
>>
>> If I remember correct then Alpha did not fully support D.
>
> It didn't support D at all, as best I know. VAX had:

[...]

F and D format are compatible with the PDP-11.

Johnny

On 1/30/2023 7:33 PM, Johnny Billquist wrote:
> On 2023-01-29 15:57, Simon Clubley wrote:
>> On 2023-01-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> VMS Basic has a decimal type.
>>
>> Did RSTS/E Basic ever get a decimal data type, and if so, when ?

> RSTS/E BASIC never had fancy data types, however for money calculations,
> you usually used strings, and the string math functions, which were exact.

> String math really was the thing for financial stuff in BASIC.

A funny note. PHP still supports that method!

<?php
bcscale(21);
$x = '100000000000000000000.000000000000000000001';
$y = '200000000000000000000.000000000000000000002';
$z = bcadd($x, $y);
echo $z;
?>

outputs:

300000000000000000000.000000000000000000003

Arne

On 2023-01-29 15:51, Simon Clubley wrote:
> On 2023-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>>> One of the absolute FIRST things that I was told about floating point
>>>>>> variables in my first programming class was to NEVER use them to
>>>>>> represent
>>>>>> money.
>>>>>
>>>>> What if you didn't have a choice?
>>>>>
>>>>> RSTS/E V04b
>>>>>
>>>>> Signed word integers
>>>>> Strings
>>>>> Single and double D-float
>>>>>
>>>>> That's all there was ...
>>>>
>>>> There is always integers and implied decimal.
>>>>
>>>> Not fun though.
>>>>
>>>> And one need an integer with enough bits ...
>>>>
>>>> Could PDP-11 do 32 bit integers?
>>>
>>> What part of "signed word integers" didn't you understand?  As in 16
>>> bits. -32768 to 32767.
>>
>> I sort of had guessed that word was the same as on VAX,
>> but I don't understand how it can't have a 32 bit integer.
>>
>> How does one work with file sizes and file position
>> in bytes on PDP-11?
>>
>
> The same way as it's done with a block-based filesystem (ODS-2) on VMS.

If you look at the QIO functions to F11ACP in RSX, the block number take
two parameters, in order to be 32 bits. Fields in RMS structures are
simply just 32 bits where needed, if you deal at it at that level.

> In general, the 16-bit nature of the PDP-11 is reflected in the API.

Not sure which API you are referring to here. The QIO interface
obviously have just 16-bit wide arguments, so something like the block
number needs to parameter values for the full 32 bits.
Most other APIs (such as FCS or RMS) just define 32-bit values where needed.

> Ever worked with real-mode MS-DOS at assembly language level ?
>
> It's the same kind of thing.

No. Not at all comparable. The PDP-11 is rather different than the x86.
There was never far pointers, segment registers, or all the weird stuff
of MS-DOS.

>> I know you don't do C, but I believe C was invented on
>> PDP-11.
>>
>
> What makes you think that "int" in C is _always_ at least 32 bits ? :-)
>
> There's a reason why both int and long int have always existed in C.
>
> And on architectures that do not support 32-bit ints, then long int is
> a library/RTL feature implemented by the language in the same way as
> 64-bit long long int is implemented by the language RTL on 32-bit
> architectures.

Um. Not necessarily. The compiler can just know how to do 32-bit
operations on a 16-bit machine, and generate the code straight off, even
if it's a bit more complex than simple 16-bit operations.

And that is what I see for PDP-11 C for example.

> Also, most languages on RSTS/E intended for commercial data processing
> also supported a decimal datatype, which was implemented by the language's
> RTL. It seems early RSTS/E Basic wasn't one of them however, based on
> what David is saying.

You could definitely argue that the numeric strings are a decimal data type.

Johnny

On 1/30/23 6:32 PM, Arne Vajhøj wrote:

> I wonder what Basic on Itanium does and what Basic on x86-64 does / will
> do.
>
> Convert to T and do T math? Or software emulation?

Looks like for Itanium it's all covered here:

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

It seems unlikely they would do anything differently for x86_64.

On 1/30/2023 9:50 PM, Craig A. Berry wrote:
> On 1/30/23 6:32 PM, Arne Vajhøj wrote:
>> I wonder what Basic on Itanium does and what Basic on x86-64 does /
>> will do.
>>
>> Convert to T and do T math? Or software emulation?
>
> Looks like for Itanium it's all covered here:
>
> http://neilrieck.net/misc/pdf/vms-docs/i64-floating-pt-wp.pdf
>
> It seems unlikely they would do anything differently for x86_64.

<quote>
When you compile an OpenVMS application that specifies an option to use VAX
floating-point on the Itanium architecture, the compiler automatically
generates code for
converting floating-point formats. Whenever the application performs a
sequence of
arithmetic operations, this code does the following:
1. Converts VAX floating-point formats to either IEEE single or IEEE double
floating-point formats.
2. Performs arithmetic operations in IEEE floating-point arithmetic.
3. Converts the resulting data from IEEE formats back to VAX formats.
</quote>

Arne

On 2023-01-30, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-01-29 15:51, Simon Clubley wrote:
>> On 2023-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>>>> One of the absolute FIRST things that I was told about floating point
>>>>>>> variables in my first programming class was to NEVER use them to
>>>>>>> represent
>>>>>>> money.
>>>>>>
>>>>>> What if you didn't have a choice?
>>>>>>
>>>>>> RSTS/E V04b
>>>>>>
>>>>>> Signed word integers
>>>>>> Strings
>>>>>> Single and double D-float
>>>>>>
>>>>>> That's all there was ...
>>>>>
>>>>> There is always integers and implied decimal.
>>>>>
>>>>> Not fun though.
>>>>>
>>>>> And one need an integer with enough bits ...
>>>>>
>>>>> Could PDP-11 do 32 bit integers?
>>>>
>>>> What part of "signed word integers" didn't you understand?  As in 16
>>>> bits. -32768 to 32767.
>>>
>>> I sort of had guessed that word was the same as on VAX,
>>> but I don't understand how it can't have a 32 bit integer.
>>>
>>> How does one work with file sizes and file position
>>> in bytes on PDP-11?
>>>
>>
>> The same way as it's done with a block-based filesystem (ODS-2) on VMS.
>
> If you look at the QIO functions to F11ACP in RSX, the block number take
> two parameters, in order to be 32 bits. Fields in RMS structures are
> simply just 32 bits where needed, if you deal at it at that level.
>
>> In general, the 16-bit nature of the PDP-11 is reflected in the API.
>
> Not sure which API you are referring to here. The QIO interface
> obviously have just 16-bit wide arguments, so something like the block
> number needs to parameter values for the full 32 bits.
> Most other APIs (such as FCS or RMS) just define 32-bit values where needed.
>

The system services/syscalls/whatever they were called on PDP-11.

>> Ever worked with real-mode MS-DOS at assembly language level ?
>>
>> It's the same kind of thing.
>
> No. Not at all comparable. The PDP-11 is rather different than the x86.
> There was never far pointers, segment registers, or all the weird stuff
> of MS-DOS.
>

The reference was to having to string together 16-bit chunks of a number
into a larger value instead of just being able to directly write into a
32-bit register in 32-bit chunks.

>>> I know you don't do C, but I believe C was invented on
>>> PDP-11.
>>>
>>
>> What makes you think that "int" in C is _always_ at least 32 bits ? :-)
>>
>> There's a reason why both int and long int have always existed in C.
>>
>> And on architectures that do not support 32-bit ints, then long int is
>> a library/RTL feature implemented by the language in the same way as
>> 64-bit long long int is implemented by the language RTL on 32-bit
>> architectures.
>
> Um. Not necessarily. The compiler can just know how to do 32-bit
> operations on a 16-bit machine, and generate the code straight off, even
> if it's a bit more complex than simple 16-bit operations.
>
> And that is what I see for PDP-11 C for example.
>

It's still something that has to be implemented in the generated compiler
code instead of it being able to directly write into a 32-bit register in
32-bit chunks.

>> Also, most languages on RSTS/E intended for commercial data processing
>> also supported a decimal datatype, which was implemented by the language's
>> RTL. It seems early RSTS/E Basic wasn't one of them however, based on
>> what David is saying.
>
> You could definitely argue that the numeric strings are a decimal data type.
>

I would not disagree with that. Having never really used DEC Basic,
I had forgotten about them until you brought them up.

Did they exist back in the V4 days when David started writing his code ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-01-31 14:07:05 +0000, Simon Clubley said:

> I would not disagree with that. Having never really used DEC Basic, I
> had forgotten about them until you brought them up.
>
> Did they exist back in the V4 days when David started writing his code ?

VAX/VMS V3.x BASIC apps usually used integers, and used numeric strings
via the VAX/VMS RTLs.

At that time (IIRC), the VAX decimal instructions were only "exposed"
in COBOL and MACRO-32. And IIRC from the era of the OpenVMS port to
Alpha, it was still only COBOL and MACRO-32.

Ported a BP2 system from PDP-11 running some mutt RSX-11M/M+ SYSGEN to
VAX/VMS ~V3.2 and that eventually running DEC BASIC.

The app developer had used FP for cash all over the place. Also some
other sorts of unsavory things. And not unexpectedly, the calculations
were not working quite right. Particularly around sales tax. The
accountants and billing folks and customers were all annoyed. Though my
hat is off to the lawyer that kept sending in the corrected cash
remittance for the bad-math bill they'd been receiving.

Ended up going to integers for most of the math, and to numeric strings
when greater range was required.

Had considered going to multiple-precision integer math and skipping
the string math, but the string math was (is) built-in and was working,
and was fast enough for that app.

Now, I'd use quadwords / long long / int64_t for that stuff, or would
use a bignum package. Quadword would have been enough for the cash
involved in that app, and in most other cash-related apps.

~USD$184,467,440,737,095,516.15 / ~MXN$184,467,440,737,095,516.15 /
€184.467.440.737.095.516,15 / etc.

OpenVMS still lacks native-API bignum support (past the string math),
though the OpenSSL cryptographic library and other multiple-precision
libraries can potentially be useful there.

I haven't seen much in the way of x86-64 app porting guidelines from
VSI, but I suspect that's somewhat tangled with the ongoing
compiler-porting work and related shake-out.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2023-01-31 15:07, Simon Clubley wrote:
> On 2023-01-30, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-01-29 15:51, Simon Clubley wrote:
>>> On 2023-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>>>> Could PDP-11 do 32 bit integers?
>>>>>
>>>>> What part of "signed word integers" didn't you understand?  As in 16
>>>>> bits. -32768 to 32767.
>>>>
>>>> I sort of had guessed that word was the same as on VAX,
>>>> but I don't understand how it can't have a 32 bit integer.
>>>>
>>>> How does one work with file sizes and file position
>>>> in bytes on PDP-11?
>>>>
>>>
>>> The same way as it's done with a block-based filesystem (ODS-2) on VMS.
>>
>> If you look at the QIO functions to F11ACP in RSX, the block number take
>> two parameters, in order to be 32 bits. Fields in RMS structures are
>> simply just 32 bits where needed, if you deal at it at that level.
>>
>>> In general, the 16-bit nature of the PDP-11 is reflected in the API.
>>
>> Not sure which API you are referring to here. The QIO interface
>> obviously have just 16-bit wide arguments, so something like the block
>> number needs to parameter values for the full 32 bits.
>> Most other APIs (such as FCS or RMS) just define 32-bit values where needed.
>>
>
> The system services/syscalls/whatever they were called on PDP-11.

I guess the really correct term in RSX is directives.
As calls such as QIO to access some block is using a 32-bit number, you
might argue that it deals with 32-bit integers then. Even if it have to
provide the high and low 16 bits as two separate values. But they are
just interpreted together as a 32-bit value all the time.

>>> Ever worked with real-mode MS-DOS at assembly language level ?
>>>
>>> It's the same kind of thing.
>>
>> No. Not at all comparable. The PDP-11 is rather different than the x86.
>> There was never far pointers, segment registers, or all the weird stuff
>> of MS-DOS.
>>
>
> The reference was to having to string together 16-bit chunks of a number
> into a larger value instead of just being able to directly write into a
> 32-bit register in 32-bit chunks.

Well, that is true for just about any CPU, for anything larger than just
fits into one register. Both PDP-11 and VAX string multiple registers
together for some operations for larger values than fit in one register.
And same when in memory.

>>>> I know you don't do C, but I believe C was invented on
>>>> PDP-11.
>>>>
>>>
>>> What makes you think that "int" in C is _always_ at least 32 bits ? :-)
>>>
>>> There's a reason why both int and long int have always existed in C.
>>>
>>> And on architectures that do not support 32-bit ints, then long int is
>>> a library/RTL feature implemented by the language in the same way as
>>> 64-bit long long int is implemented by the language RTL on 32-bit
>>> architectures.
>>
>> Um. Not necessarily. The compiler can just know how to do 32-bit
>> operations on a 16-bit machine, and generate the code straight off, even
>> if it's a bit more complex than simple 16-bit operations.
>>
>> And that is what I see for PDP-11 C for example.
>>
>
> It's still something that has to be implemented in the generated compiler
> code instead of it being able to directly write into a 32-bit register in
> 32-bit chunks.

Well, the compiler needs to implement the moving into one register as
well. Nothing happens automatically. So - moving to one register, or
two. What's the big deal? Same thing with arithmetic.
No library/RTL actually needed for the simple stuff.

>>> Also, most languages on RSTS/E intended for commercial data processing
>>> also supported a decimal datatype, which was implemented by the language's
>>> RTL. It seems early RSTS/E Basic wasn't one of them however, based on
>>> what David is saying.
>>
>> You could definitely argue that the numeric strings are a decimal data type.
>>
>
> I would not disagree with that. Having never really used DEC Basic,
> I had forgotten about them until you brought them up.

At one point I did some financial code in BASIC, very long time ago, and
then I did use those functions because they just seemed more precise.

With that said, I had also forgotten about "==" which is used to check
for approximate equality of FP in BASIC+.

> Did they exist back in the V4 days when David started writing his code ?

That is a good question. I can't say for absolutely sure, but I did find
a BASIC+ manual from V6, and couldn't find it in there, so I suspect
not. Next I checked V10, and there it is in the manual. Couldn't find
any manual in between on a quick search.

Johnny

On Monday, January 30, 2023 at 7:32:10 PM UTC-5, Arne Vajhøj wrote:
> On 1/29/2023 11:16 PM, Dave Froble wrote:
> > On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
> >> The Alpha architecture manual says that it only
> >> supports:
> >> - load D from memory
> >> - convert from D to G
> >> - do G math
> >> - convert back from G to D
> >> - store D in memory
> >> which sort of operate on D float but loose 3 bits precision.
> >
> > Correct, that is how it's provided.
> >
> >> The alternative is software emulation, which will be able to do VAX
> >> compatible D math but at a speed cost.
> >
> > Would you think it would do better than the loss of the 3 bits? Not an
> > issue most of the time. However, I'm aware of a few instances where
> > things aren't so good. I seem to recall the 5.9 to 6.0 range having an
> > issue.
> I wonder what Basic on Itanium does and what Basic on x86-64 does / will do.
>
> Convert to T and do T math? Or software emulation?

Just like Itanium. Convert G to T (same size exponent) or convert D to T (and round
3 bits); operate on the T; convert back to G (or D) as needed. Nobody complained
on Itanium.

For VAX to Alpha, VEST/TIE would actually emulate all 56 bits of the D exponents.
VEST/TIE also emulated VAX H-float. Native Alpha rounded 3 bits for D to G,
nobody complained.

For Alpha, most compilers went from F/D on VAX to F/G on Alpha. However, BASIC
has stuck with D-floating for DOUBLE on Alpha and on Itanium. At this point, we
will probably continue that mapping (although I think they shouldn't have stuck with D
for all that time).

On Tuesday, January 31, 2023 at 11:16:10 AM UTC-5, Stephen Hoffman wrote:
> On 2023-01-31 14:07:05 +0000, Simon Clubley said:
>
> > I would not disagree with that. Having never really used DEC Basic, I
> > had forgotten about them until you brought them up.
> >
> > Did they exist back in the V4 days when David started writing his code ?
> VAX/VMS V3.x BASIC apps usually used integers, and used numeric strings
> via the VAX/VMS RTLs.
>
> At that time (IIRC), the VAX decimal instructions were only "exposed"
> in COBOL and MACRO-32. And IIRC from the era of the OpenVMS port to
> Alpha, it was still only COBOL and MACRO-32.
>
VAX BLISS also has packed decimal builtins. Not moved forward.

The packed decimal "instructions" (actually macros that expand to
library routine calls in STARLET.OLB, written in Macro-32 of course)
work just fine on Macro-32 on x86.

For COBOL, the visible behavior is the same. For certain intermediates,
it uses a B100 (base100 packed format) on Itanium, but we went with
128-bit integers on x86. Easier to pass around and has more than enough
digits.

On 1/31/2023 12:47 PM, John Reagan wrote:
> On Monday, January 30, 2023 at 7:32:10 PM UTC-5, Arne Vajhøj wrote:
>> On 1/29/2023 11:16 PM, Dave Froble wrote:
>>> On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
>>>> The Alpha architecture manual says that it only
>>>> supports:
>>>> - load D from memory
>>>> - convert from D to G
>>>> - do G math
>>>> - convert back from G to D
>>>> - store D in memory
>>>> which sort of operate on D float but loose 3 bits precision.
>>>
>>> Correct, that is how it's provided.
>>>
>>>> The alternative is software emulation, which will be able to do VAX
>>>> compatible D math but at a speed cost.
>>>
>>> Would you think it would do better than the loss of the 3 bits? Not an
>>> issue most of the time. However, I'm aware of a few instances where
>>> things aren't so good. I seem to recall the 5.9 to 6.0 range having an
>>> issue.
>> I wonder what Basic on Itanium does and what Basic on x86-64 does / will do.
>>
>> Convert to T and do T math? Or software emulation?
>
> Just like Itanium. Convert G to T (same size exponent) or convert D to T (and round
> 3 bits); operate on the T; convert back to G (or D) as needed. Nobody complained
> on Itanium.
>
> For VAX to Alpha, VEST/TIE would actually emulate all 56 bits of the D exponents.
> VEST/TIE also emulated VAX H-float. Native Alpha rounded 3 bits for D to G,
> nobody complained.

Not 100% accurate, but complaining would do no good, so adequate work arounds
were developed.

It just expounds on the concept that if one wants accuracy, then, don't use FP.
If one has no reasonable choice, then, you get what you get.

> For Alpha, most compilers went from F/D on VAX to F/G on Alpha. However, BASIC
> has stuck with D-floating for DOUBLE on Alpha and on Itanium. At this point, we
> will probably continue that mapping (although I think they shouldn't have stuck with D
> for all that time).
>

If one begins a journey, and instead of continuing, continues to go back and
start over, one never reaches the goal.

I and others knew that use of D-float for money wasn't an optimum solution, but
once going down that road, if workable solutions were in place, it wasn't
reasonable to go back and start over.

I tried one time with a customer. The suggestion was to convert all monetary
data to another format, including historical data, programs, everything. It
wasn't going to be cheap. I was asked what the benefit would be. Basically,
maybe a penny here, a penny there. I was almost thrown out of the CEO's office.
I'd already wasted more of his time than whatever accuracy could be saved. I
learned that lesson real quick, and well.

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

On 1/29/2023 11:16 PM, Dave Froble wrote:
> On 1/29/2023 7:17 PM, Arne Vajhøj wrote:
>> The Alpha architecture manual says that it only
>> supports:
>> - load D from memory
>> - convert from D to G
>> - do G math
>> - convert back from G to D
>> - store D in memory
>> which sort of operate on D float but loose 3 bits precision.
>
> Correct, that is how it's provided.
>
>> The alternative is software emulation, which will be able to do VAX
>> compatible D math but at a speed cost.
>
> Would you think it would do better than the loss of the 3 bits?  Not an
> issue most of the time.  However,  I'm aware of a few instances where
> things aren't so good.  I seem to recall the 5.9 to 6.0 range having an
> issue.

Those bit are usually not significant.

I had to think hard to come up with an example showing
the bits getting chopped off.

program dg

declare integer i

external sub test(integer)

for i = 0 to 15
call test(i)
next i

end program
! sub test(integer v)

map (xb) double x
map (xb) byte b(7)

external double function add(double, double)

b(0) = 0
b(1) = 64
b(2) = 0
b(3) = 0
b(4) = 0
b(5) = 0
b(6) = v
b(7) = 0
x = add(x, 0.0)
print v, "->", b(6)

end sub
! function double add(double a, double b)

add = a + b

end function

$ r dg
0 -> 0
1 -> 0
2 -> 0
3 -> 0
4 -> 8
5 -> 8
6 -> 8
7 -> 8
8 -> 8
9 -> 8
10 -> 8
11 -> 8
12 -> 16
13 -> 16
14 -> 16
15 -> 16

Arne

On 2023-01-31, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2023-01-31 14:07:05 +0000, Simon Clubley said:
>
>> I would not disagree with that. Having never really used DEC Basic, I
>> had forgotten about them until you brought them up.
>>
>> Did they exist back in the V4 days when David started writing his code ?
>
> VAX/VMS V3.x BASIC apps usually used integers, and used numeric strings
> via the VAX/VMS RTLs.
>

Actually, the V4 reference here was to RSTS/E, not VAX/VMS... :-)

Interesting story however, and shows just how easy it is to screw up
using FP.

Something just occurred to me while writing this: does the latest solution
to everything :-) (ie: Rust) still allow you to directly compare two floating
point numbers ?

Based on a quick search, the answer would appear to be yes, which was
a bit of a surprise...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.