On 1/18/2022 10:41 PM, Sam Weiner wrote:
> In article <61e60705$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/17/2022 2:52 PM, Sam Weiner wrote:
>>> [smw] The Programmer's Guide which should be on sf.net is pretty good.
>>
>> I get the feeling that someone knows this product well.
>>
>> :-)
>
> [smw2] You could say that.
>
> [smw2] BTW, I was wrong about sf.net having the manuals. The wikipedia
> entry for "GT.M" does have a reference to where they are however. Enjoy.

Isn't it this one:

https://sourceforge.net/projects/fis-gtm/files/GT.M-x86-UNIX-ProgGuide/GT.MV4.4/

?

Arne

In article <61e8241d$0$699$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/18/2022 10:41 PM, Sam Weiner wrote:
>> In article <61e60705$0$701$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/17/2022 2:52 PM, Sam Weiner wrote:
>>>> [smw] The Programmer's Guide which should be on sf.net is pretty good.
>>>
>>> I get the feeling that someone knows this product well.
>>>
>>> :-)
>>
>> [smw2] You could say that.
>>
>> [smw2] BTW, I was wrong about sf.net having the manuals. The wikipedia
>> entry for "GT.M" does have a reference to where they are however. Enjoy.
>
>Isn't it this one:
>
>https://sourceforge.net/projects/fis-gtm/files/GT.M-x86-UNIX-ProgGuide/GT.MV4.4/

[smw3] While most of the M language features are the same for UNIX and OpenVMS,
the OpenVMS manual describes platform specific features.

Sam

On 1/19/2022 9:23 PM, Sam Weiner wrote:
> In article <61e8241d$0$699$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/18/2022 10:41 PM, Sam Weiner wrote:
>>> In article <61e60705$0$701$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/17/2022 2:52 PM, Sam Weiner wrote:
>>>>> [smw] The Programmer's Guide which should be on sf.net is pretty good.
>>>>
>>>> I get the feeling that someone knows this product well.
>>>>
>>>> :-)
>>>
>>> [smw2] You could say that.
>>>
>>> [smw2] BTW, I was wrong about sf.net having the manuals. The wikipedia
>>> entry for "GT.M" does have a reference to where they are however. Enjoy.
>>
>> Isn't it this one:
>>
>> https://sourceforge.net/projects/fis-gtm/files/GT.M-x86-UNIX-ProgGuide/GT.MV4.4/
>
> [smw3] While most of the M language features are the same for UNIX and OpenVMS,
> the OpenVMS manual describes platform specific features.

So:

http://tinco.pair.com/bhaskar/gtm/doc/books/pg/OpenVMS_manual/index.html

are better.

Arne

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
> On 2022-01-17, Arne Vajh?j <arne@vajhoej.dk> wrote:
>>
>> Separate compile and link is the VMS way ...
>>
>> I don't know how the compiled code looks like.
>>
>> It supports /LIST but not /LIST/MACH (well it accept the
>> /MACH but does not produce anything).
>>
>> Do we have a disassembler for VMS Alpha?
>>
>
> There's the srm_check utility Stephen likes to post about.
>
> If someone has built binutils for Alpha, try the objdump utility.
> (I don't know if objdump works for an Alpha target however. When I was
> playing with binutils for an Alpha VMS target, there were limitations
> in the Alpha VMS support in binutils).
>
> You can also use SDA or the debugger to disassemble an instruction sequence.

To answer my question the debugger would work fine. Now that
Arne has laid the groundwork I could do it myself, I guess!

Of course, the results of debugging optimized code can be interesting -
so I would of course use /DEBUG/NOOPT if it were Macro-32 .

Without that, though, Arne's example could be done:

$ <define logical for disabling decwindows in the debugger>
$ run/debug mumps_program

Then, at the debugger prompt, something like

STEP/CALL

(as necessary) to get to the first line of generated
code, then sequences of

STEP/INSTRUCTION

STEP/INTO

STEP/CALL

and, of course,

EXAMINE/INSTRUCTION <range>

[This is from memory. It's been awhile. I use a debugger include
file with shorthand for some of the heavily used commands.]

Oh, and I probably forgot

SET MODULE/ALL

at the beginning - assuming the image was linked with /debug.

George

> Simon.
>

Sam Weiner <weiner@shell02.theworld.com> wrote:
> In article <61e59077$0$699$14726298@news.sunsite.dk>,
> Arne Vajh??j <arne@vajhoej.dk> wrote:
>>On 1/17/2022 7:55 AM, George Cornelius wrote:
>>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>>>> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>>>>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>>>>> One may not like MUMPS and its variants.
>>>>>
>>>>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>>>>
>>>>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>>>>
>>>>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>>>>> 6.3 or 7.0).
>>>>>
>>>>> I have not tried it myself.
>>>>
>>>> Now I have. Hello world works.
>>>>
>>>> $ type test.m
>>>> hello()
>>>> write "Hello world from Mumps!",!
>>>> quit
>>>> $ mumps test
>>>> $ link test
>>>> $ r test
>>>> Hello world from Mumps!
>>>
>>> Congratulations!
>>>
>>> Though Greystone ran here for a number of years on AIX, I never
>>> bothered to ask for access to it, nor did I try to install it
>>> under VMS.
>>>
>>> Would be curious as to what the compiled code looks like, though.
>>>
>>> Greystone was unusual in that it generated object code. I suspect
>>> it was a lot of calls to subroutines. Or a bit of setup code followed
>>> by invoking an interpreter for, say, stack-machine code.
>>>
>>> If the latter, not sure why it would be necessary to have separate
>>> compilation - other environments just perform a hidden precompile -
>>> except that, if the language had the capability to call external
>>> routines, you could link those routines directly in with the compiled
>>> Mumps code and not have to have a special shared library of
>>> globally defined external routines [*],[**].
>>
>>Separate compile and link is the VMS way ...
>>
>>I don't know how the compiled code looks like.
>>
>>It supports /LIST but not /LIST/MACH (well it accept the
>>/MACH but does not produce anything).
>
> [smw] The machine list feature requires a debug build.
>
> [smw] The object code is largely, though not completely, calls into the
> runtime C code.
>
> [smw] You don't need to precompile the source to the M routines and
> "MUMPS /DIRECT" will get a prompt at which you can type M commands.
> "DO ^routine" will compile routine.m if needed and execute it.
>
> [smw] The Programmer's Guide which should be on sf.net is pretty good.

Thanks, Sam!

c.o.vms still has it: ask a question, get a discussion, then a day or
two later, a definitive answer from an expert.

George
>
> Sam
>
>>Do we have a disassembler for VMS Alpha?
>>
>>(never used one since DISM32 that was VMS VAX)
>>
>>Arne
>
>

George Cornelius <corneliu@eisner.decus.org> wrote:

> With regard to the standards committee: my organization had a seat
> on the Mumps Development Committee, which became an ASTM standards

Sorry, not ASTM but an ANSI committee.

> committee because the VA wanted their environment to run on a
> standardized language, and this was eventually elevated to a CCITT
> standards committee.

George