BASIC and AST routines

[John Doppke]

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.

Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).

Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.

-John

[Jonathan]

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.

function long astRoutine by value(long pasteboard, astArgument, r0, r1, pc, psl)

should work, though how the first two args are passed is hard to determine; experiment with by ref. As you say, messing with the final four args is prone to problems...

[Dave Froble]

Post by John Doppke
So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

From the 7.3 docs:

Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS
Registers R0 and R1, the program counter (PC), and the processor status
longword (PSL) on VAX systems, or processor status (PS) on Alpha systems were
saved when the process was interrupted by delivery of the AST.
The AST parameter is an argument passed to the AST service routine so that
it can identify the event that caused the AST. When you call a system service
requesting an AST, or when you call the SYS$DCLAST system service, you
can supply a value for the AST parameter. If you do not specify a value, the
parameter defaults to 0.

Not formatted so well, but the important data is there.

You get to pass a longword to the AST routine. The other 4 parameters appear to
be set by the OS, or whatever. Not by you! I don't know what you'd do with R0,
R1, PC, and PLS/PS.

Other communications would be via global data, a COMMON block, a PSECT, and
whatever.

As an example, something I've done, set a timer on some I/O. When the AST
fires, you want to do something because of the timeout. I pass the channel #
for the I/O and have the AST cancel the I/O on that channel and return. That
causes I/O completion in the code that set the timer.

I've not used SMG, so I'm not much help in what you're doing. But I'd guess the
"SMG$ENABLE_UNSOLICITED_INPUT" would be an external value, and the use of an
INCLUDE statement would make it available, or, in global data shared with the
calling code.

Apologies if I've not understood your question.

[John Doppke]

Post by Dave Froble

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS
Registers R0 and R1, the program counter (PC), and the processor status
longword (PSL) on VAX systems, or processor status (PS) on Alpha systems were
saved when the process was interrupted by delivery of the AST.
The AST parameter is an argument passed to the AST service routine so that
it can identify the event that caused the AST. When you call a system service
requesting an AST, or when you call the SYS$DCLAST system service, you
can supply a value for the AST parameter. If you do not specify a value, the
parameter defaults to 0.
Not formatted so well, but the important data is there.
You get to pass a longword to the AST routine. The other 4 parameters appear to
be set by the OS, or whatever. Not by you! I don't know what you'd do with R0,
R1, PC, and PLS/PS.
Other communications would be via global data, a COMMON block, a PSECT, and
whatever.
As an example, something I've done, set a timer on some I/O. When the AST
fires, you want to do something because of the timeout. I pass the channel #
for the I/O and have the AST cancel the I/O on that channel and return. That
causes I/O completion in the code that set the timer.
I've not used SMG, so I'm not much help in what you're doing. But I'd guess the
"SMG$ENABLE_UNSOLICITED_INPUT" would be an external value, and the use of an
INCLUDE statement would make it available, or, in global data shared with the
calling code.
Apologies if I've not understood your question.
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Thanks. It also helps if you don't have a typo referring to your function. BASIC will happily compile and link and not say a word.

[Simon Clubley]

Post by John Doppke
Thanks. It also helps if you don't have a typo referring to your function. BASIC will happily compile and link and not say a word.

Huh ? Why don't you get an undefined function error ?

Simon.

[V***@SendSpamHere.ORG]

So I've been playing with writing AST routines (stubbornly) in BASIC. They=
work ok, but I've found I have to declare the routine as having 5 'standar=
d' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sur=
e what the 5 parameters are, but doing anything with them is usually a bad =
idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLIC=
ITED_INPUT. I've tried adding a parameter in my usual list in different wa=
ys but I can't get it to work. Every time it's called I get a reserved opc=
ode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting=
? I'll probably end up writing this one in MACRO, but I want to understand=
what is happening.

AST parameter, R0, R1, PC, PSL/PS

[Craig A. Berry]

Post by John Doppke
So I've been playing with writing AST routines (stubbornly) in BASIC.
They work ok, but I've found I have to declare the routine as having
5 'standard' parameters - "function long AST long (p1, p2, p3, p4,
p5)". I'm not sure what the 5 parameters are, but doing anything
with them is usually a bad idea. I communicate with my main program
using common or event flags.
Now I need an AST for a call that requires a parameter -
SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my
usual list in different ways but I can't get it to work. Every time
it's called I get a reserved opcode exception. (A DCLAST call with
my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is
getting? I'll probably end up writing this one in MACRO, but I want
to understand what is happening.

There is an example in the docs here:

<https://docs.vmssoftware.com/vsi-openvms-rtl-screen-management-smg-manual/#_5935disable_broadcast_trapping>

of calling SMG$ENABLE_UNSOLICITED_INPUT. The example does not work
as-is on post-Alpha architectures -- you have to declare the AST
routines as FUNCTION INTEGER and not SUB. But as far as parameter
passing, if memory serves, what it does works.

[Bob Gezelter]

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,

