Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> On 9/13/23 12:52 PM, Arne Vajh??j wrote:
>> On 9/13/2023 1:48 PM, Tim Sneddon wrote:
>>> Arne Vajh??j <arne@vajhoej.dk> wrote:
>>>> Hey. Are you saying that PL/I will (at some point in time)
>>>> be available for VMS x86-64?
>>>
>>> Yes, that is correct.
>>>
>>>>
>>>> If yes - are you at liberty to elaborate a bit?
>>>>
>>>
>>> There is currently work underway to get PL/I to GEM BL50
>>> on Alpha. Unfortunately, PL/I was stuck at BL26 for a long
>>> time.
>>>
>>> This has been a slow process, but is starting to yield
>>> results.
>>>
>>> When the Alpha update is verified correct against the
>>> regression test library a new Alpha kit (V5.0) will be
>>> released. My guess is that it will be in Jan 2024.
>>
>> And then you need to get it to VMS x86-64.
>>
>> Is the plan to make an agreement with VSI and use the
>> same GEM to LLVM thing they are using?
>
> I'm pretty sure that would be the only game in town without
> reimplementing the whole thing to use LLVM directly.

For the VMS compiler, using G2L is certainly the shortest path.

Regards, Tim.

Tim Sneddon <tsneddon@panix.com> wrote:
> Arne Vajh??j <arne@vajhoej.dk> wrote:
>> Does anyone know if it is still possible to get a hobbyist
>> license for that?
>>
>
> Yes, it is still possible.
>
>> Web site is up but I get errors when trying requesting a
>> hobbyist license.
>>
>
> There were two problems. The first (which is fixed) related
> to some instrafstructure being moved around.
>
> The second (license mail server appearing in Spamhaus) is
> begin fixed. Unfortunately with moving things around there
> was a PTR problem and the HELO banner does not match.
>
> Hopefully all should be resolved by tomorrow.

This problem has been resolved. It is now possible to request
license PAKs for VAX and Alpha PL/I.

Now to sort out the SSL certificates... :-)

Regards, Tim.

On Wednesday, September 13, 2023 at 10:58:20 PM UTC-7, Tim Sneddon wrote:

(snip)

> This problem has been resolved. It is now possible to request
> license PAKs for VAX and Alpha PL/I.

Thanks!

Now all I have to do is get the MAC address for the form ...

gah4 <gah4@u.washington.edu> wrote:
> The PL/I compiler I used most over the years, is the IBM PL/I(F) compiler
> that dates back to the 1960's. I do remember an error message like
> "SEMICOLON MISSING, ONE INSERTED" where it inserts one into the
> internal representation and continues on. Often with strange results.

I remember (in 1974) submitting a PL/1 program to the IBM checkout
compiler, which ran using up my complete cpu time quota and produced no
output at all. I resubmitted it to the optimising compiler which used a
couple of seconds and said “Mismatched quotes”.

I’d missed out a close quote early in the program, so all my program code
had disappeared into literal text, and all my output messages and error
texts had become program. The checkout compiler had had a fit trying to
turn the messages into valid PL/1 program!

--
Paul at the paulhardy.net domain

On Thursday, September 14, 2023 at 12:23:51 AM UTC-7, Paul Hardy wrote:
> gah4 <ga...@u.washington.edu> wrote:
> > The PL/I compiler I used most over the years, is the IBM PL/I(F) compiler
> > that dates back to the 1960's. I do remember an error message like
> > "SEMICOLON MISSING, ONE INSERTED" where it inserts one into the
> > internal representation and continues on. Often with strange results.

> I remember (in 1974) submitting a PL/1 program to the IBM checkout
> compiler, which ran using up my complete cpu time quota and produced no
> output at all. I resubmitted it to the optimising compiler which used a
> couple of seconds and said “Mismatched quotes”.
> I’d missed out a close quote early in the program, so all my program code
> had disappeared into literal text, and all my output messages and error
> texts had become program. The checkout compiler had had a fit trying to
> turn the messages into valid PL/1 program!
I never used the checkout compiler, and I believe only a little the optimizing compiler.

About 25 years ago, I got an IBM AT/370, which is a card that fits into a PC/AT
(or, with some luck, an AT clone), runs the VM/PC operating system, and runs
a version of CMS. (By then, they dumped them and someone was selling
them for about $20 each.)

