With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.

$ type hw.mar
..TITLE hello
..PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
HI: .ASCID /Hello, World!/
..PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
PUSHAQ HI
CALLS #1,G^LIB$PUT_OUTPUT
BLBC R0,10$
MOVL #SS$_NORMAL,R0
10$: RET
..END START
$ $ show system /noproc
OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
$ write sys$output f$getsyi("arch_name")
x86_64
$ macro hw
$ link hw
$ run hw
Hello, World!

On 2/19/2022 1:22 PM, John Reagan wrote:
> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>
> $ type hw.mar
> .TITLE hello
> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
> HI: .ASCID /Hello, World!/
> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
> PUSHAQ HI
> CALLS #1,G^LIB$PUT_OUTPUT
> BLBC R0,10$
> MOVL #SS$_NORMAL,R0
> 10$: RET
> .END START
> $
> $ show system /noproc
> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
> $ write sys$output f$getsyi("arch_name")
> x86_64
> $ macro hw
> $ link hw
> $ run hw
> Hello, World!
>
>

Great demo.

Now do it in Basic ...

:-)

Yeah, I know, you got some issues there.

And I'm wondering, is the LIB$PUT_OUTPUT native, or cross compiled?

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

In article <226d2c3c-996d-45f5-8c01-9fa650ae016dn@googlegroups.com>, John Reagan <xyzzy1959@gmail.com> writes:
>With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>
>$ type hw.mar
>..TITLE hello
>..PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>HI: .ASCID /Hello, World!/
>..PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>PUSHAQ HI
>CALLS #1,G^LIB$PUT_OUTPUT
>BLBC R0,10$
>MOVL #SS$_NORMAL,R0
>10$: RET
>..END START
>$
>$ show system /noproc
>OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>$ write sys$output f$getsyi("arch_name")
>x86_64
>$ macro hw
>$ link hw
>$ run hw
>Hello, World!

Macro is native! That's all I need!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

In article <surhbf$jt$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 2/19/2022 1:22 PM, John Reagan wrote:
>> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>>
>> $ type hw.mar
>> .TITLE hello
>> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>> HI: .ASCID /Hello, World!/
>> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>> PUSHAQ HI
>> CALLS #1,G^LIB$PUT_OUTPUT
>> BLBC R0,10$
>> MOVL #SS$_NORMAL,R0
>> 10$: RET
>> .END START
>> $
>> $ show system /noproc
>> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>> $ write sys$output f$getsyi("arch_name")
>> x86_64
>> $ macro hw
>> $ link hw
>> $ run hw
>> Hello, World!
>>
>>
>
>Great demo.

.... but not great Macro. ;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2/19/22 16:09, VAXman-@SendSpamHere.ORG wrote:
> In article <surhbf$jt$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>> On 2/19/2022 1:22 PM, John Reagan wrote:
>>> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>>>
>>> $ type hw.mar
>>> .TITLE hello
>>> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>>> HI: .ASCID /Hello, World!/
>>> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>>> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>>> PUSHAQ HI
>>> CALLS #1,G^LIB$PUT_OUTPUT
>>> BLBC R0,10$
>>> MOVL #SS$_NORMAL,R0
>>> 10$: RET
>>> .END START
>>> $
>>> $ show system /noproc
>>> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>>> $ write sys$output f$getsyi("arch_name")
>>> x86_64
>>> $ macro hw
>>> $ link hw
>>> $ run hw
>>> Hello, World!
>>>
>>>
>>
>> Great demo.
>
> ... but not great Macro. ;)
>

How's this for Macro?

.MCALL .PRINT .EXIT
MESG1: .ASCIZ " HELLO WORLD "
.EVEN
START:
.PRINT #MESG1
DONE:
; CLEAN UP AND GO BACK TO KMON
.EXIT
.END START

:-)

bill

On Saturday, February 19, 2022 at 2:44:50 PM UTC-5, Dave Froble wrote:
> On 2/19/2022 1:22 PM, John Reagan wrote:
> > With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
> >
> > $ type hw.mar
> > .TITLE hello
> > .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
> > HI: .ASCID /Hello, World!/
> > .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
> > START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
> > PUSHAQ HI
> > CALLS #1,G^LIB$PUT_OUTPUT
> > BLBC R0,10$
> > MOVL #SS$_NORMAL,R0
> > 10$: RET
> > .END START
> > $
> > $ show system /noproc
> > OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
> > $ write sys$output f$getsyi("arch_name")
> > x86_64
> > $ macro hw
> > $ link hw
> > $ run hw
> > Hello, World!
> >
> >
> Great demo.
>
> Now do it in Basic ...
>
> :-)
>
> Yeah, I know, you got some issues there.
>
> And I'm wondering, is the LIB$PUT_OUTPUT native, or cross compiled?
>
> --
> 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
The OS is still cross-built.

The native compilers are too new. We need more than just compilers to build the OS natively. I do have an early native SDL (written in C++) that can produce headers. I can show a BLISS compile in a day or so. Native C hopefully just a few weeks behind.

On Sunday, February 20, 2022 at 2:38:11 AM UTC, xyzz...@gmail.com wrote:
> On Saturday, February 19, 2022 at 2:44:50 PM UTC-5, Dave Froble wrote:
> The OS is still cross-built.
>
> The native compilers are too new. We need more than just compilers to build the OS natively. I do have an early native SDL (written in C++) that can produce headers. I can show a BLISS compile in a day or so. Native C hopefully just a few weeks behind.

that's good. C and a little macro32 covers what I want :-)

On 2022-02-19, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <226d2c3c-996d-45f5-8c01-9fa650ae016dn@googlegroups.com>, John Reagan <xyzzy1959@gmail.com> writes:
>>With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>>
>>$ type hw.mar
>>..TITLE hello
>>..PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>>HI: .ASCID /Hello, World!/
>>..PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>>START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>>PUSHAQ HI
>>CALLS #1,G^LIB$PUT_OUTPUT
>>BLBC R0,10$
>>MOVL #SS$_NORMAL,R0
>>10$: RET
>>..END START
>>$
>>$ show system /noproc
>>OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>>$ write sys$output f$getsyi("arch_name")
>>x86_64
>>$ macro hw
>>$ link hw
>>$ run hw
>>Hello, World!
>
> Macro is native! That's all I need!
>

$ set response/mode=good_natured_troll