Been there, done that (for a client whose entire codebase was written in BASIC).

As VAXman and Dave Froble noted, the five parameters are passed are, and I quote from David's posting:

"From the 7.3 docs:

Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "

One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.

Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.

As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.

- Bob Gezelter, http://wwww.rlgsc.com

[Chris Townley]

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic

[Bob Gezelter]

Post by Chris Townley

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic
--
Chris

Chris,

Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possible to easily fall into the trap. Later versions allowed more precision, but the older form was preserved for backward compatibility.

Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.

- Bob Gezelter, http://www.rlgsc.com

[Dave Froble]

Post by Bob Gezelter

Post by Chris Townley

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic
--
Chris

Chris,
Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possible to easily fall into the trap. Later versions allowed more precision, but the older form was preserved for backward compatibility.
Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.
- Bob Gezelter, http://www.rlgsc.com

I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

[Bob Gezelter]

Post by Bob Gezelter

Post by Chris Townley

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic
--
Chris

Chris,
Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possible to easily fall into the trap. Later versions allowed more precision, but the older form was preserved for backward compatibility.
Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.
- Bob Gezelter, http://www.rlgsc.com

I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

David,

Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.

- Bob Gezelter, http://www.rlgsc.com

[Dave Froble]

Post by Bob Gezelter

Post by Bob Gezelter

Post by Chris Townley

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic
--
Chris

Chris,
Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possible to easily fall into the trap. Later versions allowed more precision, but the older form was preserved for backward compatibility.
Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.
- Bob Gezelter, http://www.rlgsc.com

I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

David,
Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.
- Bob Gezelter, http://www.rlgsc.com

Oh, you mean that big book on the bookshelf gathering dust?

Got to now consider how curious I really am.

[Simon Clubley]

Post by Dave Froble

Post by Bob Gezelter
David,
Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.
- Bob Gezelter, http://www.rlgsc.com

Oh, you mean that big book on the bookshelf gathering dust?
Got to now consider how curious I really am.

That "big book" has lots of interesting stuff in it. Try reading
it sometime. :-)

Simon.

[V***@SendSpamHere.ORG]

Post by Dave Froble

Post by Bob Gezelter

Post by Bob Gezelter

Post by Chris Townley

Post by Bob Gezelter

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters
Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST
Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
-John

John,
Been there, done that (for a client whose entire codebase was written in BASIC).
Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "
One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that
Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general li
As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
- Bob Gezelter, http://wwww.rlgsc.com

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic
--
Chris

Chris,
Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possibl
Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.
- Bob Gezelter, http://www.rlgsc.com

I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

David,
Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.
- Bob Gezelter, http://www.rlgsc.com

Oh, you mean that big book on the bookshelf gathering dust?
Got to now consider how curious I really am.

RTFM!

[Neil Rieck]

John etc al,

Back in the day, I was under the impression that I could do almost anything I wanted in DEC-BASIC (given enough time). You mentioned the 5 standard parameters. I recall being here as well when I was first attempting to write my own code to call SYS$QIO and SYS$QIOW. It was around that time that I discovered errors in the official VMS documentation that did not agree with how things were done in the STARLET library. Anyway, here are three links: the first one is for doing $QIO from BASIC (one of the QIO examples includes an AST). The second is a "dog's breakfast menu" of my mostly DEC-BASIC demo code. The third is a menu of VMS notes where one entry shows you how to open any system library so you can see how things need to be declared for the language in question. Enjoy!

http://neilrieck.net/demo_vms_html/qio_demo_bas.html
http://neilrieck.net/demo_vms_html/openvms_demo_index.html
http://neilrieck.net/links/openvms_resources.html#openvms-notes

Neil Rieck
Waterloo, Ontario, Canada

[Stephen Hoffman]

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed
to an AST routine?

Technically, because VAX.

VAX never saved R0 and R1 across CALLS/CALLG calls as those registers
were the return value path, and PC and PS/PSL are the rest of restoring
the context around the AST. If those registers didn't get preserved
(somewhere) across the AST, then the AST delivery would corrupt the
mainline.

Pragmatically, because the programming languages that the OpenVMS devs
largely utilized (then and now) could ignore those arguments, and "the
right thing" would happen. (There's a side-discussion in argument
mismatching to be had here, too.)

In aggregate, it's a dumb-arsed API design that exposes the hardware,
and one that will probably only change as part of overhauling BASIC for
64-bit and for more modern expectations. And possibly of overhauling
the OpenVMS APIs.

Minimally, better BASIC doc would be nice, as the AST API has
eventually bitten most BASIC developers, this stuff is ~not documented.
Searching for "asynchronous" in the current BASIC user and reference
manuals gets nada, and searching for "AST" in the user guide has
nothing useful for writing an AST routine in BASIC and nothing in the
reference manual. This would be where a discussion of AST and thread
reentrancy would likely be placed, too.