My first project was to get PL/I (F) running on it.

I got the demo version of the Tachyon assembler to assemble it,
got the object programs to the AT/370, and did manage to get it to run.
It takes about 5 minutes to compile a three line program.

A few years later, I found someone who knew the person at IBM who built
the P/370. P/370 is a Microchannel card that runs in a Microchannel
PC running OS/2. It is a full emulation of a 370, unlike the AT/370.
I had OS/VS2 and VM/370 running on that one. Runs much better
than the AT/370! And I had PL/I (F) on that one, too.

But I haven't run any PL/I programs for years now.

gah4 <gah4@u.washington.edu> wrote:
> On Wednesday, September 13, 2023 at 10:58:20???PM UTC-7, Tim Sneddon wrote:
>
> (snip)
>
>> This problem has been resolved. It is now possible to request
>> license PAKs for VAX and Alpha PL/I.
>
> Thanks!
>
> Now all I have to do is get the MAC address for the form ...
>

Don't worry about that. I might actually remove the field
from the form. Checking that was never implemented and the
Kednos site was simply lifted and copied, never updated
after that.

Regards, Tim.

On Thursday, September 14, 2023 at 1:04:37 AM UTC-7, Tim Sneddon wrote:

(snip, I wrote)
> > Now all I have to do is get the MAC address for the form ...
> Don't worry about that. I might actually remove the field
> from the form. Checking that was never implemented and the
> Kednos site was simply lifted and copied, never updated
> after that.
OK, I put in all 0's and it took it.

That should work for others, too.

I do remember some software that uses it to identify the processor.

Arne Vajhøj schrieb am Donnerstag, 14. September 2023 um 02:53:20 UTC+2:
> On 9/13/2023 4:53 PM, gah4 wrote:
> > On Wednesday, September 13, 2023 at 12:28:45 PM UTC-7, Arne Vajhøj wrote:
> > (snip, I wrote)
> >>> Does Alpha have 64 bit multiply and divide?
> >
> >> In instruction set?
> >
> >> Multiply: yes
> >
> > With 128 bit product?
> No.
Sorry Arne, but I would prefer to say yes.
Since Alpha can only deliver 64 bits per instruction, you have to use two of them:
MULQ for the lower 64 bits and then UMULQ for the upper 64 bits.
Andreas
> >> Division: no. But obviously you can divide two 64 bit integers in your
> >> favorite HLL.
> >
> > But PL/I allows for a scaling factor for FIXED BIN values.
> > That often requires a shift before the divide, so you really want a double
> > length dividend and product for divide and multiply instructions.
> >
> >>> I even forget now, does x86-64 hardware have multiply and divide with 128 bit
> >>> product and dividend?
> >
> >> I don't think so.
> >
> > It has been usual for a long time, for hardware to have multiply and divide with
> > double length product and dividend. Many algorithms depend on that, though few
> > HLLs have a way to do it. (Other than call an assembly language routine..)
> >
> > It seems that 64 bit processors don't all do it.
> Big integers in software is pretty standard today. You can get
> 128 or 245 or 512 or 1024 bit integers or whatever if you want to.
> In software. And on todays hardware it will be pretty fast anyway.
>
> Arne

On 2023-09-13, Tim Sneddon <tsneddon@panix.com> wrote:
>
> It took a while, but the IP has now moved to
> new hands and work is being done to port to x86-64.
>

Bloody hell Tim, you kept _that_ a secret. :-)

Others have focused on the "what". I am more interested in the "why".

Why are you investing in a port to x86-64 VMS ?

Is it simply because you want to do it, or because there are still some
large customers out there who want to see it happen and hence their
upcoming licence fees will pay for the port ?

Simon.

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

On 2023-09-14 13:18, Andreas Gruhl wrote:
> Arne Vajhøj schrieb am Donnerstag, 14. September 2023 um 02:53:20 UTC+2:
>> On 9/13/2023 4:53 PM, gah4 wrote:
>>> On Wednesday, September 13, 2023 at 12:28:45 PM UTC-7, Arne Vajhøj wrote:
>>> (snip, I wrote)
>>>>> Does Alpha have 64 bit multiply and divide?
>>>
>>>> In instruction set?
>>>
>>>> Multiply: yes
>>>
>>> With 128 bit product?
>> No.
> Sorry Arne, but I would prefer to say yes.
> Since Alpha can only deliver 64 bits per instruction, you have to use two of them:
> MULQ for the lower 64 bits and then UMULQ for the upper 64 bits.
> Andreas

