[Info-vax] BASIC and AST routines

[Dave Froble]

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 at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486