Smallest and most isolated VSI code change would be an added AST
function keyword that would allow those arguments to be preserved by
the BASIC run-time, but suppressed in the BASIC app source code.
Syntactic sugar in the BASIC compiler.

Moderate to larger changes would involve moving OpenVMS and BASIC to
object support, and with a hypothetical object AST routine would get an
object containing everything, and the app source code would never need
to reference those bits of hardware data. Or as ASTs are a predecessor
to threading, replace ASTs for KP threading or GCD/libdispatch-style
threading save for preserving the existing old-style-API AST source
code. But last I checked, BASIC was AST-safe and not thread-safe, so
this threading overhaul and object-overhaul would be a
comparatively large investment in the future of BASIC.

[Dave Froble]

Post by Stephen Hoffman

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an
AST routine?

Technically, because VAX.
VAX never saved R0 and R1 across CALLS/CALLG calls as those registers were the
return value path, and PC and PS/PSL are the rest of restoring the context
around the AST. If those registers didn't get preserved (somewhere) across the
AST, then the AST delivery would corrupt the mainline.
Pragmatically, because the programming languages that the OpenVMS devs largely
utilized (then and now) could ignore those arguments, and "the right thing"
would happen. (There's a side-discussion in argument mismatching to be had here,
too.)
In aggregate, it's a dumb-arsed API design that exposes the hardware, and one
that will probably only change as part of overhauling BASIC for 64-bit and for
more modern expectations. And possibly of overhauling the OpenVMS APIs.
Minimally, better BASIC doc would be nice, as the AST API has eventually bitten
most BASIC developers, this stuff is ~not documented. Searching for
"asynchronous" in the current BASIC user and reference manuals gets nada, and
searching for "AST" in the user guide has nothing useful for writing an AST
routine in BASIC and nothing in the reference manual. This would be where a
discussion of AST and thread reentrancy would likely be placed, too.
Smallest and most isolated VSI code change would be an added AST function
keyword that would allow those arguments to be preserved by the BASIC run-time,
but suppressed in the BASIC app source code. Syntactic sugar in the BASIC compiler.
Moderate to larger changes would involve moving OpenVMS and BASIC to object
support, and with a hypothetical object AST routine would get an object
containing everything, and the app source code would never need to reference
those bits of hardware data. Or as ASTs are a predecessor to threading, replace
ASTs for KP threading or GCD/libdispatch-style threading save for preserving the
existing old-style-API AST source code. But last I checked, BASIC was AST-safe
and not thread-safe, so this threading overhaul and object-overhaul would be a
comparatively large investment in the future of BASIC.

All very interesting, and yes, I asked, so thanks for the info.

The real problem is John still doesn't have a Basic compiler for x86, which just
might be a bit more important than how ASTs work. I'll just be real happy when
he has an x86 Basic compiler. I'm not too hard to please.

:-)

[Simon Clubley]

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

In a modern version of VMS, that would be hidden from the application
programmer as an implementation detail and the most you would have to
do would be to tag the AST routine with a pragma or some type of __ast__
attribute that the compiler understood and then automatically generated
the right code for you.

Simon.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

Post by Simon Clubley
In a modern version of VMS, that would be hidden from the application
programmer as an implementation detail and the most you would have to
do would be to tag the AST routine with a pragma or some type of __ast__
attribute that the compiler understood and then automatically generated
the right code for you.

Most will NEVER need to access those parameter and attempts to change them will
do nothing. ASTPRM is first and that's all you may need. Consider the others
gratuitous FYI.

[Simon Clubley]

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

You miss the point Arne.

If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.

This happens all the time with C language interrupt handlers in some
embedded environments for example.

The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

You miss the point Arne.
If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.
This happens all the time with C language interrupt handlers in some
embedded environments for example.
The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

????

There are two questions here.

1) How to deal with side effects from those arguments.

Basic apparently has a problem. It could be fixed like you describe
for C. John Reagan already confirmed that.

Neither C nor Macro-32 has the need for such a fix. They just
don't access the argument and they are good.

2) Why are those arguments there?

It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

You miss the point Arne.
If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.
This happens all the time with C language interrupt handlers in some
embedded environments for example.
The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

????
There are two questions here.
1) How to deal with side effects from those arguments.
Basic apparently has a problem. It could be fixed like you describe
for C. John Reagan already confirmed that.

No, Basic does not have any problems. Works just fine. No use for arguments
2,3,4,5, just ignore them.

Post by Arne Vajhøj
Neither C nor Macro-32 has the need for such a fix. They just
don't access the argument and they are good.

Same with Basic.

Post by Arne Vajhøj
2) Why are those arguments there?

Now there is the interesting question. Does anyone think they would have been
implemented if there was no use for them? There is or was a reason, even if it
was done in case some future use might need them.

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

You miss the point Arne.
If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.
This happens all the time with C language interrupt handlers in some
embedded environments for example.
The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

????
There are two questions here.
1) How to deal with side effects from those arguments.
Basic apparently has a problem. It could be fixed like you describe
for C. John Reagan already confirmed that.