Well, there's always that someone who needs to work with obsolete
languages... :-)

Simon.

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

On 2022-02-19, John Reagan <xyzzy1959@gmail.com> wrote:
> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>
> $ type hw.mar
> .TITLE hello
> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
> HI: .ASCID /Hello, World!/
> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
> PUSHAQ HI
> CALLS #1,G^LIB$PUT_OUTPUT
> BLBC R0,10$
> MOVL #SS$_NORMAL,R0
> 10$: RET
> .END START
> $
> $ show system /noproc
> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
> $ write sys$output f$getsyi("arch_name")
> x86_64
> $ macro hw
> $ link hw
> $ run hw
> Hello, World!
>

Is there any chance we can have a look at the generated code for this ?

Would be interesting to see what it looks like...

Simon.

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

In article <sv0ove$66b$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-02-19, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <226d2c3c-996d-45f5-8c01-9fa650ae016dn@googlegroups.com>, John Reagan <xyzzy1959@gmail.com> writes:
>>>With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>>>
>>>$ type hw.mar
>>>..TITLE hello
>>>..PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>>>HI: .ASCID /Hello, World!/
>>>..PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>>>START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>>>PUSHAQ HI
>>>CALLS #1,G^LIB$PUT_OUTPUT
>>>BLBC R0,10$
>>>MOVL #SS$_NORMAL,R0
>>>10$: RET
>>>..END START
>>>$
>>>$ show system /noproc
>>>OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>>>$ write sys$output f$getsyi("arch_name")
>>>x86_64
>>>$ macro hw
>>>$ link hw
>>>$ run hw
>>>Hello, World!
>>
>> Macro is native! That's all I need!
>>
>
>$ set response/mode=good_natured_troll
>
>Well, there's always that someone who needs to work with obsolete
>languages... :-)

Post hoc ergo propter hoc Romney Wordsworth!

It's not obsolete. I don't write *applications* or fiddle with stuff access
via the WWW.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
> On 2022-02-19, John Reagan <xyzz...@gmail.com> wrote:
> > With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
> >
> > $ type hw.mar
> > .TITLE hello
> > .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
> > HI: .ASCID /Hello, World!/
> > .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
> > START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
> > PUSHAQ HI
> > CALLS #1,G^LIB$PUT_OUTPUT
> > BLBC R0,10$
> > MOVL #SS$_NORMAL,R0
> > 10$: RET
> > .END START
> > $
> > $ show system /noproc
> > OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
> > $ write sys$output f$getsyi("arch_name")
> > x86_64
> > $ macro hw
> > $ link hw
> > $ run hw
> > Hello, World!
> >
> Is there any chance we can have a look at the generated code for this ?
>
> Would be interesting to see what it looks like...
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
.text
.cfi_sections .eh_frame
.globl LIB$PUT_OUTPUT
.globl SS$_NORMAL
.globl ELF$TFRADR
..set ELF$TFRADR, START
.file 1 "DKA100:[JREAGAN]HW.MAR;2"
.section CODE,"ax",@progbits
.globl START
.type START,@function
.p2align 4, 0x90
START:
.cfi_startproc

# Prologue code for routine START on line 5
.loc 1 5 0 is_stmt 0 # DKA100:[JREAGAN]HW.MAR;2:5:0
pushq %rbp # encoding: [0x55]
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp # encoding: [0x48,0x89,0xe5]
.cfi_def_cfa_register %rbp
pushq %rbx # encoding: [0x53]
.cfi_offset %rbx, -24
pushq %r15 # encoding: [0x41,0x57]
.cfi_offset %r15, -32
pushq %r14 # encoding: [0x41,0x56]
.cfi_offset %r14, -40
pushq %r13 # encoding: [0x41,0x55]
.cfi_offset %r13, -48
movzbl %ah, %ebx # encoding: [0x0f,0xb6,0xdc]
callq LIB$ALPHA_REG_VECTOR_BASE@PLT # encoding: [0xe8,A,A,A,A]
# fixup A - offset: 1, value: LIB$ALPHA_REG_VECTOR_BASE@PLT-4, kind: FK_PCRel_4
xchgq %rbx, %rax # encoding: [0x48,0x93]
pushq %r12 # encoding: [0x41,0x54]
.cfi_offset %r12, -56
addq $-40, %rsp # encoding: [0x48,0x83,0xc4,0xd8]
movl %r9d, 24(%rsp) # encoding: [0x44,0x89,0x4c,0x24,0x18]
movl %r8d, 20(%rsp) # encoding: [0x44,0x89,0x44,0x24,0x14]
movl %ecx, 16(%rsp) # encoding: [0x89,0x4c,0x24,0x10]
movl %edx, 12(%rsp) # encoding: [0x89,0x54,0x24,0x0c]
movl %esi, 8(%rsp) # encoding: [0x89,0x74,0x24,0x08]
movl %edi, 4(%rsp) # encoding: [0x89,0x7c,0x24,0x04]
movl %eax, (%rsp) # encoding: [0x89,0x04,0x24]
movq %rsp, %r12 # encoding: [0x49,0x89,0xe4]
.loc 1 5 0 prologue_end # DKA100:[JREAGAN]HW.MAR;2:5:0
_$$L1:

# Processing instruction PUSHAQ on line 6
.loc 1 58 0 # DKA100:[JREAGAN]HW.MAR;2:58:0
movq _$$PSECT_BASE3@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
# fixup A - offset: 3, value: _$$PSECT_BASE3@GOTPCREL-4, kind: reloc_riprel_4byte_movq_loa
d pushq %r10 # encoding: [0x41,0x52]

# Processing instruction CALLS on line 7
.loc 1 59 0 # DKA100:[JREAGAN]HW.MAR;2:59:0
popq %rdi # encoding: [0x5f]
movq $256, %rax # encoding: [0x48,0xc7,0xc0,0x00,0x01,0x00,0x00]
# imm = 0x100
callq LIB$PUT_OUTPUT@PLT # encoding: [0xe8,A,A,A,A]
# fixup A - offset: 1, value: LIB$PUT_OUTPUT@PLT-4, kind: FK_PCRel_4
movq %rax, (%rbx) # encoding: [0x48,0x89,0x03]
movq %rdx, 8(%rbx) # encoding: [0x48,0x89,0x53,0x08]

