X86VMS-BASIC-X0108-5-1 FT

OpenVMS x86 native compilers, cross compilers news and questions.

Topic author
earlem
Visitor
Posts: 1
Joined: Fri Mar 29, 2024 6:11 am
Reputation: 0
Status: Offline

X86VMS-BASIC-X0108-5-1 FT

Post by earlem » Fri Mar 29, 2024 6:19 am

1) The IVP fails on initial installation due to the BASIC command not being present on the first install of a BASIC compiler. The IVP works after logout and log back in.

2) The last page of the PDF release notes references the COBOL manual. The release notes are also poorly formatted.

3) My source code makes heavy use of 'include from cdd' for record definitions. Is there a FT available of the TDD/CDD for X86?

- Earle

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Fri Mar 29, 2024 4:55 pm

I have another example that crashes.

Disclaimer: I am not a Basic person so it could be an error in my code. The same code runs fine on Alpha though.

Code: Select all

program isq

option type = explicit

external sub test_write
external sub test_read_sequential
external sub test_read_random

print "Basic"
call test_write
call test_read_sequential
call test_read_random

end program
!
sub test_write

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf
external sub test_write_one(string, integer)

open "bas.isq" for output as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
call test_write_one("CCCC", 3)
call test_write_one("BBBB", 2)
call test_write_one("AAAA", 1)
close #1

end sub
!
sub test_write_one(string id, integer ival)

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

buf::id = id
buf::ival = ival
put #1

end sub
!
sub test_read_sequential

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

open "bas.isq" for input as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
handler eof_handler
end handler
when error use eof_handler
    while 1 = 1
        get #1
        print buf::id, " -> ", buf::ival
    next
end when
close #1

end sub
!
sub test_read_random

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf
external sub test_read_random_one(string)

open "bas.isq" for input as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
call test_read_random_one("CCCC")
call test_read_random_one("BBBB")
call test_read_random_one("AAAA")
close #1

end sub
!
sub test_read_random_one(string id)

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

get #1, key #0 eq id
print buf::id, " -> ", buf::ival

end sub

Code: Select all

$ bas isq
$ lin isq
$ r isq
Basic
AAAA           ->            1
BBBB           ->            2
CCCC           ->            3
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=FFFF8300079ACB31, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000000
                                 FFFF8300079ACB31
                                 000000000000001B
    Register dump:
    RAX = 0000000000000000  RDI = 00000000001A805C  RSI = 0000000000000000
    RDX = 0000000000000001  RCX = 0000000000000003  R8  = 0000000000000001
    R9  = 000000007AC99620  RBX = 000000007AC99790  RBP = 000000007AC99788
    R10 = 0000000000000000  R11 = 000000000001827A  R12 = 0000000000004448
    R13 = 0000000000000000  R14 = 0000000000002000  R15 = 000000007AC99790
    RIP = FFFF8300079ACB31  RSP = 000000007AC99780  SS  = 000000000000001B
Arne
arne@vajhoej.dk
VMS user since 1986


hb
Valued Contributor
Posts: 77
Joined: Mon May 01, 2023 12:11 pm
Reputation: 0
Status: Offline

Re: X86VMS-BASIC-X0108-5-1 FT

Post by hb » Fri Mar 29, 2024 5:33 pm

cct wrote:
Fri Mar 29, 2024 4:34 pm
What is the significance of doing it, aprt from increasing runtime IO and CPU?
I note it is shown in VMSIMAGES.DAT as /OPEN /HEADER /SHARED=ADDRESS_DATA so changing will be reset on reboot
Installing with shared address data means pre-applying all fixups and as many image relocations as possible. Install creates global sections for this and maps them to P1 addresses, which are fixed for all processes. Otherwise this would not work. Think of based shareable VAX/VMS images. That is, the image activation does not need to apply all fixups and relocation: image activation is faster. This does not change anything related to runtime IO or CPU.

Without shared address data, the shareable image is mapped in P0/P2 space as any other not-installed image on x86.

The default is to install DEC$BASRTL with shared address data. This is done at startup time. You have to change that default or enter the "install replace" command.

Added in 2 minutes 44 seconds:
arne_v wrote:
Fri Mar 29, 2024 4:55 pm
I have another example that crashes.
Here the RTL signals EOF, the user hander is called (can be verified with a print in eof_handler). It looks like then an RTL handler is called (or control is returned to the code which called eof_handler) and then things go wrong.

PS: How can I convince the forum SW that I want to enter a new entry and do not want to append anything to my last one, which happens to be the last entry for this topic?
Last edited by hb on Fri Mar 29, 2024 6:35 pm, edited 4 times in total.

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Fri Mar 29, 2024 6:41 pm

hb wrote:
Fri Mar 29, 2024 6:31 pm
Here the RTL signals EOF, the user hander is called (can be verified with a print in eof_handler). It looks like then an RTL handler is called (or control is returned to the code which called eof_handler) and then things go wrong.
Looks that way.

Based on your analysis I could simplify the example (and skipping creating the file):

Code: Select all

$ typ z.bas
program isq

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

open "bas.isq" for input as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
handler eof_handler
    print "we got eof"