No, Basic does not have any problems.  Works just fine.  No use for
arguments 2,3,4,5, just ignore them.

True. But they need to be declared. That was the observation that
started this thread.

BTW, I think it was Hoff not John Reagan that talked about a
keyword to "hide" those arguments. Mea culpa.

Post by Arne Vajhøj
Neither C nor Macro-32 has the need for such a fix. They just
don't access the argument and they are good.

Same with Basic.

But in those language you do not even need to declare them.

Arne

[Simon Clubley]

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

Since they are visible, and since they are of no use to a normal
compiled language, there must be some cases where you have to
preserve these values manually in Macro-32, whereas a OS based
around a higher-level language would have its compilers generate
the correct code sequences for you without you having to worry
about any of this at all.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

So why did you suggest that it was for Macro-32?

Post by Simon Clubley
Since they are visible, and since they are of no use to a normal
compiled language, there must be some cases where you have to
preserve these values manually in Macro-32, whereas a OS based
around a higher-level language would have its compilers generate
the correct code sequences for you without you having to worry
about any of this at all.

So it is there for Macro-32 because VMS C could have had a feature
but actually does not that does something that nobody seems to be doing?

And are there really any difference between the non-existing C:

int __damn_ast foobar()

and the non-existing Macro-32:

.entry foobar
.damn_ast

?

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

So why did you suggest that it was for Macro-32?

I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

Post by Arne Vajhøj

Post by Simon Clubley
Since they are visible, and since they are of no use to a normal
compiled language, there must be some cases where you have to
preserve these values manually in Macro-32, whereas a OS based
around a higher-level language would have its compilers generate
the correct code sequences for you without you having to worry
about any of this at all.

So it is there for Macro-32 because VMS C could have had a feature
but actually does not that does something that nobody seems to be doing?

No, it's there because the lowest supported application language on
VMS is Macro-32 instead of C or another language and hence that had
to be factored into the VMS API design.

Post by Arne Vajhøj
int __damn_ast foobar()
.entry foobar
.damn_ast

Yes. Code generation in a compiled language is totally abstracted
away from the source code the compiler is working with.

In Macro-32, the assembler is translating the source code, not
rewriting it, and hence there are only a small number of transformations
it can do on the source code.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

So why did you suggest that it was for Macro-32?

I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

But it is an observable fact that it is not needed.

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
Since they are visible, and since they are of no use to a normal
compiled language, there must be some cases where you have to
preserve these values manually in Macro-32, whereas a OS based
around a higher-level language would have its compilers generate
the correct code sequences for you without you having to worry
about any of this at all.

So it is there for Macro-32 because VMS C could have had a feature
but actually does not that does something that nobody seems to be doing?

No, it's there because the lowest supported application language on
VMS is Macro-32 instead of C or another language and hence that had
to be factored into the VMS API design.

Post by Arne Vajhøj
int __damn_ast foobar()
.entry foobar
.damn_ast

Yes. Code generation in a compiled language is totally abstracted
away from the source code the compiler is working with.

Except that it is not.

The compiler does what it is instructed to do.

In this case a fictive __damn_ast directive.

Post by Simon Clubley
In Macro-32, the assembler is translating the source code, not
rewriting it, and hence there are only a small number of transformations
it can do on the source code.

And the MAcro-32 use a fictive damn_ast macro.

In both cases something get added to the code that causes
the compiler to output some code that does something.

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley
I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

But it is an observable fact that it is not needed.

Turns out it's not the programmer who needs to preserve the registers
but the OS and it turns out that VMS did it by pushing the registers
directly into the user-visible call frame and hence making them directly
available to the callback function. :-(

That is incredibly ugly. It should have been handled by either the
compiler itself generating the required AST code sequence or the OS ABI
saving the registers privately outside of the user-visible call frame
before calling the AST.

Yuck.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

But it is an observable fact that it is not needed.

Turns out it's not the programmer who needs to preserve the registers
but the OS and it turns out that VMS did it by pushing the registers
directly into the user-visible call frame and hence making them directly
available to the callback function. :-(
That is incredibly ugly. It should have been handled by either the
compiler itself generating the required AST code sequence or the OS ABI
saving the registers privately outside of the user-visible call frame
before calling the AST.

So do we now agree that the Macro-32 thing was pure manure?

:-)

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

But it is an observable fact that it is not needed.

Turns out it's not the programmer who needs to preserve the registers
but the OS and it turns out that VMS did it by pushing the registers
directly into the user-visible call frame and hence making them directly
available to the callback function. :-(
That is incredibly ugly. It should have been handled by either the
compiler itself generating the required AST code sequence or the OS ABI
saving the registers privately outside of the user-visible call frame
before calling the AST.

So do we now agree that the Macro-32 thing was pure manure?
:-)

I agree that the real reason for them being there is so horrible
and ugly that it never occurred to me as a possibility. :-)

VMS should have been designed 5-10 years later on than when it was.