# Processing instruction BLBC on line 8
.loc 1 60 0 # DKA100:[JREAGAN]HW.MAR;2:60:0
btq $0, (%rbx) # encoding: [0x48,0x0f,0xba,0x23,0x00]
jae 5_10$ # encoding: [0x0f,0x83,A,A,A,A]
# fixup A - offset: 2, value: 5_10$-4, kind: FK_PCRel_4

# Processing instruction MOVL on line 9
.loc 1 61 0 # DKA100:[JREAGAN]HW.MAR;2:61:0
movq SS$_NORMAL@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
# fixup A - offset: 3, value: SS$_NORMAL@GOTPCREL-4, kind: reloc_riprel_4byte_movq_load
movq %r10, (%rbx) # encoding: [0x4c,0x89,0x13]
5_10$:

# Processing instruction RET on line 10
.loc 1 62 0 # DKA100:[JREAGAN]HW.MAR;2:62:0
_$$_0:
.loc 1 62 0 epilogue_begin # DKA100:[JREAGAN]HW.MAR;2:62:0
leaq -40(%rbp), %rsp # encoding: [0x48,0x8d,0x65,0xd8]
andb $-2, 240(%rbx) # encoding: [0x80,0xa3,0xf0,0x00,0x00,0x00,0xfe]
movq (%rbx), %rax # encoding: [0x48,0x8b,0x03]
movq 8(%rbx), %rdx # encoding: [0x48,0x8b,0x53,0x08]
popq %r12 # encoding: [0x41,0x5c]
.cfi_restore %r12
popq %r13 # encoding: [0x41,0x5d]
.cfi_restore %r13
popq %r14 # encoding: [0x41,0x5e]
.cfi_restore %r14
popq %r15 # encoding: [0x41,0x5f]
.cfi_restore %r15
popq %rbx # encoding: [0x5b]
.cfi_restore %rbx
popq %rbp # encoding: [0x5d]
.cfi_restore %rbp
.cfi_def_cfa %rsp, 8
retq # encoding: [0xc3]
_$$_2:
.size START, _$$_2-START
.cfi_endproc
.section ". ABS .","a",@progbits
.section ". BLANK .","axw",@progbits
.section RDATA,"a",@progbits
.type _$$PSECT_BASE3,@object
_$$PSECT_BASE3:
.type HI,@object
HI:
.short 13
.byte 14
.byte 1
.long 0_0$
.type 0_0$,@object
0_0$:
.ascii "Hello, World!"
.section .note,"",@note
.quad 8
.quad 43
.quad 1
.ascii "IPF/VMS"
.byte 0
.ascii "19-FEB-2022 13:12"
.ascii "19-FEB-2022 13:12"
.ascii "HELLO"
.byte 0
.ascii "V1"
.byte 0
.p2align 3
.quad 8
.quad 14
.quad 2
.ascii "IPF/VMS"
.byte 0
.ascii "XMAC X6.0-109"
.byte 0
.p2align 3