end handler
when error use eof_handler
    while 1 = 1
        get #1
        print buf::id, " -> ", buf::ival
    next
end when
print "not seeing this"
close #1

end program
$ bas z
$ lin z
$ r z
AAAA           ->            1
BBBB           ->            2
CCCC           ->            3
we got eof
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=FFFF8300079ACB31, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000000
                                 FFFF8300079ACB31
                                 000000000000001B
    Register dump:
    RAX = 0000000000000000  RDI = 00000000001A805C  RSI = 0000000000000000
    RDX = 0000000000000001  RCX = 0000000000000003  R8  = 0000000000000001
    R9  = 000000007AC996F0  RBX = 000000007AC99860  RBP = 000000007AC99858
    R10 = 0000000000000000  R11 = 000000000001827A  R12 = 0000000000004150
    R13 = 0000000000000000  R14 = 0000000000002000  R15 = 000000007AC99860
    RIP = FFFF8300079ACB31  RSP = 000000007AC99850  SS  = 000000000000001B
Can someone that know VMS Basic say if there is something suspect in the code (so it was just pure luck that it worked in Alpha) or if something is wrong in Basic compiler/runtime library.

Added in 1 minute 29 seconds:
hb wrote:
Fri Mar 29, 2024 6:31 pm
PS: How can I convince the forum SW that I want to enter a new entry and do not want to append anything to my last one, which happens to be the last entry for this topic?
Good question. I am now trying to select the "Do not merge with previous post" checkbox. Let us see if if it actually works (never tried it before).
Arne
arne@vajhoej.dk
VMS user since 1986

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Fri Mar 29, 2024 6:44 pm

Hmmm. Did I forget to check it.
Arne
arne@vajhoej.dk
VMS user since 1986

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Fri Mar 29, 2024 6:44 pm

I must have, but second time I did. I think it works.
Arne
arne@vajhoej.dk
VMS user since 1986

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Fri Mar 29, 2024 6:48 pm

Back to Basic.

:-)

The problem is not specific for index-sequential files. Exact same problem for sequential.

Code: Select all

$ typ seq.bas
program seq

option type = explicit

declare string cmd
map (buf) string lin = 80

external sub lib$get_foreign(string)
external string function trim(string)

call lib$get_foreign(cmd)
print "Basic - " + cmd
open "var.txt" for input as file #1, map buf
handler eof_handler
end handler
when error use eof_handler
    while 1 = 1
        get #1
        print "|" + trim(lin) + "|", len(trim(lin))
    next
end when
close #1

end program
!
function string trim(string s)

option type = explicit

declare integer ix

ix = len(s)
while ix > 1 and mid$(s, ix, 1) = chr$(0)
    ix = ix - 1
next
trim = mid$(s, 1, ix)

end function
$ bas seq
$ lin seq
$ r seq
Basic -
|A|            1
|BB|           2
|CCC|          3
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=FFFF8300079ACB31, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000000
                                 FFFF8300079ACB31
                                 000000000000001B
    Register dump:
    RAX = 0000000000000000  RDI = 00000000001A805C  RSI = 0000000000000000
    RDX = 0000000000000001  RCX = 0000000000000003  R8  = 0000000000000001
    R9  = 000000007AC996B0  RBX = 000000007AC99848  RBP = 000000007AC99818
    R10 = 0000000000000000  R11 = 000000000001827A  R12 = 0000000000002000
    R13 = 000000007AC99858  R14 = 00000000000041C0  R15 = 000000007AC99840
    RIP = FFFF8300079ACB31  RSP = 000000007AC99810  SS  = 000000000000001B
Arne
arne@vajhoej.dk
VMS user since 1986

User avatar

cct
Master
Posts: 125
Joined: Sat Aug 15, 2020 9:00 am
Reputation: 0
Location: Cambridge, UK
Status: Offline

Re: X86VMS-BASIC-X0108-5-1 FT

Post by cct » Fri Mar 29, 2024 8:13 pm

hb wrote:
Fri Mar 29, 2024 6:31 pm
cct wrote:
Fri Mar 29, 2024 4:34 pm
What is the significance of doing it, aprt from increasing runtime IO and CPU?
I note it is shown in VMSIMAGES.DAT as /OPEN /HEADER /SHARED=ADDRESS_DATA so changing will be reset on reboot
Installing with shared address data means pre-applying all fixups and as many image relocations as possible. Install creates global sections for this and maps them to P1 addresses, which are fixed for all processes. Otherwise this would not work. Think of based shareable VAX/VMS images. That is, the image activation does not need to apply all fixups and relocation: image activation is faster. This does not change anything related to runtime IO or CPU.

Without shared address data, the shareable image is mapped in P0/P2 space as any other not-installed image on x86.

The default is to install DEC$BASRTL with shared address data. This is done at startup time. You have to change that default or enter the "install replace" command.
Thanks for that. My comment about more CPU, IO was taken from HELP INSTALL/SHARE

I would imagine this will get sort in due course - for now I will go for the manual INSTALL/REPLACE

Tomorrows task is to see if I can recreate a build environment for my old work system - decomissioned in 2013, and anyway the company was forced in administration in 2020 - so definately not commercial