It would have been so much cleaner internally if it had been.

Simon.

[John Dallman]

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

Would DEC have survived that long without it? Would it have been
successful in the environment of the time?

John

[Simon Clubley]

Post by John Dallman

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

Would DEC have survived that long without it? Would it have been
successful in the environment of the time?

Probably not. It's a pity the timing didn't work out however.

OS design was starting to become a lot cleaner by the start of
the 1980s and much cleaner by the end of the 1980s.

A VMS designed several years later would not have had the albatross
of Macro-32 as an application programming language and as a system
implementation language hanging around it.

Think about the trends of that time period. By the early 1980s, OS
designs in a HLL (Unix for example) were standard and by the late
1980s DEC was proposing Prism with Pillar as the system implementation
language.

Simon.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by John Dallman

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

Would DEC have survived that long without it? Would it have been
successful in the environment of the time?

Probably not. It's a pity the timing didn't work out however.
OS design was starting to become a lot cleaner by the start of
the 1980s and much cleaner by the end of the 1980s.
A VMS designed several years later would not have had the albatross
of Macro-32 as an application programming language and as a system
implementation language hanging around it.

The Albatross is a magnificent glider, capable of staying aloft for hours at
a time without flapping its wings.

Sounds like VMS uptimes! It seems Macro-32 wasn't so bad after all as you've
pointed out just now.

[Arne Vajhøj]

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.
It would have been so much cleaner internally if it had been.

Then Data General may still be around.

;-)

Arne

[Bill Gunshannon]

Post by Arne Vajhøj

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.
It would have been so much cleaner internally if it had been.

Then Data General may still be around.
;-)

And PR1ME, too. :-)

bill

[Andrew Commons]

You can find a complete official example in BASIC here:

http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

[Andrew Commons]

Post by Andrew Commons
http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

And you might also want to check this:

http://odl.sysworks.biz/disk$axpdocmar021/opsys/vmsos73/vmsos73/6136/6136pro_017.html#mbx_interact

[Craig A. Berry]

Post by Andrew Commons
http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

I already posted that way up-thread a couple of weeks ago:

<https://groups.google.com/g/comp.os.vms/c/TbtTpsImDnY/m/_b1WRX9KAAAJ>

along with a note that the example does not work out of the box on
Itanium, or (presumably) x86_64. Function signatures are more strict on
non-VAX and non-Alpha and you can't just pretend that a subroutine and a
function are the same thing. But with minor fixes, and as far as
handling AST parameters, it's an example that works.

[Andrew Commons]

Post by Craig A. Berry

Post by Andrew Commons
http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

<https://groups.google.com/g/comp.os.vms/c/TbtTpsImDnY/m/_b1WRX9KAAAJ>
along with a note that the example does not work out of the box on
Itanium, or (presumably) x86_64. Function signatures are more strict on
non-VAX and non-Alpha and you can't just pretend that a subroutine and a
function are the same thing. But with minor fixes, and as far as
handling AST parameters, it's an example that works.

Craig, sorry, missed that amongst all the off-topic posts.

[Hunter Goatley]

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

In a thread of backpedaling inanities, that has to be the most inane.

Hunter

[Chris Townley]

Post by Hunter Goatley

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

In a thread of backpedaling inanities, that has to be the most inane.
Hunter

+1

[V***@SendSpamHere.ORG]

Post by Hunter Goatley

Post by Simon Clubley
VMS should have been designed 5-10 years later on than when it was.

In a thread of backpedaling inanities, that has to be the most inane.

Well, it was Simon.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

So why did you suggest that it was for Macro-32?

I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

Clearly something needs to be learnt by Simon before slinging manure.

[V***@SendSpamHere.ORG]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

You miss the point Arne.
If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.
This happens all the time with C language interrupt handlers in some
embedded environments for example.
The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

????
There are two questions here.
1) How to deal with side effects from those arguments.
Basic apparently has a problem. It could be fixed like you describe
for C. John Reagan already confirmed that.

I don't see why BASIC should have any issue either.

Post by Arne Vajhøj
Neither C nor Macro-32 has the need for such a fix. They just
don't access the argument and they are good.

Correct. Use them on a need to know basis.

Post by Arne Vajhøj
2) Why are those arguments there?
It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Precisely! However, according to our manure slinger in chief, ASTs are
delivered with those extra parameters' values because Macro-32 would be
spanking the monkey in some dark corner without them.

[Dave Froble]

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?
Arne

Ya know, that sort of gets back to my question ...

[V***@SendSpamHere.ORG]

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

Manure slinging, of course.

[Dave Froble]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).
Simon.

Ok, but, what is the harm?

Perhaps there are uses for that data. If one doesn't need to use them, ignore
them. No blood, no foul.

Just because something is not "how things should be according to Simon" doesn't
necessarily make that something bad.

Perhaps when using Macro-32 there might be some use. Yes, Macro-32 as a
compiler language sort of sucks. But what's your alternative? Re-write
everything each year, even if it's working as designed and needed?