On 2/21/22 8:01 PM, John Reagan wrote:
> On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
>> On 2022-02-19, John Reagan <xyzz...@gmail.com> wrote:
>>> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
>>>
>>> $ type hw.mar
>>> .TITLE hello
>>> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
>>> HI: .ASCID /Hello, World!/
>>> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
>>> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
>>> PUSHAQ HI
>>> CALLS #1,G^LIB$PUT_OUTPUT
>>> BLBC R0,10$
>>> MOVL #SS$_NORMAL,R0
>>> 10$: RET
>>> .END START
>>> $
>>> $ show system /noproc
>>> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
>>> $ write sys$output f$getsyi("arch_name")
>>> x86_64
>>> $ macro hw
>>> $ link hw
>>> $ run hw
>>> Hello, World!
>>>
>> Is there any chance we can have a look at the generated code for this ?
>>
>> Would be interesting to see what it looks like...
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> .text
> .cfi_sections .eh_frame
> .globl LIB$PUT_OUTPUT
> .globl SS$_NORMAL
> .globl ELF$TFRADR
> .set ELF$TFRADR, START
> .file 1 "DKA100:[JREAGAN]HW.MAR;2"
> .section CODE,"ax",@progbits
> .globl START
> .type START,@function
> .p2align 4, 0x90
> START:
> .cfi_startproc
>
> # Prologue code for routine START on line 5
> .loc 1 5 0 is_stmt 0 # DKA100:[JREAGAN]HW.MAR;2:5:0
> pushq %rbp # encoding: [0x55]
> .cfi_def_cfa_offset 16
> .cfi_offset %rbp, -16
> movq %rsp, %rbp # encoding: [0x48,0x89,0xe5]
> .cfi_def_cfa_register %rbp
> pushq %rbx # encoding: [0x53]
> .cfi_offset %rbx, -24
> pushq %r15 # encoding: [0x41,0x57]
> .cfi_offset %r15, -32
> pushq %r14 # encoding: [0x41,0x56]
> .cfi_offset %r14, -40
> pushq %r13 # encoding: [0x41,0x55]
> .cfi_offset %r13, -48
> movzbl %ah, %ebx # encoding: [0x0f,0xb6,0xdc]
> callq LIB$ALPHA_REG_VECTOR_BASE@PLT # encoding: [0xe8,A,A,A,A]
> # fixup A - offset: 1, value: LIB$ALPHA_REG_VECTOR_BASE@PLT-4, kind: FK_PCRel_4
> xchgq %rbx, %rax # encoding: [0x48,0x93]
> pushq %r12 # encoding: [0x41,0x54]
> .cfi_offset %r12, -56
> addq $-40, %rsp # encoding: [0x48,0x83,0xc4,0xd8]
> movl %r9d, 24(%rsp) # encoding: [0x44,0x89,0x4c,0x24,0x18]
> movl %r8d, 20(%rsp) # encoding: [0x44,0x89,0x44,0x24,0x14]
> movl %ecx, 16(%rsp) # encoding: [0x89,0x4c,0x24,0x10]
> movl %edx, 12(%rsp) # encoding: [0x89,0x54,0x24,0x0c]
> movl %esi, 8(%rsp) # encoding: [0x89,0x74,0x24,0x08]
> movl %edi, 4(%rsp) # encoding: [0x89,0x7c,0x24,0x04]
> movl %eax, (%rsp) # encoding: [0x89,0x04,0x24]
> movq %rsp, %r12 # encoding: [0x49,0x89,0xe4]
> .loc 1 5 0 prologue_end # DKA100:[JREAGAN]HW.MAR;2:5:0
> _$$L1:
>
> # Processing instruction PUSHAQ on line 6
> .loc 1 58 0 # DKA100:[JREAGAN]HW.MAR;2:58:0
> movq _$$PSECT_BASE3@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
> # fixup A - offset: 3, value: _$$PSECT_BASE3@GOTPCREL-4, kind: reloc_riprel_4byte_movq_loa
> d
> pushq %r10 # encoding: [0x41,0x52]
>
> # Processing instruction CALLS on line 7
> .loc 1 59 0 # DKA100:[JREAGAN]HW.MAR;2:59:0
> popq %rdi # encoding: [0x5f]
> movq $256, %rax # encoding: [0x48,0xc7,0xc0,0x00,0x01,0x00,0x00]
> # imm = 0x100
> callq LIB$PUT_OUTPUT@PLT # encoding: [0xe8,A,A,A,A]
> # fixup A - offset: 1, value: LIB$PUT_OUTPUT@PLT-4, kind: FK_PCRel_4
> movq %rax, (%rbx) # encoding: [0x48,0x89,0x03]
> movq %rdx, 8(%rbx) # encoding: [0x48,0x89,0x53,0x08]
>
> # Processing instruction BLBC on line 8
> .loc 1 60 0 # DKA100:[JREAGAN]HW.MAR;2:60:0
> btq $0, (%rbx) # encoding: [0x48,0x0f,0xba,0x23,0x00]
> jae 5_10$ # encoding: [0x0f,0x83,A,A,A,A]
> # fixup A - offset: 2, value: 5_10$-4, kind: FK_PCRel_4
>
> # Processing instruction MOVL on line 9
> .loc 1 61 0 # DKA100:[JREAGAN]HW.MAR;2:61:0
> movq SS$_NORMAL@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
> # fixup A - offset: 3, value: SS$_NORMAL@GOTPCREL-4, kind: reloc_riprel_4byte_movq_load
> movq %r10, (%rbx) # encoding: [0x4c,0x89,0x13]
> 5_10$:
>
> # Processing instruction RET on line 10
> .loc 1 62 0 # DKA100:[JREAGAN]HW.MAR;2:62:0
> _$$_0:
> .loc 1 62 0 epilogue_begin # DKA100:[JREAGAN]HW.MAR;2:62:0
> leaq -40(%rbp), %rsp # encoding: [0x48,0x8d,0x65,0xd8]
> andb $-2, 240(%rbx) # encoding: [0x80,0xa3,0xf0,0x00,0x00,0x00,0xfe]
> movq (%rbx), %rax # encoding: [0x48,0x8b,0x03]
> movq 8(%rbx), %rdx # encoding: [0x48,0x8b,0x53,0x08]
> popq %r12 # encoding: [0x41,0x5c]
> .cfi_restore %r12
> popq %r13 # encoding: [0x41,0x5d]
> .cfi_restore %r13
> popq %r14 # encoding: [0x41,0x5e]
> .cfi_restore %r14
> popq %r15 # encoding: [0x41,0x5f]
> .cfi_restore %r15
> popq %rbx # encoding: [0x5b]
> .cfi_restore %rbx
> popq %rbp # encoding: [0x5d]
> .cfi_restore %rbp
> .cfi_def_cfa %rsp, 8
> retq # encoding: [0xc3]
> _$$_2:
> .size START, _$$_2-START
> .cfi_endproc
> .section ". ABS .","a",@progbits
> .section ". BLANK .","axw",@progbits
> .section RDATA,"a",@progbits
> .type _$$PSECT_BASE3,@object
> _$$PSECT_BASE3:
> .type HI,@object
> HI:
> .short 13
> .byte 14
> .byte 1
> .long 0_0$
> .type 0_0$,@object
> 0_0$:
> .ascii "Hello, World!"
> .section .note,"",@note
> .quad 8
> .quad 43
> .quad 1
> .ascii "IPF/VMS"
> .byte 0
> .ascii "19-FEB-2022 13:12"
> .ascii "19-FEB-2022 13:12"
> .ascii "HELLO"
> .byte 0
> .ascii "V1"
> .byte 0
> .p2align 3
> .quad 8
> .quad 14
> .quad 2
> .ascii "IPF/VMS"
> .byte 0
> .ascii "XMAC X6.0-109"
> .byte 0
> .p2align 3

Cool. Now we just need MACRO-32 added as one of the source languages here:

https://godbolt.org