It's UMULH, but I agree. The Alpha was definitely designed for getting a
128 bit result from 64 bit multiply. But it is done via two
instructions. MULQ;UMULH. If you want a signed MUL, you then need a
couple of more steps to adjust the result. But it's a simple thing.

Johnny

On 9/14/2023 4:32 AM, gah4 wrote:
> On Thursday, September 14, 2023 at 1:04:37 AM UTC-7, Tim Sneddon wrote:
> (snip, I wrote)
>>> Now all I have to do is get the MAC address for the form ...
>
>> Don't worry about that. I might actually remove the field
>> from the form. Checking that was never implemented and the
>> Kednos site was simply lifted and copied, never updated
>> after that.
>
> OK, I put in all 0's and it took it.
>
> That should work for others, too.
>
> I do remember some software that uses it to identify the processor.

SO do I.

Late 80's.

On a VAX where firmware updates changed the SID.

So that particular software was always down the day after
DEC upgraded firmware.

Arne

On 9/14/2023 10:38 AM, Johnny Billquist wrote:
> On 2023-09-14 13:18, Andreas Gruhl wrote:
>> Arne Vajhøj schrieb am Donnerstag, 14. September 2023 um 02:53:20 UTC+2:
>>> On 9/13/2023 4:53 PM, gah4 wrote:
>>>> On Wednesday, September 13, 2023 at 12:28:45 PM UTC-7, Arne Vajhøj
>>>> wrote:
>>>> (snip, I wrote)
>>>>>> Does Alpha have 64 bit multiply and divide?
>>>>
>>>>> In instruction set?
>>>>
>>>>> Multiply: yes
>>>>
>>>> With 128 bit product?
>>> No.
>> Sorry Arne, but I would prefer to say yes.
>> Since Alpha can only deliver 64 bits per instruction, you have to use
>> two of them:
>> MULQ for the lower 64 bits and then UMULQ for the upper 64 bits.
>
> It's UMULH, but I agree. The Alpha was definitely designed for getting a
> 128 bit result from 64 bit multiply. But it is done via two
> instructions. MULQ;UMULH. If you want a signed MUL, you then need a
> couple of more steps to adjust the result. But it's a simple thing.

So first a MULQ and then a UMULH works similar to how EMUL
worked on VAX?

(obviously 64 bit * 64 bit = 128 bit instead of 32 bit * 32 bit = 64 bit)

Looks like it.

$ type mul64.mar
.title m64
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry mul64,^m<>
emul 4(ap),8(ap),#0,@12(ap)
ret
.end
$ macro mul64

emul 4(ap),8(ap),#0,@12(ap)
^ %AMAC-I-MEMREFNOT, memory reference not naturally aligned in routine MUL64
at line number 4 in file DISK2:[ARNE]mul64.mar;1
$ type mul128.m64
$code_section
$routine mul128,kind=stack
mulq r16,r17,r22
stq r22,(r18)
umulh r16,r17,r23
stq r23,8(r18)
$return
$end_routine mul128
.end
$ macro/alpha mul128
$ type bigmul.c
#include <stdio.h>

void mul64(long int a, long int b, long int *c);
void mul128(long long int a, long long int b, long long int *c);

int main(int argc, char *argv[])
{ long int a32 = 0x40000000L;
long int b32 = 0x00000004L;
long int c64[2];
mul64(a32, b32, c64);
printf("%08X %08X\n", c64[1], c64[0]);
long long int a64 = 0x4000000000000000LL;
long long int b64 = 0x0000000000000004LL;
long long c128[2];
mul128(a64, b64, c128);
printf("%016LX %016LX\n", c128[1], c128[0]);
return 0;
} $ cc bigmul
$ link bigmul + mul64 + mul128
$ run bigmul
00000001 00000000
0000000000000001 0000000000000000

Arne