[Arne Vajhøj]

Post by Dave Froble

Post by Simon Clubley
That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

Ok, but, what is the harm?
Perhaps there are uses for that data.  If one doesn't need to use them,
ignore them.  No blood, no foul.
Just because something is not "how things should be according to Simon"
doesn't necessarily make that something bad.
Perhaps when using Macro-32 there might be some use.  Yes, Macro-32 as a
compiler language sort of sucks.  But what's your alternative?  Re-write
everything each year, even if it's working as designed and needed?

Rewrite comes with both short term cost and risk.

But not rewriting comes with long term cost and risk.

Rewriting every year is crazy. But rewrite every 10 or 15 or 20 years
and always to something higher level may make sense.

Arne

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley

Post by Dave Froble
I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

Post by Simon Clubley
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

Oh, please explain then how are ASTs handled in *ix? <LOL>

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

[Simon Clubley]

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

You are correct Brian. I wrongly thought it was the SP for some reason
instead of the PS/PSL. However, passing an architecture-specific PS/PSL
register to the AST is even more ridiculous than passing the SP.

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

Oh, please explain then how are ASTs handled in *ix? <LOL>

Here is one example of how asynchronous callbacks are handled in Linux:

https://linux.die.net/man/3/dlm_lock

For a proper hardware-level callback when code is written in C, looking
at microcontroller interrupt handlers would be a good example.

In that world, you can either tag the interrupt handler with an __ISR
attribute and let the compiler generate the correct code for you, or
the underlying OS environment can wrap calls to the C language interrupt
handler with an assembly language handler that is utterly invisible to
the C language interrupt handler itself.

Here is how one compiler for the PIC32MX (a MIPS MCU) handles this:

https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

So far there has only been one guess: yours - that it is to
support applications in Macro-32. And that explanation does
not make any sense as Macro-32 applications do not need info
that C applications does not.

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

So far there has only been one guess: yours - that it is to
support applications in Macro-32. And that explanation does
not make any sense as Macro-32 applications do not need info
that C applications does not.

Not directly, but you might have to manually manage or preserve
something in Macro-32 that an OS based around a higher-level language
could handle for you automatically in the code generated by the
compilers for that OS.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

So far there has only been one guess: yours - that it is to
support applications in Macro-32. And that explanation does
not make any sense as Macro-32 applications do not need info
that C applications does not.

Not directly, but you might have to manually manage or preserve
something in Macro-32 that an OS based around a higher-level language
could handle for you automatically in the code generated by the
compilers for that OS.

Except that it is fine to ignore those arguments.

And except that there is no such feature in VMS C.

Arne

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

So far there has only been one guess: yours - that it is to
support applications in Macro-32. And that explanation does
not make any sense as Macro-32 applications do not need info
that C applications does not.

Not directly, but you might have to manually manage or preserve
something in Macro-32 that an OS based around a higher-level language
could handle for you automatically in the code generated by the
compilers for that OS.

Might? You mean you don't know. Yet, you stated that it's purpose is
because of something lacking in Macro-32. Please, answer the original
question.

[Simon Clubley]

Post by V***@SendSpamHere.ORG
Might? You mean you don't know. Yet, you stated that it's purpose is
because of something lacking in Macro-32. Please, answer the original
question.

Already answered in another reply Brian.

Simon.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG
Might? You mean you don't know. Yet, you stated that it's purpose is
because of something lacking in Macro-32. Please, answer the original
question.

Already answered in another reply Brian.

No, you haven't.

[Dave Froble]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

You are correct Brian. I wrongly thought it was the SP for some reason
instead of the PS/PSL. However, passing an architecture-specific PS/PSL
register to the AST is even more ridiculous than passing the SP.

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

Oh, please explain then how are ASTs handled in *ix? <LOL>

https://linux.die.net/man/3/dlm_lock
For a proper hardware-level callback when code is written in C, looking
at microcontroller interrupt handlers would be a good example.
In that world, you can either tag the interrupt handler with an __ISR
attribute and let the compiler generate the correct code for you, or
the underlying OS environment can wrap calls to the C language interrupt
handler with an assembly language handler that is utterly invisible to
the C language interrupt handler itself.
https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?
Simon.

Steve Hoffman answered that question way back up-thread. I'll leave it as an
exercise for you to go back and take a look.

[Simon Clubley]

Post by Dave Froble

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Steve Hoffman answered that question way back up-thread. I'll leave it as an
exercise for you to go back and take a look.

Thank you David, I have found that posting.

So basically, I was right that the VMS abstraction layers are horribly
broken when it comes to ASTs even though the reason is a bit different
(and worse) than what I was expecting.

In other operating systems that have this functionality, this is either
handled by the compiler generating the appropriate code sequences after
the function is tagged by the programmer or is handled directly by the
underlying OS ABI _before_ calling the routine.

In either case, the saved registers are private to the OS ABI or compiler
and are _not_ visible to the user code.