On Monday, February 21, 2022 at 9:52:36 PM UTC-5, Craig A. Berry wrote:
> On 2/21/22 8:01 PM, John Reagan wrote:
> > On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
> >> On 2022-02-19, John Reagan <xyzz...@gmail.com> wrote:
> >>> With all the various threads talking about compilers and such, here's a "demo" (compilers are hard to demo) of a the native Macro compiler.
> >>>
> >>> $ type hw.mar
> >>> .TITLE hello
> >>> .PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
> >>> HI: .ASCID /Hello, World!/
> >>> .PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
> >>> START:: .CALL_ENTRY PRESERVE=<>,MAX_ARGS=0,HOME_ARGS=TRUE
> >>> PUSHAQ HI
> >>> CALLS #1,G^LIB$PUT_OUTPUT
> >>> BLBC R0,10$
> >>> MOVL #SS$_NORMAL,R0
> >>> 10$: RET
> >>> .END START
> >>> $
> >>> $ show system /noproc
> >>> OpenVMS XG5P-H4S on node X86VMS 19-FEB-2022 13:09:56.72 Uptime 2 03:28:17
> >>> $ write sys$output f$getsyi("arch_name")
> >>> x86_64
> >>> $ macro hw
> >>> $ link hw
> >>> $ run hw
> >>> Hello, World!
> >>>
> >> Is there any chance we can have a look at the generated code for this ?
> >>
> >> Would be interesting to see what it looks like...
> >> Simon.
> >>
> >> --
> >> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> >> Walking destinations on a map are further away than they appear.
> > .text
> > .cfi_sections .eh_frame
> > .globl LIB$PUT_OUTPUT
> > .globl SS$_NORMAL
> > .globl ELF$TFRADR
> > .set ELF$TFRADR, START
> > .file 1 "DKA100:[JREAGAN]HW.MAR;2"
> > .section CODE,"ax",@progbits
> > .globl START
> > .type START,@function
> > .p2align 4, 0x90
> > START:
> > .cfi_startproc
> >
> > # Prologue code for routine START on line 5
> > .loc 1 5 0 is_stmt 0 # DKA100:[JREAGAN]HW.MAR;2:5:0
> > pushq %rbp # encoding: [0x55]
> > .cfi_def_cfa_offset 16
> > .cfi_offset %rbp, -16
> > movq %rsp, %rbp # encoding: [0x48,0x89,0xe5]
> > .cfi_def_cfa_register %rbp
> > pushq %rbx # encoding: [0x53]
> > .cfi_offset %rbx, -24
> > pushq %r15 # encoding: [0x41,0x57]
> > .cfi_offset %r15, -32
> > pushq %r14 # encoding: [0x41,0x56]
> > .cfi_offset %r14, -40
> > pushq %r13 # encoding: [0x41,0x55]
> > .cfi_offset %r13, -48
> > movzbl %ah, %ebx # encoding: [0x0f,0xb6,0xdc]
> > callq LIB$ALPHA_REG_VECTOR_BASE@PLT # encoding: [0xe8,A,A,A,A]
> > # fixup A - offset: 1, value: LIB$ALPHA_REG_VECTOR_BASE@PLT-4, kind: FK_PCRel_4
> > xchgq %rbx, %rax # encoding: [0x48,0x93]
> > pushq %r12 # encoding: [0x41,0x54]
> > .cfi_offset %r12, -56
> > addq $-40, %rsp # encoding: [0x48,0x83,0xc4,0xd8]
> > movl %r9d, 24(%rsp) # encoding: [0x44,0x89,0x4c,0x24,0x18]
> > movl %r8d, 20(%rsp) # encoding: [0x44,0x89,0x44,0x24,0x14]
> > movl %ecx, 16(%rsp) # encoding: [0x89,0x4c,0x24,0x10]
> > movl %edx, 12(%rsp) # encoding: [0x89,0x54,0x24,0x0c]
> > movl %esi, 8(%rsp) # encoding: [0x89,0x74,0x24,0x08]
> > movl %edi, 4(%rsp) # encoding: [0x89,0x7c,0x24,0x04]
> > movl %eax, (%rsp) # encoding: [0x89,0x04,0x24]
> > movq %rsp, %r12 # encoding: [0x49,0x89,0xe4]
> > .loc 1 5 0 prologue_end # DKA100:[JREAGAN]HW.MAR;2:5:0
> > _$$L1:
> >
> > # Processing instruction PUSHAQ on line 6
> > .loc 1 58 0 # DKA100:[JREAGAN]HW.MAR;2:58:0
> > movq _$$PSECT_BASE3@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
> > # fixup A - offset: 3, value: _$$PSECT_BASE3@GOTPCREL-4, kind: reloc_riprel_4byte_movq_loa
> > d
> > pushq %r10 # encoding: [0x41,0x52]
> >
> > # Processing instruction CALLS on line 7
> > .loc 1 59 0 # DKA100:[JREAGAN]HW.MAR;2:59:0
> > popq %rdi # encoding: [0x5f]
> > movq $256, %rax # encoding: [0x48,0xc7,0xc0,0x00,0x01,0x00,0x00]
> > # imm = 0x100
> > callq LIB$PUT_OUTPUT@PLT # encoding: [0xe8,A,A,A,A]
> > # fixup A - offset: 1, value: LIB$PUT_OUTPUT@PLT-4, kind: FK_PCRel_4
> > movq %rax, (%rbx) # encoding: [0x48,0x89,0x03]
> > movq %rdx, 8(%rbx) # encoding: [0x48,0x89,0x53,0x08]
> >
> > # Processing instruction BLBC on line 8
> > .loc 1 60 0 # DKA100:[JREAGAN]HW.MAR;2:60:0
> > btq $0, (%rbx) # encoding: [0x48,0x0f,0xba,0x23,0x00]
> > jae 5_10$ # encoding: [0x0f,0x83,A,A,A,A]
> > # fixup A - offset: 2, value: 5_10$-4, kind: FK_PCRel_4
> >
> > # Processing instruction MOVL on line 9
> > .loc 1 61 0 # DKA100:[JREAGAN]HW.MAR;2:61:0
> > movq SS$_NORMAL@GOTPCREL(%rip), %r10 # encoding: [0x4c,0x8b,0x15,A,A,A,A]
> > # fixup A - offset: 3, value: SS$_NORMAL@GOTPCREL-4, kind: reloc_riprel_4byte_movq_load
> > movq %r10, (%rbx) # encoding: [0x4c,0x89,0x13]
> > 5_10$:
> >
> > # Processing instruction RET on line 10
> > .loc 1 62 0 # DKA100:[JREAGAN]HW.MAR;2:62:0
> > _$$_0:
> > .loc 1 62 0 epilogue_begin # DKA100:[JREAGAN]HW.MAR;2:62:0
> > leaq -40(%rbp), %rsp # encoding: [0x48,0x8d,0x65,0xd8]
> > andb $-2, 240(%rbx) # encoding: [0x80,0xa3,0xf0,0x00,0x00,0x00,0xfe]
> > movq (%rbx), %rax # encoding: [0x48,0x8b,0x03]
> > movq 8(%rbx), %rdx # encoding: [0x48,0x8b,0x53,0x08]
> > popq %r12 # encoding: [0x41,0x5c]
> > .cfi_restore %r12
> > popq %r13 # encoding: [0x41,0x5d]
> > .cfi_restore %r13
> > popq %r14 # encoding: [0x41,0x5e]
> > .cfi_restore %r14
> > popq %r15 # encoding: [0x41,0x5f]
> > .cfi_restore %r15
> > popq %rbx # encoding: [0x5b]
> > .cfi_restore %rbx
> > popq %rbp # encoding: [0x5d]
> > .cfi_restore %rbp
> > .cfi_def_cfa %rsp, 8
> > retq # encoding: [0xc3]
> > _$$_2:
> > .size START, _$$_2-START
> > .cfi_endproc
> > .section ". ABS .","a",@progbits
> > .section ". BLANK .","axw",@progbits
> > .section RDATA,"a",@progbits
> > .type _$$PSECT_BASE3,@object
> > _$$PSECT_BASE3:
> > .type HI,@object
> > HI:
> > .short 13
> > .byte 14
> > .byte 1
> > .long 0_0$
> > .type 0_0$,@object
> > 0_0$:
> > .ascii "Hello, World!"
> > .section .note,"",@note
> > .quad 8
> > .quad 43
> > .quad 1
> > .ascii "IPF/VMS"
> > .byte 0
> > .ascii "19-FEB-2022 13:12"
> > .ascii "19-FEB-2022 13:12"
> > .ascii "HELLO"
> > .byte 0
> > .ascii "V1"
> > .byte 0
> > .p2align 3
> > .quad 8
> > .quad 14
> > .quad 2
> > .ascii "IPF/VMS"
> > .byte 0
> > .ascii "XMAC X6.0-109"
> > .byte 0
> > .p2align 3
> Cool. Now we just need MACRO-32 added as one of the source languages here:
>
> https://godbolt.org
I'm a Patreon of Matt's. He runs all of his systems on AWS. However, I doubt he'll want to spin up an OpenVMS x86 system when available.

