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

On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
> 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...

On 11/17/2021 6:14 PM, John Doppke wrote:
> 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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wednesday, November 17, 2021 at 8:18:45 PM UTC-5, Dave Froble wrote:
> On 11/17/2021 6:14 PM, John Doppke wrote:
> > 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.
>
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

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.

On 2021-11-18, John Doppke <jdoppke@gmail.com> wrote:
>
> 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.

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

On 11/18/2021 1:47 PM, Simon Clubley wrote:
> On 2021-11-18, John Doppke <jdoppke@gmail.com> wrote:
>>
>> 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.
>

Because the compiler is smart enough to rub your nose in your mistakes ??

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <d77053df-ac45-42f9-9b01-fac40a04095en@googlegroups.com>, John Doppke <jdoppke@gmail.com> writes:
>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

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

I speak to machines with the voice of humanity.

On 11/17/21 5:14 PM, John Doppke wrote:
> 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.

On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
> 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

On 18/11/2021 23:31, Bob Gezelter wrote:
> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
>> 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
>

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

--
Chris

On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
> On 18/11/2021 23:31, Bob Gezelter wrote:
> > On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
> >> 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
> >
> 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

On 11/18/2021 10:49 PM, Bob Gezelter wrote:
> On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
>> On 18/11/2021 23:31, Bob Gezelter wrote:
>>> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
>>>> 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
>>>
>> 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: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Friday, November 19, 2021 at 12:35:24 AM UTC-5, Dave Froble wrote:
> On 11/18/2021 10:49 PM, Bob Gezelter wrote:
> > On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
> >> On 18/11/2021 23:31, Bob Gezelter wrote:
> >>> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
> >>>> 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
> >>>
> >> 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: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> 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

On 2021-11-19 05:35:20 +0000, Dave Froble said:

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

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/19/2021 6:43 AM, Bob Gezelter wrote:
> On Friday, November 19, 2021 at 12:35:24 AM UTC-5, Dave Froble wrote:
>> On 11/18/2021 10:49 PM, Bob Gezelter wrote:
>>> On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
>>>> On 18/11/2021 23:31, Bob Gezelter wrote:
>>>>> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
>>>>>> 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
>>>>>
>>>> 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: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> 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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/19/2021 10:36 AM, Stephen Hoffman wrote:
> On 2021-11-19 05:35:20 +0000, Dave Froble said:
>
>> 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.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <sn8nrg$g7b$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 11/19/2021 6:43 AM, Bob Gezelter wrote:
>> On Friday, November 19, 2021 at 12:35:24 AM UTC-5, Dave Froble wrote:
>>> On 11/18/2021 10:49 PM, Bob Gezelter wrote:
>>>> On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
>>>>> On 18/11/2021 23:31, Bob Gezelter wrote:
>>>>>> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
>>>>>>> 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).
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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: 724-529-0450
>>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>>> 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!

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

I speak to machines with the voice of humanity.

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

On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>
> 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.

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

On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/19/2021 6:43 AM, Bob Gezelter wrote:
>> 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.

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

In article <sngp1p$aud$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> 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...

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

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

I speak to machines with the voice of humanity.

On 2021-11-22, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <sngp1p$aud$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> 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.

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

On 11/23/2021 1:37 PM, Simon Clubley wrote:
> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <sngp1p$aud$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> 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

On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/23/2021 1:37 PM, Simon Clubley wrote:
>> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>> In article <sngp1p$aud$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>
>>>>> 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.

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

On 11/23/2021 2:06 PM, Simon Clubley wrote:
> On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/23/2021 1:37 PM, Simon Clubley wrote:
>>> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>>> In article <sngp1p$aud$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> On 2021-11-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> 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