But to directly push values into the call frame for the routine (and hence
directly visible to the routine) so they can be restored afterwards is just
horrible, horrible, horrible. I have never seen another OS handle this
problem in such an ugly way.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Dave Froble

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Steve Hoffman answered that question way back up-thread. I'll leave it as an
exercise for you to go back and take a look.

Thank you David, I have found that posting.
So basically, I was right that the VMS abstraction layers are horribly
broken when it comes to ASTs even though the reason is a bit different
(and worse) than what I was expecting.
In other operating systems that have this functionality, this is either
handled by the compiler generating the appropriate code sequences after
the function is tagged by the programmer or is handled directly by the
underlying OS ABI _before_ calling the routine.
In either case, the saved registers are private to the OS ABI or compiler
and are _not_ visible to the user code.
But to directly push values into the call frame for the routine (and hence
directly visible to the routine) so they can be restored afterwards is just
horrible, horrible, horrible. I have never seen another OS handle this
problem in such an ugly way.

Now I followed Robert Gezeltzer's advice and it is worth noting that
this is really a VAX thing. The newer platforms do not use the values -
they are just there for VAX compatibility.

Arne

[Bob Gezelter]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Steve Hoffman answered that question way back up-thread. I'll leave it as an
exercise for you to go back and take a look.

Thank you David, I have found that posting.
So basically, I was right that the VMS abstraction layers are horribly
broken when it comes to ASTs even though the reason is a bit different
(and worse) than what I was expecting.
In other operating systems that have this functionality, this is either
handled by the compiler generating the appropriate code sequences after
the function is tagged by the programmer or is handled directly by the
underlying OS ABI _before_ calling the routine.
In either case, the saved registers are private to the OS ABI or compiler
and are _not_ visible to the user code.
But to directly push values into the call frame for the routine (and hence
directly visible to the routine) so they can be restored afterwards is just
horrible, horrible, horrible. I have never seen another OS handle this
problem in such an ugly way.

Now I followed Robert Gezeltzer's advice and it is worth noting that
this is really a VAX thing. The newer platforms do not use the values -
they are just there for VAX compatibility.
Arne

Arne,

Writing a better linkage is not a particularly difficult task. One is somewhat limited by the limitation that two values are passed, the AST Entry Address and the AST Parameter.

On more than a few occasions, particularly when using ASTs with QIO on the RSX-11 family using 16-bit integers, where ASTPARM was not available, the straightforward solution was to use a data structured headlined by the IO Status Block. Alternatively, one could create a transfer vector which did nothing more than set up the context and pass control to an identified routine via a pointer.

On OpenVMS (all architectures) on, e can do something similar, either hiding the non-ASTPARM parameters, or loading certain parameters from a data structure and then invoking a routine.

It is only a problem in that some languages, e.g.. C can ignore extra parameters, while other languages, e.g., BASIC, actually check for the correct number of parameters. Languages which have type checking on capabilities for call gates add another complexity to this question.

Been there, done that, have draws filled with shirts.

- Bob Gezelter, http://www.rlgsc.com
P.S. Reminds me. One of the tasks on my low priority list is to add my AST seminars to the Presentations section of my www site. Some of the AST-related sessions are already online.

[Arne Vajhøj]

Post by Bob Gezelter

Post by Arne Vajhøj

Post by Simon Clubley
But to directly push values into the call frame for the routine
(and hence directly visible to the routine) so they can be
restored afterwards is just horrible, horrible, horrible. I have
never seen another OS handle this problem in such an ugly way.

Now I followed Robert Gezeltzer's advice and it is worth noting
that this is really a VAX thing. The newer platforms do not use the
values - they are just there for VAX compatibility.

Writing a better linkage is not a particularly difficult task. One is
somewhat limited by the limitation that two values are passed, the
AST Entry Address and the AST Parameter.
On more than a few occasions, particularly when using ASTs with QIO
on the RSX-11 family using 16-bit integers, where ASTPARM was not
available, the straightforward solution was to use a data structured
headlined by the IO Status Block. Alternatively, one could create a
transfer vector which did nothing more than set up the context and
pass control to an identified routine via a pointer.
On OpenVMS (all architectures) on, e can do something similar, either
hiding the non-ASTPARM parameters, or loading certain parameters from
a data structure and then invoking a routine.
It is only a problem in that some languages, e.g.. C can ignore extra
parameters, while other languages, e.g., BASIC, actually check for
the correct number of parameters. Languages which have type checking
on capabilities for call gates add another complexity to this
question.

Just to clarify - the advice I took was to read the IDSM.

And the AXP version explains that AXP (and presumedly I64) does
not actually restore or otherwise use arguments at return and
that they are only there for VAX compatibility. The R0 and R1
are restored from an AST stack.

Arne

[Dave Froble]

Post by Bob Gezelter
On more than a few occasions, particularly when using ASTs with QIO on the
RSX-11 family using 16-bit integers, where ASTPARM was not available, the
straightforward solution was to use a data structured headlined by the IO
Status Block.