And hosting Macro-32 on a Linux system comes with its own unique nightmare. MLB files. Macro has no real include file system. You get plus-list on the DCL command and macro expansions with MLB files. Both would be a challenge with a Linux-hosted compiler.

On 2022-02-22 06:27, John Reagan wrote:
> On Monday, February 21, 2022 at 9:52:36 PM UTC-5, Craig A. Berry wrote:
>> Cool. Now we just need MACRO-32 added as one of the source languages here:
>>
>> https://godbolt.org
> I'm a Patreon of Matt's. He runs all of his systems on AWS. However, I doubt he'll want to spin up an OpenVMS x86 system when available.
>
> And hosting Macro-32 on a Linux system comes with its own unique nightmare. MLB files. Macro has no real include file system. You get plus-list on the DCL command and macro expansions with MLB files. Both would be a challenge with a Linux-hosted compiler.

Uh? What? Either I am confused, or you are.
..INCLUDE /whatever/
should work just fine. It's not that Macro-32 don't have an include file
system. It's just that it's not the only thing it has. It *also* have
libraries, which is something Unix compilers usually lack when we talk
about source side.

Or at least this is what I *know* is true in Macro-11, and while it's
been quite a while since I played with Macro-32, I'm fairly certain it's
the same there.

The ability to have libraries also for source code like macros, is
really nice. But yes, it would be a headache to deal with on systems
that don't currently have it, because you'll have to implement it in
your compiler. But hey, Macro-32 as a compiler is already your own code,
so having the capability to deal with libraries shouldn't be that hard.
But then you also want a tool to be able to manipulate these
libraries... More work...

Johnny

In article <sv2i58$a5h$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>{...snip..}
>Uh? What? Either I am confused, or you are.
>..INCLUDE /whatever/
>should work just fine. It's not that Macro-32 don't have an include file
>system. It's just that it's not the only thing it has. It *also* have
>libraries, which is something Unix compilers usually lack when we talk
>about source side.

There is no .INCLUDE directive in Macro-32! It is not referenced in the
VAX Macro LRM either. Adding a ".INCLUDE /whatever/" elicits the error:

.INCLUDE /whatever/
^ %AMAC-E-UNRECSTMT, unrecognized statement
at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3

>Or at least this is what I *know* is true in Macro-11, and while it's
>been quite a while since I played with Macro-32, I'm fairly certain it's
>the same there.

'Tis not!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Tuesday, February 22, 2022 at 6:41:30 AM UTC-5, Johnny Billquist wrote:
> On 2022-02-22 06:27, John Reagan wrote:
> > On Monday, February 21, 2022 at 9:52:36 PM UTC-5, Craig A. Berry wrote:
> >> Cool. Now we just need MACRO-32 added as one of the source languages here:
> >>
> >> https://godbolt.org
> > I'm a Patreon of Matt's. He runs all of his systems on AWS. However, I doubt he'll want to spin up an OpenVMS x86 system when available.
> >
> > And hosting Macro-32 on a Linux system comes with its own unique nightmare. MLB files. Macro has no real include file system. You get plus-list on the DCL command and macro expansions with MLB files. Both would be a challenge with a Linux-hosted compiler.
> Uh? What? Either I am confused, or you are.
> .INCLUDE /whatever/
> should work just fine. It's not that Macro-32 don't have an include file
> system. It's just that it's not the only thing it has. It *also* have
> libraries, which is something Unix compilers usually lack when we talk
> about source side.
>
> Or at least this is what I *know* is true in Macro-11, and while it's
> been quite a while since I played with Macro-32, I'm fairly certain it's
> the same there.
>
> The ability to have libraries also for source code like macros, is
> really nice. But yes, it would be a headache to deal with on systems
> that don't currently have it, because you'll have to implement it in
> your compiler. But hey, Macro-32 as a compiler is already your own code,
> so having the capability to deal with libraries shouldn't be that hard.
> But then you also want a tool to be able to manipulate these
> libraries... More work...
>
> Johnny
The Macro compiler uses GEM for all of its I/O (just like all the other compilers).
For macros, we call the callable librarian to find the macro and return the records.
Anyone with a sizable Macro-32 application must be using LIBR/MACRO and adding
"lib.MLB/LIBRARY" on the command line as plus-list. Having a Linux-hosted Macro-32
has more issues than Linux-hosted BLISS (which existed in the past).

As for something on godbolt.org could use, none of that would be required for a quick
10 line example.

On 2022-02-21, John Reagan <xyzzy1959@gmail.com> wrote:
> On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
>> Is there any chance we can have a look at the generated code for this ?
>>
>> Would be interesting to see what it looks like...
> .text
> .cfi_sections .eh_frame
> .globl LIB$PUT_OUTPUT
> .globl SS$_NORMAL
> .globl ELF$TFRADR
> .set ELF$TFRADR, START
> .file 1 "DKA100:[JREAGAN]HW.MAR;2"
> .section CODE,"ax",@progbits
> .globl START
> .type START,@function
> .p2align 4, 0x90
> START:
> .cfi_startproc

[snip example]

Thank you for posting the example John.

It's nice having a greater number of registers to work with than
the traditional Intel x86 architecture isn't it ? :-)

Simon.

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