Final setup is only just over 850k lines of code!

MInd when I singlehandedly did the Itanium port it was 1.6 million lines...
--
Chris


vadim
VSI Expert
Newbie
Posts: 3
Joined: Thu Nov 16, 2023 10:15 am
Reputation: 0
Status: Offline

Re: X86VMS-BASIC-X0108-5-1 FT

Post by vadim » Sat Mar 30, 2024 6:01 am

arne_v wrote:
Fri Mar 29, 2024 4:55 pm
I have another example that crashes.

Disclaimer: I am not a Basic person so it could be an error in my code. The same code runs fine on Alpha though.

Code: Select all

program isq

option type = explicit

external sub test_write
external sub test_read_sequential
external sub test_read_random

print "Basic"
call test_write
call test_read_sequential
call test_read_random

end program
!
sub test_write

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf
external sub test_write_one(string, integer)

open "bas.isq" for output as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
call test_write_one("CCCC", 3)
call test_write_one("BBBB", 2)
call test_write_one("AAAA", 1)
close #1

end sub
!
sub test_write_one(string id, integer ival)

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

buf::id = id
buf::ival = ival
put #1

end sub
!
sub test_read_sequential

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

open "bas.isq" for input as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
handler eof_handler
end handler
when error use eof_handler
    while 1 = 1
        get #1
        print buf::id, " -> ", buf::ival
    next
end when
close #1

end sub
!
sub test_read_random

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf
external sub test_read_random_one(string)

open "bas.isq" for input as file #1, indexed fixed, recordtype none, map bufmap, primary key buf::id
call test_read_random_one("CCCC")
call test_read_random_one("BBBB")
call test_read_random_one("AAAA")
close #1

end sub
!
sub test_read_random_one(string id)

option type = explicit

record datarec
    string id = 4
    integer ival
end record
map (bufmap) datarec buf

get #1, key #0 eq id
print buf::id, " -> ", buf::ival

end sub

Code: Select all

$ bas isq
$ lin isq
$ r isq
Basic
AAAA           ->            1
BBBB           ->            2
CCCC           ->            3
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=FFFF8300079ACB31, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000000
                                 FFFF8300079ACB31
                                 000000000000001B
    Register dump:
    RAX = 0000000000000000  RDI = 00000000001A805C  RSI = 0000000000000000
    RDX = 0000000000000001  RCX = 0000000000000003  R8  = 0000000000000001
    R9  = 000000007AC99620  RBX = 000000007AC99790  RBP = 000000007AC99788
    R10 = 0000000000000000  R11 = 000000000001827A  R12 = 0000000000004448
    R13 = 0000000000000000  R14 = 0000000000002000  R15 = 000000007AC99790
    RIP = FFFF8300079ACB31  RSP = 000000007AC99780  SS  = 000000000000001B

Code: Select all

$ bas/noopt isq
$ link/seg=code=p0 isq
$ run isq
Basic
AAAA           ->            1
BBBB           ->            2
CCCC           ->            3
CCCC           ->            3
BBBB           ->            2
AAAA           ->            1
$

User avatar

arne_v
Master
Posts: 344
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: X86VMS-BASIC-X0108-5-1 FT

Post by arne_v » Sat Mar 30, 2024 8:22 am

vadim wrote:
Sat Mar 30, 2024 6:01 am

Code: Select all

$ bas/noopt isq
$ link/seg=code=p0 isq
$ run isq
Basic
AAAA           ->            1
BBBB           ->            2
CCCC           ->            3
CCCC           ->            3
BBBB           ->            2
AAAA           ->            1
$
Yuck - 64 bit strikes again.

OK - thanks.
Arne
arne@vajhoej.dk
VMS user since 1986

User avatar

cct
Master
Posts: 125
Joined: Sat Aug 15, 2020 9:00 am
Reputation: 0
Location: Cambridge, UK
Status: Offline

Re: X86VMS-BASIC-X0108-5-1 FT

Post by cct » Sat Mar 30, 2024 2:52 pm

cct wrote:
Fri Mar 29, 2024 8:13 pm
Tomorrows task is to see if I can recreate a build environment for my old work system - decomissioned in 2013, and anyway the company was forced in administration in 2020 - so definately not commercial

Final setup is only just over 850k lines of code!

MInd when I singlehandedly did the Itanium port it was 1.6 million lines...
Nearly got the build environment setup.

First run only had 41 modules with errors, that I need to review. A good start!

Added in 7 hours 20 minutes 27 seconds:
Missed a bit in the build, so corrected, and tried again. Quite a few directorty/ACP errors, so deleted the source directory and repopulated.
Next buid failed about 20% into the compiling, with some weird MATH error, accompanied by many control characters, clearly in a massive loop, so it filled up the data disc. When I managed to kill it - only way was to reset the queue, I had to delete the log. Manually compiled the failing routine, it was fine as it was on the lasy couple of builds.

Weird, but I will try again in the morning
Last edited by cct on Sat Mar 30, 2024 10:14 pm, edited 1 time in total.
--
Chris

Post Reply