On Thursday, September 14, 2023 at 7:38:58 AM UTC-7, Johnny Billquist wrote:

(snip)

> It's UMULH, but I agree. The Alpha was definitely designed for getting a
> 128 bit result from 64 bit multiply. But it is done via two
> instructions. MULQ;UMULH. If you want a signed MUL, you then need a
> couple of more steps to adjust the result. But it's a simple thing.
Okay, I found my "Alpha Architecture Handbook", copyright 1992.

I think I got it before machines were available for sale.

And what I had forgotten, and might have known 31 years ago:
There is no hardware integer divide.

For divide by constant, you can usually, or maybe always, use the
high half of the double length product.

And for variable divide, they suggest, but don't write out, a successive
approximation algorithm. Presumably usually as a subroutine call.

There is floating point divide, though.

On 9/13/2023 8:53 PM, Arne Vajhøj wrote:
> Big integers in software is pretty standard today. You can get
> 128 or 245 or 512 or 1024 bit integers or whatever if you want to.
> In software. And on todays hardware it will be pretty fast anyway.

As an illustration of how big integers are used today, then
Java 19 added a new method to the BigInteger class - a
parallelMultiply to supplement multiply. That only makes
sense with a lots of bits. The example used in the
LinkedIn post where I saw it ended up with a 347084 bit
integer.

Arne

On 2023-09-15 03:17:31 +0000, gah4 said:

> On Thursday, September 14, 2023 at 7:38:58 AM UTC-7, Johnny Billquist wrote:
>
> (snip)
>
>> It's UMULH, but I agree. The Alpha was definitely designed for getting
>> a 128 bit result from 64 bit multiply. But it is done via two
>> instructions. MULQ;UMULH. If you want a signed MUL, you then need a
>> couple of more steps to adjust the result. But it's a simple
>> thing.Okay, I found my "Alpha Architecture Handbook", copyright 1992.
>
> I think I got it before machines were available for sale.
>
> And what I had forgotten, and might have known 31 years ago:
> There is no hardware integer divide.
> For divide by constant, you can usually, or maybe always, use the
> high half of the double length product.
> And for variable divide, they suggest, but don't write out, a successive
> approximation algorithm. Presumably usually as a subroutine call.
>
> There is floating point divide, though.

Invert and multiply, quite commonly.
See A.4.2 in SRM
http://bitsavers.org/pdf/dec/alpha/system_reference/Alpha_System_Reference_Manual_Version_5_199205.pdf

The Alpha Architecture Reference Manual (ARM) was a de-tuned version of
the Alpha System Reference Manual (SRM).

--
Pure Personal Opinion | HoffmanLabs LLC

On 2023-09-16 19:25, Stephen Hoffman wrote:
> On 2023-09-15 03:17:31 +0000, gah4 said:
>
>> On Thursday, September 14, 2023 at 7:38:58 AM UTC-7, Johnny Billquist
>> wrote:
>>
>> (snip)
>>
>>> It's UMULH, but I agree. The Alpha was definitely designed for
>>> getting a 128 bit result from 64 bit multiply. But it is done via two
>>> instructions. MULQ;UMULH. If you want a signed MUL, you then need a
>>> couple of more steps to adjust the result. But it's a simple
>>> thing.Okay, I found my "Alpha Architecture Handbook", copyright 1992.
>>
>> I think I got it before machines were available for sale.
>>
>> And what I had forgotten, and might have known 31 years ago:
>> There is no hardware integer divide.
>> For divide by constant, you can usually, or maybe always, use the
>> high half of the double length product.
>> And for variable divide, they suggest, but don't write out, a successive
>> approximation algorithm.  Presumably usually as a subroutine call.
>>
>> There is floating point divide, though.
>
> Invert and multiply, quite commonly.
> See A.4.2 in SRM
> http://bitsavers.org/pdf/dec/alpha/system_reference/Alpha_System_Reference_Manual_Version_5_199205.pdf
> The Alpha Architecture Reference Manual (ARM) was a de-tuned version of
> the Alpha System Reference Manual (SRM).

Inverting isn't really an option on integer arithmetic... But yes, for
FP it's definitely a thing.

But that manual also contains other good tricks for division. Which
sortof leads in the same direction as gah4 was suggesting.

Johnny