On Tuesday, February 22, 2022 at 1:59:37 PM UTC-5, Simon Clubley wrote:
> On 2022-02-21, John Reagan <xyzz...@gmail.com> wrote:
> > On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
> >> Is there any chance we can have a look at the generated code for this ?
> >>
> >> Would be interesting to see what it looks like...
> > .text
> > .cfi_sections .eh_frame
> > .globl LIB$PUT_OUTPUT
> > .globl SS$_NORMAL
> > .globl ELF$TFRADR
> > .set ELF$TFRADR, START
> > .file 1 "DKA100:[JREAGAN]HW.MAR;2"
> > .section CODE,"ax",@progbits
> > .globl START
> > .type START,@function
> > .p2align 4, 0x90
> > START:
> > .cfi_startproc
> [snip example]
>
> Thank you for posting the example John.
>
> It's nice having a greater number of registers to work with than
> the traditional Intel x86 architecture isn't it ? :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
~8 vs ~16 Ugh. Compared to Alpha's 32 and Itanium's 128.

However, gcc has lived forever in this environment with putting variables on the
stack and hoping that the cache saves the day.

On 2/22/2022 3:28 PM, John Reagan wrote:
> On Tuesday, February 22, 2022 at 1:59:37 PM UTC-5, Simon Clubley wrote:
>> On 2022-02-21, John Reagan <xyzz...@gmail.com> wrote:
>>> On Monday, February 21, 2022 at 2:26:44 PM UTC-5, Simon Clubley wrote:
>>>> Is there any chance we can have a look at the generated code for this ?
>>>>
>>>> Would be interesting to see what it looks like...
>>> .text
>>> .cfi_sections .eh_frame
>>> .globl LIB$PUT_OUTPUT
>>> .globl SS$_NORMAL
>>> .globl ELF$TFRADR
>>> .set ELF$TFRADR, START
>>> .file 1 "DKA100:[JREAGAN]HW.MAR;2"
>>> .section CODE,"ax",@progbits
>>> .globl START
>>> .type START,@function
>>> .p2align 4, 0x90
>>> START:
>>> .cfi_startproc
>> [snip example]
>>
>> Thank you for posting the example John.
>>
>> It's nice having a greater number of registers to work with than
>> the traditional Intel x86 architecture isn't it ? :-)

> ~8 vs ~16 Ugh. Compared to Alpha's 32 and Itanium's 128.
>
> However, gcc has lived forever in this environment with putting variables on the
> stack and hoping that the cache saves the day.

Ice Lake's got 48 KB data L1 and 1.25 MB L2 per core.

Arne

On Tue, 22 Feb 2022 12:28:33 -0800, John Reagan wrote:

> ~8 vs ~16 Ugh. Compared to Alpha's 32 and Itanium's 128.
>
> However, gcc has lived forever in this environment with putting
> variables on the stack and hoping that the cache saves the day.

I'm just writing a simulator for a single register mainframe (OK, it also
has an index register). Heavily cached stack.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 2/21/22 11:27 PM, John Reagan wrote:
> On Monday, February 21, 2022 at 9:52:36 PM UTC-5, Craig A. Berry wrote:

>> Cool. Now we just need MACRO-32 added as one of the source languages here:
>>
>> https://godbolt.org

> I'm a Patron of Matt's. He runs all of his systems on AWS. However,
> I doubt he'll want to spin up an OpenVMS x86 system when available.

It doesn't have to be him -- the code is open source and anyone can run
their own:

https://github.com/compiler-explorer/compiler-explorer

I was sort of kidding, but having one for the DEC compilers is not
/that/ crazy a thought, although apparently it requires Node, so one
would either need to port the V8 Javascript engine and Node to VMS or
suss out the details of how a remote server receives a program to
compile, compiles it, and sends the results back. The latter is
probably equivalent to what the VMS IDE in VSCode is doing. Basically
it would involve implementing the REST API documented here:

<https://github.com/compiler-explorer/compiler-explorer/blob/main/docs/API.md>

> And hosting Macro-32 on a Linux system comes with its own unique
> nightmare. MLB files. Macro has no real include file system. You
> get plus-list on the DCL command and macro expansions with MLB files.
> Both would be a challenge with a Linux-hosted compiler.
That sounds painful. More painful than porting Node ;-).

None of this is meant as yet another "VSI must do this to save the
world," etc. Just something I stumbled on that looked interesting.
Plus, if it were so easy to try out test programs in any and every
language, the newsgroup would die off because people would no longer
have an excuse to pile hate on languages they don't know anything about :-).

On 2022-02-22 16:06, VAXman-@SendSpamHere.ORG wrote:
> In article <sv2i58$a5h$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>> {...snip..}
>> Uh? What? Either I am confused, or you are.
>> ..INCLUDE /whatever/
>> should work just fine. It's not that Macro-32 don't have an include file
>> system. It's just that it's not the only thing it has. It *also* have
>> libraries, which is something Unix compilers usually lack when we talk
>> about source side.
>
> There is no .INCLUDE directive in Macro-32! It is not referenced in the
> VAX Macro LRM either. Adding a ".INCLUDE /whatever/" elicits the error:
>
> .INCLUDE /whatever/
> ^
> %AMAC-E-UNRECSTMT, unrecognized statement
> at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3
>
>
>> Or at least this is what I *know* is true in Macro-11, and while it's
>> been quite a while since I played with Macro-32, I'm fairly certain it's
>> the same there.
>
> 'Tis not!

Ok. This time I'm really surprised. Makes one wonder why this was
removed in Macro-32, which certainly otherwise feels like a spiritual
successor to Macro-11.

And I certainly believed I had used it in the dim past when I played
more on VAXen. Brains develop bit rot...

Johnny