That is a neat idea. Of course, I'd not like the concept of messing with the
IOSB, but, when all else fails, it is a solution.

[Johnny Billquist]

Post by Bob Gezelter
On more than a few occasions, particularly when using ASTs with QIO on the
RSX-11 family using 16-bit integers, where ASTPARM was not available, the
straightforward solution was to use a data structured headlined by the IO
Status Block.

That is a neat idea.  Of course, I'd not like the concept of messing
with the IOSB, but, when all else fails, it is a solution.

??? You're not messing with the IOSB. It's just that your I/O have some
context and information, and you keep that in a structure that also
contains the IOSB. And when the AST comes, you get the pointer to the
IOSB, and hence also the pointer to your data structure with all the
rest of the context for your I/O.

Johnny

[Dave Froble]

Post by Dave Froble

Post by Bob Gezelter
On more than a few occasions, particularly when using ASTs with QIO on the
RSX-11 family using 16-bit integers, where ASTPARM was not available, the
straightforward solution was to use a data structured headlined by the IO
Status Block.

That is a neat idea. Of course, I'd not like the concept of messing with the
IOSB, but, when all else fails, it is a solution.

??? You're not messing with the IOSB. It's just that your I/O have some context
and information, and you keep that in a structure that also contains the IOSB.
And when the AST comes, you get the pointer to the IOSB, and hence also the
pointer to your data structure with all the rest of the context for your I/O.
Johnny

The IOSB is a structure that you set up, and pass a pointer to the structure.
Yeah, as you mention.

1) neat idea to use the structure

2) offends my sense of how things should be to use the structure for other than
intended

All I was trying to say. I try to avoid such "smart ideas", since they can be
obscure. But I'd use if if that was the only solution, with lots of comments.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

You are correct Brian. I wrongly thought it was the SP for some reason
instead of the PS/PSL. However, passing an architecture-specific PS/PSL
register to the AST is even more ridiculous than passing the SP.

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

Oh, please explain then how are ASTs handled in *ix? <LOL>

https://linux.die.net/man/3/dlm_lock
For a proper hardware-level callback when code is written in C, looking
at microcontroller interrupt handlers would be a good example.
In that world, you can either tag the interrupt handler with an __ISR
attribute and let the compiler generate the correct code for you, or
the underlying OS environment can wrap calls to the C language interrupt
handler with an assembly language handler that is utterly invisible to
the C language interrupt handler itself.
https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Stop there! You stated crap, pure unadulterated crap! Answer the initial
question! You're trying to drag this off the main street and down a side
alley where it'll be lost amongst the riff-raff.

[Simon Clubley]

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Stop there! You stated crap, pure unadulterated crap! Answer the initial
question! You're trying to drag this off the main street and down a side
alley where it'll be lost amongst the riff-raff.

No, I am not. Are the arguments passed to the AST because the Macro-32
programmer has to manually preserve them in some cases ?

The same kind of thing that a programmer would never have to worry
about if the lowest supported language on VMS was not Macro-32 ?

Simon.

[Dave Froble]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Stop there! You stated crap, pure unadulterated crap! Answer the initial
question! You're trying to drag this off the main street and down a side
alley where it'll be lost amongst the riff-raff.

No, I am not. Are the arguments passed to the AST because the Macro-32
programmer has to manually preserve them in some cases ?
The same kind of thing that a programmer would never have to worry
about if the lowest supported language on VMS was not Macro-32 ?
Simon.

On VAX Macro-32 is an assembler, not a compiled language. Nothing wrong with
that. Note also that the VAX 11/780 was first available in 1978. Trying to
blame the VAX for not having things that didn't exist back then is rather
unfair, to say the least.

On Alpha, itanic, and x86 Macro-32 is a compiled language. Yes, a rather poor
compiled language. But it's existence allowed applications to be easily ported
to Alpha, then itanic, and soon x86. Now, that is a very huge capability.
Allowed Alphas to be sold, and applications to continue doing the job they were
implemented to do. For myself, I have a database product implemented in
Macro-32 that is still in use and doing very well.

That compatibility that you so despise allowed Alphas to be sold, applications
to be ported, saved a large expense, and in general was/is a good thing. If you
cannot understand that, we'll never agree.

[V***@SendSpamHere.ORG]

Post by Simon Clubley

Post by V***@SendSpamHere.ORG

Post by Simon Clubley
Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

Stop there! You stated crap, pure unadulterated crap! Answer the initial
question! You're trying to drag this off the main street and down a side
alley where it'll be lost amongst the riff-raff.

No, I am not. Are the arguments passed to the AST because the Macro-32
programmer has to manually preserve them in some cases ?

Bzzzt! Sorry, you've used up all of your slither-arounds and we now have
to ask you to answer the oringinal question. Remember, you'd stated with
authority that is was because Macro-32 couldn't function without.