In article <sv5ias$ute$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>On 2022-02-22 16:06, VAXman-@SendSpamHere.ORG wrote:
>> In article <sv2i58$a5h$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>>> {...snip..}
>>> Uh? What? Either I am confused, or you are.
>>> ..INCLUDE /whatever/
>>> should work just fine. It's not that Macro-32 don't have an include file
>>> system. It's just that it's not the only thing it has. It *also* have
>>> libraries, which is something Unix compilers usually lack when we talk
>>> about source side.
>>
>> There is no .INCLUDE directive in Macro-32! It is not referenced in the
>> VAX Macro LRM either. Adding a ".INCLUDE /whatever/" elicits the error:
>>
>> .INCLUDE /whatever/
>> ^
>> %AMAC-E-UNRECSTMT, unrecognized statement
>> at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3
>>
>>
>>> Or at least this is what I *know* is true in Macro-11, and while it's
>>> been quite a while since I played with Macro-32, I'm fairly certain it's
>>> the same there.
>>
>> 'Tis not!
>
>Ok. This time I'm really surprised. Makes one wonder why this was
>removed in Macro-32, which certainly otherwise feels like a spiritual
>successor to Macro-11.
>
>And I certainly believed I had used it in the dim past when I played
>more on VAXen. Brains develop bit rot...

Personally, I prefer the macro library mechanism. If you need to ".INCLUDE"
put it in a macro library, reference the library (.LIBRARY) and then callout
the module. The idea is reusable macros. One time Macro-32 should simply be
put into the source.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-02-23 21:02, VAXman-@SendSpamHere.ORG wrote:
> In article <sv5ias$ute$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>> On 2022-02-22 16:06, VAXman-@SendSpamHere.ORG wrote:
>>> There is no .INCLUDE directive in Macro-32! It is not referenced in the
>>> VAX Macro LRM either. Adding a ".INCLUDE /whatever/" elicits the error:
>>>
>>> .INCLUDE /whatever/
>>> ^
>>> %AMAC-E-UNRECSTMT, unrecognized statement
>>> at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3
>>>
>>>
>>>> Or at least this is what I *know* is true in Macro-11, and while it's
>>>> been quite a while since I played with Macro-32, I'm fairly certain it's
>>>> the same there.
>>>
>>> 'Tis not!
>>
>> Ok. This time I'm really surprised. Makes one wonder why this was
>> removed in Macro-32, which certainly otherwise feels like a spiritual
>> successor to Macro-11.
>>
>> And I certainly believed I had used it in the dim past when I played
>> more on VAXen. Brains develop bit rot...
>
> Personally, I prefer the macro library mechanism. If you need to ".INCLUDE"
> put it in a macro library, reference the library (.LIBRARY) and then callout
> the module. The idea is reusable macros. One time Macro-32 should simply be
> put into the source.

They have different uses, and are not interchangeable.
I certainly like the macro libraries, but they cannot be used for things
like some prefix file you want to add to the compilation. Which is why
..include is also good. Of course, you can also do this on the command
line, which is what I believe John Reagan was hinting at.

But I find it a bit annoying to have to remember to throw those things
in on the command line, so when possible, I use .include instead.

Typical things are stuff like you have some configuration step that
based on your choices creates a prefix file with various symbols
defined. Which is then included in with the compilation, and the source
have various conditional parts that are included or not (or modified)
based on what's in the prefix file.

You could, of course, create a macro out of the whole thing, and put
that in a library, and then the source refers to that created library,
invokes the known macro that defines all the choices made, and then you
are good. But that seems like a very complicated way of doing things here...

(There is so much conditional code in RSX it's almost ridiculous.
Without such prefix files selecting which way to build things, it would
become horrible. Hello LB:[11,10]RSXMC.MAC)

Johnny

In article <sv7on8$ljq$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>On 2022-02-23 21:02, VAXman-@SendSpamHere.ORG wrote:
>> In article <sv5ias$ute$1@news.misty.com>, Johnny Billquist <bqt@softjar.se> writes:
>>> On 2022-02-22 16:06, VAXman-@SendSpamHere.ORG wrote:
>>>> There is no .INCLUDE directive in Macro-32! It is not referenced in the
>>>> VAX Macro LRM either. Adding a ".INCLUDE /whatever/" elicits the error:
>>>>
>>>> .INCLUDE /whatever/
>>>> ^
>>>> %AMAC-E-UNRECSTMT, unrecognized statement
>>>> at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3
>>>>
>>>>
>>>>> Or at least this is what I *know* is true in Macro-11, and while it's
>>>>> been quite a while since I played with Macro-32, I'm fairly certain it's
>>>>> the same there.
>>>>
>>>> 'Tis not!
>>>
>>> Ok. This time I'm really surprised. Makes one wonder why this was
>>> removed in Macro-32, which certainly otherwise feels like a spiritual
>>> successor to Macro-11.
>>>
>>> And I certainly believed I had used it in the dim past when I played
>>> more on VAXen. Brains develop bit rot...
>>
>> Personally, I prefer the macro library mechanism. If you need to ".INCLUDE"
>> put it in a macro library, reference the library (.LIBRARY) and then callout
>> the module. The idea is reusable macros. One time Macro-32 should simply be
>> put into the source.
>
>They have different uses, and are not interchangeable.
>I certainly like the macro libraries, but they cannot be used for things
>like some prefix file you want to add to the compilation. Which is why
>..include is also good. Of course, you can also do this on the command
>line, which is what I believe John Reagan was hinting at.
>
>But I find it a bit annoying to have to remember to throw those things
>in on the command line, so when possible, I use .include instead.
>
>Typical things are stuff like you have some configuration step that
>based on your choices creates a prefix file with various symbols
>defined. Which is then included in with the compilation, and the source
>have various conditional parts that are included or not (or modified)
>based on what's in the prefix file.

VMS provides a file for multiple target (VAX, Alpha, Itanium and I would
assume for the X86 too) that defines various conditional symbols for the
different architectures.

In my DESCRIP.MMS file, I create a library (SYS$LIBRARY:ARCH.MLB) and I
then sandwich the contents of SYS$LIBRARY:ARCH_DEFS.MAR inside of .MACRO
and .ENDM directive and insert that in the ARCH.MLB. Then, my code can
incorporate this with:

.LIBRARY "SYS$LIBRARY:ARCH.MLB"
.ARCH_DEFS

>You could, of course, create a macro out of the whole thing, and put
>that in a library, and then the source refers to that created library,
>invokes the known macro that defines all the choices made, and then you
>are good. But that seems like a very complicated way of doing things here...

MMS makes this virtually effortless, IMNSHO. If you can edit your source
to add a ".INCLUDE", you can edit it to callout a macro.

>(There is so much conditional code in RSX it's almost ridiculous.
>Without such prefix files selecting which way to build things, it would
>become horrible. Hello LB:[11,10]RSXMC.MAC)

comp.os.vms
--------^^^

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.