On 2021-11-26, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <snrbgf$7td$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Have you ever looked inside the Linux internals to see how clean
>>they are compared to VMS internals ?
>
> Statement such as yours are purely unfounded without proofs. What is
> so *unclean* in the VMS internals? I've never seen a book written as
> well as the OpenVMS Internal and Data Structures Manual for Linux. I
> demand a proof but not before you answer my question that you have so
> completely ignored or skirted around since the inception of this long
> thread.
>

Since I have answered your question, it's time for me to ask one in
return.

If the VMS internals are as clean as you say, then how can a person easily
and cleanly add a new filesystem to VMS with the same comparable effort
as if they were adding one to Linux or another Unix variant that supports
modular filesystems ?

That is not an academic question BTW, Brian.

After the port is finally completed, what is desperately needed is a
brand new filesystem for VMS that matches the hardware of today and the
requirements of today. VSI have tried this twice now, and have abandoned
both efforts (at least for now).

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-28, John Doppke <jdoppke@gmail.com> wrote:
>
> Every time I see these posts I think "My God, what have I started?"

Relax John, it's not _you_ they want to kill... :-)

Besides, people around here fantasize about killing me on a regular basis. :-)

Simon.

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

On 11/29/2021 1:57 PM, Simon Clubley wrote:
> On 2021-11-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/26/2021 2:26 PM, Simon Clubley wrote:
>>> And the reason I thought it _must_ be Macro-32 related was because the
>>> real reason was so crazy it never even occurred to me. :-)
>>
>> So anything you don't know why is by default a Macro-32 problems??
>>
>
> No. Read my detailed reply to Dan.
>
> In my eyes, there must have been a reason for those registers being
> present and only Macro-32 code could have made any use of them if
> they were going to be used by the AST routine itself.

So do something only possible in Macro-32 and not possible in C?

And that is still relevant for "application programming"?

Arne

On 2021-11-28, Johnny Billquist <bqt@softjar.se> wrote:
> On 2021-11-26 20:26, Simon Clubley wrote:
>> It turns out that the reason those arguments are available to the called
>> function is because VMS needs to preserve those registers across the AST
>> call and some bright spark during the design of VMS thought it was
>> acceptable to push those registers onto a user-visible call frame instead
>> of storing them in a private area that the called AST function did not
>> have access to.
>
> It seems you understand neither how interrupts (hardware or software)
> work, nor where the problem actually is here.
>

I actually do understand how all this works (or should work). Read my
reply to Dan.

I write bare metal assembly language dispatchers that call C language
interrupt handlers on a regular basis, and they sometimes need to store
information outside of the usual registers. That information is always
private to the interrupt dispatcher, not the C language interrupt handler.

>> That's the kind of design decision that was so insane it should never
>> have passed a design review but at least it appears to have been fixed
>> in later architectures with a private storage area, just like it should
>> have been on VAX.
>
> No. You're nuts, and don't seem to understand some very simple things.
>

I'm not nuts. I just have some firm opinions about how it should work... :-)

> Why DEC choose to expose these elements on the stack to the AST function
> is beyond me. You could possibly argue that there could be some reason
> for sometimes being able to examine these in order to do something
> specific, but in general I can't really think of a good reason, and if I
> had designed the language environment, I'd kept them out of visibility.
> It would be easy to do this, so it was obviously a conscious decision by
> DEC for the high level languages to expose the information.
>

This is the bit I simply don't get either.

> But again - this do not have anything to do with VMS itself, and VMS
> isn't doing anything different than Unix is (well, actually ASTs work
> much better than signals, but the reason and context for that should be
> a different thread).
>
> Unix on the other hand made the decision that the similar kind of
> information on the stack when a signal handler is called is not being
> exposed in the function signature.
> Makes much more sense if you ask me, but this is something for the C
> language, and don't have anything to do with Unix as such. The
> information is there on the stack. It's just not exposed to the function.
>

This is how I design my own bare metal setups and it works robustly
and cleanly. The information is still on the stack, but it is strictly
outside of the bounds of the stack space that the called routine is
allowed to touch or view. The information is considered to belong to
the dispatcher and _not_ to the routine the dispatcher calls.

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-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/29/2021 1:57 PM, Simon Clubley wrote:
>> On 2021-11-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/26/2021 2:26 PM, Simon Clubley wrote:
>>>> And the reason I thought it _must_ be Macro-32 related was because the
>>>> real reason was so crazy it never even occurred to me. :-)
>>>
>>> So anything you don't know why is by default a Macro-32 problems??
>>>
>>
>> No. Read my detailed reply to Dan.
>>
>> In my eyes, there must have been a reason for those registers being
>> present and only Macro-32 code could have made any use of them if
>> they were going to be used by the AST routine itself.
>
> So do something only possible in Macro-32 and not possible in C?
>
> And that is still relevant for "application programming"?
>

That was the thinking yes, before I found out the real reason.

Before that, I _was_ thinking something along the lines of maybe
being able to disturb program state directly in a way that a HLL
would not because the code generated by the HLL compiler would be
guaranteed to save and restore program state for you.

The problem was that I couldn't see what and I now know the reason why. :-)

Simon.

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

I think this message shows the source of the confusion.

The AST dispatch/return mechanism has nothing to do with Macro32 or any
other language.

VMS and the VAX hardware were designed together. The implementation of
each affected the other and various decisions and trade offs were made
to produce a viable solution given the hardware limitations of the time.

A large part of what made VMS's capabilities unique in the day was the
AST. This provided capabilities that other OSes (including Linux and
Windows) have yet to provide. Likewise, it also required restrictions
that other OSes (including Linux and Windows) do not have.

In VAX/VMS, there is not a software AST "routine" dispatcher.

The AST dispatch/routine mechanism is implemented in the VAX hardware.

The extra "arguments" are the hardware context required by the VAX
hardware to correctly execute the AST return.

The programing practice has always been to ignore those arguments.

Would a pure software design have done it some other way. Of course!

But such a software redesign would have impacted more than just VMS.
ASTs are used in many user mode programs.

If you want to blame something, blame the VAX hardware design. But,
that very design is what made VMS viable in the 1970/1980s time frame.

Simon Clubley wrote:
> On 2021-11-26, abrsvc <dansabrservices@yahoo.com> wrote:
>> I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.
>>
>
> Hello Dan,
>
> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in
> which it was done. This information should be private to the AST
> dispatcher that calls the AST routine. It should never be visible
> to the called AST routine itself because that is an outright violation
> of good modular design and that's as true back when VMS was designed
> as it is now.
>
> In case you are familiar with bare metal interrupt programming, you can
> compare the calling of an AST routine with the way that an interrupt
> handler is called when working with bare metal code or when implementing
> an OS itself.
>
> On more advanced MCUs, you can have an assembly language interrupt
> dispatcher that calls the actual C language interrupt handler and you
> can end up having to save more interrupt state than just the normal
> registers in your assembly language interrupt dispatcher.
>
> However, that information is always private to the interrupt dispatcher,
> and is _never_ exposed to the interrupt handler itself and this is so
> universally true, that I didn't even realise what the AST registers were
> being used for until it was pointed out to me.
>
> For example, in one bare metal assembly language interrupt dispatcher
> I wrote a while back for an ARM processor and which I was looking at
> recently, the dispatcher has to save what is called the priority limiter
> register before programming a new value (this allows nested interrupts
> to occur).
>
> This is saved onto the stack by the dispatcher before calling the
> C language interrupt handler and is restored by the interrupt dispatcher
> upon return from the interrupt handler. This information is private
> to the dispatcher, it is not visible to the interrupt handler, and
> I would never design a system where it was, because that is an utter
> violation of modular and good programming practice.
>
> That priority limiter register can be compared to one of those private
> AST registers and that's why I consider it so wrong that those private
> registers are there in the AST call frame and hence visible to the
> called routine as it's an utter violation of good modular design.
>
> Simon.
>

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: chris@applied-synergy.com
Fax: 817-237-3074

On 2021-11-29 19:51, Simon Clubley wrote:
> On 2021-11-26, abrsvc <dansabrservices@yahoo.com> wrote:
>> I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.
>>
>
> Hello Dan,
>
> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in
> which it was done. This information should be private to the AST
> dispatcher that calls the AST routine. It should never be visible
> to the called AST routine itself because that is an outright violation
> of good modular design and that's as true back when VMS was designed
> as it is now.
>
> In case you are familiar with bare metal interrupt programming, you can
> compare the calling of an AST routine with the way that an interrupt
> handler is called when working with bare metal code or when implementing
> an OS itself.
>
> On more advanced MCUs, you can have an assembly language interrupt
> dispatcher that calls the actual C language interrupt handler and you
> can end up having to save more interrupt state than just the normal
> registers in your assembly language interrupt dispatcher.
>
> However, that information is always private to the interrupt dispatcher,
> and is _never_ exposed to the interrupt handler itself and this is so
> universally true, that I didn't even realise what the AST registers were
> being used for until it was pointed out to me.
>
> For example, in one bare metal assembly language interrupt dispatcher
> I wrote a while back for an ARM processor and which I was looking at
> recently, the dispatcher has to save what is called the priority limiter
> register before programming a new value (this allows nested interrupts
> to occur).
>
> This is saved onto the stack by the dispatcher before calling the
> C language interrupt handler and is restored by the interrupt dispatcher
> upon return from the interrupt handler. This information is private
> to the dispatcher, it is not visible to the interrupt handler, and
> I would never design a system where it was, because that is an utter
> violation of modular and good programming practice.
>
> That priority limiter register can be compared to one of those private
> AST registers and that's why I consider it so wrong that those private
> registers are there in the AST call frame and hence visible to the
> called routine as it's an utter violation of good modular design.

I agree with the sentiment here, but this is not something that has
anything to do with VMS.

This is a choice that was done by the people writing the language
runtime system. For some reason they thought it was a good idea to
expose these internal things explicitly in the language. I would not do
it, and it seems you wouldn't either.

But why are you blaming that on VMS?

Johnny

In article <685f4933-7224-485b-a19a-04e0624b4521n@googlegroups.com>, abrsvc <dansabrservices@yahoo.com> writes:
>On Monday, November 29, 2021 at 1:51:49 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-26, abrsvc <dansabr...@yahoo.com> wrote:=20
>> > I find these kind of comments somewhat offensive since it is easy to cr=
>iticize the decisions of people made 40 years ago using the context of know=
>ledge today. VMS was designed as a cooperative pairing of both hardware and=
> software. The use of R0 and R1 was for consistency across calls and had no=
>thing to do with MACRO32 at all. Bliss used the same register conventions. =
>If the VMS and VAX engineers knew in the late 70's what was known now, I su=
>spect things would have been done differently.=20
>> >
>> Hello Dan,=20
>>=20
>> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in=20
>> which it was done. This information should be private to the AST=20
>> dispatcher that calls the AST routine. It should never be visible=20
>> to the called AST routine itself because that is an outright violation=20
>> of good modular design and that's as true back when VMS was designed=20
>> as it is now.=20
>>=20
>> In case you are familiar with bare metal interrupt programming, you can=
>=20
>> compare the calling of an AST routine with the way that an interrupt=20
>> handler is called when working with bare metal code or when implementing=
>=20
>> an OS itself.=20
>>=20
>> On more advanced MCUs, you can have an assembly language interrupt=20
>> dispatcher that calls the actual C language interrupt handler and you=20
>> can end up having to save more interrupt state than just the normal=20
>> registers in your assembly language interrupt dispatcher.=20
>>=20
>> However, that information is always private to the interrupt dispatcher,=
>=20
>> and is _never_ exposed to the interrupt handler itself and this is so=20
>> universally true, that I didn't even realise what the AST registers were=
>=20
>> being used for until it was pointed out to me.=20
>>=20
>> For example, in one bare metal assembly language interrupt dispatcher=20
>> I wrote a while back for an ARM processor and which I was looking at=20
>> recently, the dispatcher has to save what is called the priority limiter=
>=20
>> register before programming a new value (this allows nested interrupts=20
>> to occur).=20
>>=20
>> This is saved onto the stack by the dispatcher before calling the=20
>> C language interrupt handler and is restored by the interrupt dispatcher=
>=20
>> upon return from the interrupt handler. This information is private=20
>> to the dispatcher, it is not visible to the interrupt handler, and=20
>> I would never design a system where it was, because that is an utter=20
>> violation of modular and good programming practice.=20
>>=20
>> That priority limiter register can be compared to one of those private=20
>> AST registers and that's why I consider it so wrong that those private=20
>> registers are there in the AST call frame and hence visible to the=20
>> called routine as it's an utter violation of good modular design.
>> Simon.=20
>>=20
>> --=20
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP=20
>> Walking destinations on a map are further away than they appear.
>
>I am so sick and tired of this "holier than thou" attitude along with "I di=
>ctate what is correct design" attitude. Look, while new technologies and t=
>echniques often make decisions made years ago seem incorrect, you MUST anal=
>yze decisions based upon the knowledge at the time. As I stated earlier, i=
>t is easy to criticize based on what is known now.
>
>Can you for once provide constructive criticism? I find it hard to believe=
> that you have not produced "the best" OS in the world given your opinion o=
>f yourself since you seem to be the only one that knows the right way to do=
> anything ever.

Harrumph! Harrumph! Harrumph!

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

I speak to machines with the voice of humanity.

abrsvc <dansabrservices@yahoo.com> wrote:
>
> I am so sick and tired of this "holier than thou" attitude along with "I
> dictate what is correct design" attitude. Look, while new technologies
> and techniques often make decisions made years ago seem incorrect, you
> MUST analyze decisions based upon the knowledge at the time. As I stated
> earlier, it is easy to criticize based on what is known now.
>
> Can you for once provide constructive criticism? I find it hard to
> believe that you have not produced "the best" OS in the world given your
> opinion of yourself since you seem to be the only one that knows the
> right way to do anything ever.
>

+1

On 2021-11-29 20:38:43 +0000, Chris Scheers said:

> I think this message shows the source of the confusion.
>
> The AST dispatch/return mechanism has nothing to do with Macro32 or any
> other language.
>
> VMS and the VAX hardware were designed together. The implementation of
> each affected the other and various decisions and trade offs were made
> to produce a viable solution given the hardware limitations of the time.
>
> A large part of what made VMS's capabilities unique in the day was the
> AST. This provided capabilities that other OSes (including Linux and
> Windows) have yet to provide. Likewise, it also required restrictions
> that other OSes (including Linux and Windows) do not have.
>
> In VAX/VMS, there is not a software AST "routine" dispatcher.
>
> The AST dispatch/routine mechanism is implemented in the VAX hardware.
>
> The extra "arguments" are the hardware context required by the VAX
> hardware to correctly execute the AST return.
>
> The programing practice has always been to ignore those arguments.
>
> Would a pure software design have done it some other way. Of course!
>
> But such a software redesign would have impacted more than just VMS.
> ASTs are used in many user mode programs.
>
> If you want to blame something, blame the VAX hardware design. But,
> that very design is what made VMS viable in the 1970/1980s time frame.

The VAX/VMS AST delivery code is not hardware. It's software. The code
is located in module ASTDEL (see routines SCH$QAST, SC$ASTDEL,
EXE$ASTRET, etc), and the code had the choice of saving arguments onto
the argument list or saving arguments on the other side of the frame
pointer for the AST, and the developer chose oddly.

A REI instruction triggers an interrupt to go check for some pending
work, and that interrupt then runs a whole lot of software. Including
the CALLG used to pass control to the AST code. Since it was a CALLG
instruction used to pass control to the AST, passing one argument would
have worked as well as five. Not that use of a CALLS would have
significantly changed the flow, other than moving the AP/FP around a
little and wasting some stack. But we have five arguments.

AST delivery does need to preserve the registers involved (as CALLS and
CALLG do not preserve R0 and R1 per the calling standard), though the
visibility of those added arguments on the AST call are basically
useful only for causing corruptions in apps. Which is what Simon is
grumbling about. The whole design tends to point to latent
argument-mismatches in many uses of ASTs, too. That'll be fun to fix,
just as soon as better diagnostics are enabled in the various
programming languages the ASTs are written using.

And that AST argument list design is not changing soon. There's no
reason to change this current ASTDEL argument-list design ~forty years
on either, absent larger changes such as those involved with some
hypothetical implementation of object-oriented message-passing support
on OpenVMS.

> Simon Clubley wrote:
>> On 2021-11-26, abrsvc <dansabrservices@yahoo.com> wrote:
>>> I find these kind of comments somewhat offensive since it is easy to
>>> criticize the decisions of people made 40 years ago using the context
>>> of knowledge today. VMS was designed as a cooperative pairing of both
>>> hardware and software. The use of R0 and R1 was for consistency across
>>> calls and had nothing to do with MACRO32 at all. Bliss used the same
>>> register conventions. If the VMS and VAX engineers knew in the late
>>> 70's what was known now, I suspect things would have been done
>>> differently.
>>>
>>
>> Hello Dan,
>>
>> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in
>> which it was done. This information should be private to the AST
>> dispatcher that calls the AST routine. It should never be visible to
>> the called AST routine itself because that is an outright violation of
>> good modular design and that's as true back when VMS was designed as it
>> is now.
>>
>> In case you are familiar with bare metal interrupt programming, you can
>> compare the calling of an AST routine with the way that an interrupt
>> handler is called when working with bare metal code or when
>> implementing an OS itself.
>>
>> On more advanced MCUs, you can have an assembly language interrupt
>> dispatcher that calls the actual C language interrupt handler and you
>> can end up having to save more interrupt state than just the normal
>> registers in your assembly language interrupt dispatcher.
>>
>> However, that information is always private to the interrupt
>> dispatcher, and is _never_ exposed to the interrupt handler itself and
>> this is so universally true, that I didn't even realise what the AST
>> registers were being used for until it was pointed out to me.
>>
>> For example, in one bare metal assembly language interrupt dispatcher I
>> wrote a while back for an ARM processor and which I was looking at
>> recently, the dispatcher has to save what is called the priority
>> limiter register before programming a new value (this allows nested
>> interrupts to occur).
>>
>> This is saved onto the stack by the dispatcher before calling the C
>> language interrupt handler and is restored by the interrupt dispatcher
>> upon return from the interrupt handler. This information is private to
>> the dispatcher, it is not visible to the interrupt handler, and I would
>> never design a system where it was, because that is an utter violation
>> of modular and good programming practice.
>>
>> That priority limiter register can be compared to one of those private
>> AST registers and that's why I consider it so wrong that those private
>> registers are there in the AST call frame and hence visible to the
>> called routine as it's an utter violation of good modular design.

As for some of the other replies in this thread...

Threading is now baked into OpenVMS (KP), into Linux (POSIX AIO since
2.6, io_uring/liburing more recently, etc), and similarly built into
most other platforms. ASTs aren't particularly unique in 2021.

Ignoring the hardware register stuff in the VAX/VMS AST argument list,
ASTs are somewhat a pain in the arse as compared with some other
designs too, but ASTs can and do work. And KP threading isn't all that
well integrated into the OpenVMS system service calls. There are some
discussions on mixing threads and ASTs around on OpenVMS, and there are
subtleties awaiting app developers here. The OpenVMS documentation did
not cover this area at all well, when last I checked.

As for whether Macro32 was involved in this design? Donno. Kernels
still tend to mess with registers in some corners, and assemblers are
still better than that than is C with asm or built-ins, or some other
alternative. Though we're getting pretty close with the alternatives.

There are other stupid ideas in OpenVMS, such as the successful access
violation, and using localtime in the system clock.

Oh, and there was a replacement created for VAX/VMS at DEC—built with
things learned from VMS and other work—and that replacement has been
quite successful in the market. That replacement? DEC MICA. For some
posters, a platform which largely sees references around here in the
comp.os.vms newsgroup as a source of examples of mistakes that OpenVMS
should... emulate? implement? something.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-11-29, Johnny Billquist <bqt@softjar.se> wrote:
>
> I agree with the sentiment here, but this is not something that has
> anything to do with VMS.
>
> This is a choice that was done by the people writing the language
> runtime system. For some reason they thought it was a good idea to
> expose these internal things explicitly in the language. I would not do
> it, and it seems you wouldn't either.
>
> But why are you blaming that on VMS?
>

In addition to the comments posted by Stephen, VMS has what is called
the Common Language Environment, which all DEC compilers must comply
with. The CLE is a standard which sets down rules to allow modules
written in different programming languages to interact with each other.

As another example of how VMS controls the compilers, VMS also supplies
the Structure Definition Language files and the SDL compiler to generate
the language-specific VMS headers from the VMS supplied SDL files. These
VMS-specific headers are not manually created by the compiler teams.

For these reasons, I have always regarded this kind of thing as being
a part of VMS itself and not just something done by the compiler teams.
The compiler teams do not have a free hand here and have always been
driven by standards and processes laid down by VMS engineering.

Simon.

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

On 11/30/2021 2:22 PM, Simon Clubley wrote:
> On 2021-11-29, Johnny Billquist <bqt@softjar.se> wrote:
>> I agree with the sentiment here, but this is not something that has
>> anything to do with VMS.
>>
>> This is a choice that was done by the people writing the language
>> runtime system. For some reason they thought it was a good idea to
>> expose these internal things explicitly in the language. I would not do
>> it, and it seems you wouldn't either.
>>
>> But why are you blaming that on VMS?
>
> In addition to the comments posted by Stephen, VMS has what is called
> the Common Language Environment, which all DEC compilers must comply
> with. The CLE is a standard which sets down rules to allow modules
> written in different programming languages to interact with each other.
>
> As another example of how VMS controls the compilers, VMS also supplies
> the Structure Definition Language files and the SDL compiler to generate
> the language-specific VMS headers from the VMS supplied SDL files. These
> VMS-specific headers are not manually created by the compiler teams.
>
> For these reasons, I have always regarded this kind of thing as being
> a part of VMS itself and not just something done by the compiler teams.
> The compiler teams do not have a free hand here and have always been
> driven by standards and processes laid down by VMS engineering.

Now I am confused.

I thought the argument was that VMS VAX was doing
(and VMS Alpha + VMS Itanium continued to for
compatibility reasons):

VMS---(5 args)--->AST function

and many people would have preferred:

VMS---(1 arg)--->AST function

The language and language runtimes of the AST function does
not matter for that. The arguments are there.

The difference is that some languages / language runtimes are
fine with 5 args being present and AST function expecting
1 arg while other languages (specifically Basic) complain
and AST function must declare 5 args.

Arne

On Wednesday, 1 December 2021 at 6:46:56 am UTC+11, Arne Vajhøj wrote:
> On 11/30/2021 2:22 PM, Simon Clubley wrote:
> > On 2021-11-29, Johnny Billquist <b...@softjar.se> wrote:
> >> I agree with the sentiment here, but this is not something that has
> >> anything to do with VMS.
> >>
> >> This is a choice that was done by the people writing the language
> >> runtime system. For some reason they thought it was a good idea to
> >> expose these internal things explicitly in the language. I would not do
> >> it, and it seems you wouldn't either.
> >>
> >> But why are you blaming that on VMS?
> >
> > In addition to the comments posted by Stephen, VMS has what is called
> > the Common Language Environment, which all DEC compilers must comply
> > with. The CLE is a standard which sets down rules to allow modules
> > written in different programming languages to interact with each other.
> >
> > As another example of how VMS controls the compilers, VMS also supplies
> > the Structure Definition Language files and the SDL compiler to generate
> > the language-specific VMS headers from the VMS supplied SDL files. These
> > VMS-specific headers are not manually created by the compiler teams.
> >
> > For these reasons, I have always regarded this kind of thing as being
> > a part of VMS itself and not just something done by the compiler teams.
> > The compiler teams do not have a free hand here and have always been
> > driven by standards and processes laid down by VMS engineering.
> Now I am confused.
>
> I thought the argument was that VMS VAX was doing
> (and VMS Alpha + VMS Itanium continued to for
> compatibility reasons):
>
> VMS---(5 args)--->AST function
>
> and many people would have preferred:
>
> VMS---(1 arg)--->AST function
>
> The language and language runtimes of the AST function does
> not matter for that. The arguments are there.
>
> The difference is that some languages / language runtimes are
> fine with 5 args being present and AST function expecting
> 1 arg while other languages (specifically Basic) complain
> and AST function must declare 5 args.
>
> Arne
You are not alone in your confusion
See this post from a long time ago
https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU

On 2021-12-01 02:11:19 +0000, Phil Howell said:

> You are not alone in your confusion
> See this post from a long time ago
> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>

I'd forgotten about that thread.

What a wonderfully inconsistent trashfire ASTs are.

Somebody at VSI probably now has some (more) writing to do, and some
(more) of the existing documentation to review.

And it seems some BASIC declaration somewhere for the AST API is
arguably busted.

Ah, well.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-11-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/30/2021 2:22 PM, Simon Clubley wrote:
>> On 2021-11-29, Johnny Billquist <bqt@softjar.se> wrote:
>>> I agree with the sentiment here, but this is not something that has
>>> anything to do with VMS.
>>>
>>> This is a choice that was done by the people writing the language
>>> runtime system. For some reason they thought it was a good idea to
>>> expose these internal things explicitly in the language. I would not do
>>> it, and it seems you wouldn't either.
>>>
>>> But why are you blaming that on VMS?
>>
>> In addition to the comments posted by Stephen, VMS has what is called
>> the Common Language Environment, which all DEC compilers must comply
>> with. The CLE is a standard which sets down rules to allow modules
>> written in different programming languages to interact with each other.
>>
>> As another example of how VMS controls the compilers, VMS also supplies
>> the Structure Definition Language files and the SDL compiler to generate
>> the language-specific VMS headers from the VMS supplied SDL files. These
>> VMS-specific headers are not manually created by the compiler teams.
>>
>> For these reasons, I have always regarded this kind of thing as being
>> a part of VMS itself and not just something done by the compiler teams.
>> The compiler teams do not have a free hand here and have always been
>> driven by standards and processes laid down by VMS engineering.
>
> Now I am confused.
>
> I thought the argument was that VMS VAX was doing
> (and VMS Alpha + VMS Itanium continued to for
> compatibility reasons):
>
> VMS---(5 args)--->AST function
>
> and many people would have preferred:
>
> VMS---(1 arg)--->AST function
>
> The language and language runtimes of the AST function does
> not matter for that. The arguments are there.
>

That is indeed exactly what this is about and you are right in
what you say above. This is behaviour defined at VMS level, not
at compiler level.

Johnny was thinking this may be a compiler issue that exposed the
extra arguments, not a VMS issue, based on something he appears to
be seeing in Unix. (I don't have enough internals knowledge in that
specific part of Unix to know if he's right about that or not.)

However, on VMS, this is very much a part of VMS, is based on VMS
standards, and is not something done in the compilers. It's just that
the various compilers react differently to what VMS itself is doing.

Simon.

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

On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>
>> You are not alone in your confusion
>> See this post from a long time ago
>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>
>
> I'd forgotten about that thread.
>
> What a wonderfully inconsistent trashfire ASTs are.
>
> Somebody at VSI probably now has some (more) writing to do, and some (more) of
> the existing documentation to review.
>
> And it seems some BASIC declaration somewhere for the AST API is arguably busted.
>
> Ah, well.
>
>

I'm a bit afraid to ask another question. The last question I asked seemed to
start weeks of, not sure what to call it, but some of it was rather nasty.

Oh, well, another question.

I haven't done any research, so the question might have a simple answer.

When as AST is specified while calling a system service, and an AST parameter
can be specified, other than following the docs, what causes me to need to
specify 5 parameters in the AST subroutine? Unless I declare the subroutine
with 5 parameters, I don't know what might enforce such a requirement.

Ok, I really should just go and try it myself, but, I'm lazy. Anyone have a
simple answer?

--
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 2021-12-01 19:41:00 +0000, Dave Froble said:

> On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
>> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>>
>>> You are not alone in your confusion
>>> See this post from a long time ago
>>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>>
>>>
>>
>> I'd forgotten about that thread.
>>
>> What a wonderfully inconsistent trashfire ASTs are.
>>
>> Somebody at VSI probably now has some (more) writing to do, and some
>> (more) of the existing documentation to review.
>>
>> And it seems some BASIC declaration somewhere for the AST API is
>> arguably busted.
>>
>> Ah, well.
>>
>>
>
> I'm a bit afraid to ask another question. The last question I asked
> seemed to start weeks of, not sure what to call it, but some of it was
> rather nasty.
>
> Oh, well, another question.
>
> I haven't done any research, so the question might have a simple answer.
>
> When as AST is specified while calling a system service, and an AST
> parameter can be specified, other than following the docs, what causes
> me to need to specify 5 parameters in the AST subroutine? Unless I
> declare the subroutine with 5 parameters, I don't know what might
> enforce such a requirement.
>
> Ok, I really should just go and try it myself, but, I'm lazy. Anyone
> have a simple answer?

I usually declare the subroutine with one argument for an AST routine,
and that's the context pointer. That's worked in C and C++ for an aeon
or three.

Though whether it breaks with x86-64 port?

And I usually use a pointer to some app-local data structure, as that's
where I stash the IOSB or whatever other connection-specific details
are required for the AST.

It's also where I stash the "unwind in progress" flag, if I'm
cancelling some operation and it's unclear whether the cancel or the
AST will arrive first.

If that one-argument declaration is tolerated by BASIC, use it.

The Linker isn't particularly sensitive to API declarations, and will
probably not notice any API differences. API contract "enforcement"
here is usually by app failure.

Otherwise—if BASIC won't play nice with a one-argument AST
declaration—specify the context pointer and whatever other four values
will be tolerated by BASIC and the Linker.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/1/2021 2:50 PM, Stephen Hoffman wrote:
> On 2021-12-01 19:41:00 +0000, Dave Froble said:
>
>> On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
>>> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>>>
>>>> You are not alone in your confusion
>>>> See this post from a long time ago
>>>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>>>
>>>>
>>>
>>> I'd forgotten about that thread.
>>>
>>> What a wonderfully inconsistent trashfire ASTs are.
>>>
>>> Somebody at VSI probably now has some (more) writing to do, and some (more)
>>> of the existing documentation to review.
>>>
>>> And it seems some BASIC declaration somewhere for the AST API is arguably
>>> busted.
>>>
>>> Ah, well.
>>>
>>>
>>
>> I'm a bit afraid to ask another question. The last question I asked seemed to
>> start weeks of, not sure what to call it, but some of it was rather nasty.
>>
>> Oh, well, another question.
>>
>> I haven't done any research, so the question might have a simple answer.
>>
>> When as AST is specified while calling a system service, and an AST parameter
>> can be specified, other than following the docs, what causes me to need to
>> specify 5 parameters in the AST subroutine? Unless I declare the subroutine
>> with 5 parameters, I don't know what might enforce such a requirement.
>>
>> Ok, I really should just go and try it myself, but, I'm lazy. Anyone have a
>> simple answer?
>
> I usually declare the subroutine with one argument for an AST routine, and
> that's the context pointer. That's worked in C and C++ for an aeon or three.
>
> Though whether it breaks with x86-64 port?
>
> And I usually use a pointer to some app-local data structure, as that's where I
> stash the IOSB or whatever other connection-specific details are required for
> the AST.
>
> It's also where I stash the "unwind in progress" flag, if I'm cancelling some
> operation and it's unclear whether the cancel or the AST will arrive first.
>
> If that one-argument declaration is tolerated by BASIC, use it.
>
> The Linker isn't particularly sensitive to API declarations, and will probably
> not notice any API differences. API contract "enforcement" here is usually by
> app failure.
>
> Otherwise—if BASIC won't play nice with a one-argument AST declaration—specify
> the context pointer and whatever other four values will be tolerated by BASIC
> and the Linker.
>
>
>

Ok, got a bit un-lazy, tried it.

This works:

1 !************************************************
! Timer AST Timeout Handler to Cancel I/O
!************************************************

SUB TCP_TIMER( LONG CH% , &
LONG Z2% , &
LONG Z3% , &
LONG Z4% , &
LONG Z5% )

CALL SYS$CANCEL( Loc(CH%) By Value )

SubEnd

This does not work:

1 !************************************************
! Timer AST Timeout Handler to Cancel I/O
!************************************************

SUB TCP_TIMER( LONG CH% )

CALL SYS$CANCEL( Loc(CH%) By Value )

SubEnd

It seems to have a problem when issuing a read on an I/O channel, not when
invoking the QIO that specifies the AST routine.

I'm not complaining, this was just a test. I'm a bit curious what caused the
error, there was no evident error code or such.

In the debugger, there was a report of "too many arguments" or something like
that. I'm just guessing that at some point Basic caused some count of arguments
and decided that there were too many arguments for the routine as declared.

I hate it when the computer thinks it's smarter than me. Of course that bar
isn't too high.

:-)

--
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 12/1/2021 3:35 PM, Dave Froble wrote:
> Ok, got a bit un-lazy, tried it.
>
> This works:
>
> 1       !************************************************
>         !     Timer AST Timeout Handler to Cancel I/O
>         !************************************************
>
>         SUB TCP_TIMER(  LONG CH% , &
>                         LONG Z2% , &
>                         LONG Z3% , &
>                         LONG Z4% , &
>                         LONG Z5% )
>
>         CALL SYS$CANCEL( Loc(CH%) By Value )
>
>         SubEnd
>
> This does not work:
>
> 1       !************************************************
>         !     Timer AST Timeout Handler to Cancel I/O
>         !************************************************
>
>         SUB TCP_TIMER(  LONG CH% )
>
>         CALL SYS$CANCEL( Loc(CH%) By Value )
>
>         SubEnd
>
> It seems to have a problem when issuing a read on an I/O channel, not
> when invoking the QIO that specifies the AST routine.
>
> I'm not complaining, this was just a test.  I'm a bit curious what
> caused the error, there was no evident error code or such.
>
> In the debugger, there was a report of "too many arguments" or something
> like that.  I'm just guessing that at some point Basic caused some count
> of arguments and decided that there were too many arguments for the
> routine as declared.
>
> I hate it when the computer thinks it's smarter than me.  Of course that
> bar isn't too high.
>
> :-)

Basic is different from some more low level languages.

But I don't see a problem with Basic here.

The AST function is being called with 5 arguments and
the AST function is declared to receive 1 argument, so
something in the generated code does not like it.

Seems perfectly fair to me.

Obviously the documentation should be very clear
about the 5 arguments.

Arne

On 12/1/21 8:50 PM, Stephen Hoffman wrote:
> The Linker isn't particularly sensitive to API declarations, and will
> probably not notice any API differences. API contract "enforcement" here
> is usually by app failure.
>
> Otherwise—if BASIC won't play nice with a one-argument AST
> declaration—specify the context pointer and whatever other four values
> will be tolerated by BASIC and the Linker.

The linker matches symbols, which represent references and definitions.
It complains if it can't find a matching definition for a reference. The
symbol name and the symbol type must match. That is the linker knows
about data and routines. It will not let you define an object for a
routine reference. That's more or less all the linker does, here.

With C++ you get the API encoded in the symbol name, also known as
"decorated" or "mangled" name. With matching such symbols the linker
implicitly checks the API and does notice a difference, that is, it will
print an unresolved reference warning. For example, if you call (or take
the address of) "foo(int,int)" but only define a "foo(int)" you will see

%ILINK-I-UDFSYM, CX3$_Z3FOOII2INROLH
%ILINK-W-USEUNDEF, undefined symbol CX3$_Z3FOOII2INROLH referenced
source code name: "foo(int, int)"

On 11/29/21 19:27, Simon Clubley wrote:

>
> This is how I design my own bare metal setups and it works robustly
> and cleanly. The information is still on the stack, but it is strictly
> outside of the bounds of the stack space that the called routine is
> allowed to touch or view. The information is considered to belong to
> the dispatcher and _not_ to the routine the dispatcher calls.
>
> Simon.
>

Lets qualify that by saying the information is not in any protected
memory space and could be accessed using an offset add / subtract
from the current stack pointer, whatever function the code is currently
running. Seem to remember examples of that for context switching in
embedded os's.

It's quite common in some work to specify a call interface as a
structure + pointer for some subgroup of functionality. Some of
the structure elements used within the called functions and some
are call parameters, but the whole structure is visible to both
sides. I don't see a problem with that...

Chris

On 01/12/2021 21:23, hb wrote:
> On 12/1/21 8:50 PM, Stephen Hoffman wrote:
>> The Linker isn't particularly sensitive to API declarations, and will
>> probably not notice any API differences. API contract "enforcement" here
>> is usually by app failure.
>>
>> Otherwise—if BASIC won't play nice with a one-argument AST
>> declaration—specify the context pointer and whatever other four values
>> will be tolerated by BASIC and the Linker.
>
> The linker matches symbols, which represent references and definitions.
> It complains if it can't find a matching definition for a reference. The
> symbol name and the symbol type must match. That is the linker knows
> about data and routines. It will not let you define an object for a
> routine reference. That's more or less all the linker does, here.
>
> With C++ you get the API encoded in the symbol name, also known as
> "decorated" or "mangled" name. With matching such symbols the linker
> implicitly checks the API and does notice a difference, that is, it will
> print an unresolved reference warning. For example, if you call (or take
> the address of) "foo(int,int)" but only define a "foo(int)" you will see
>
> %ILINK-I-UDFSYM, CX3$_Z3FOOII2INROLH
> %ILINK-W-USEUNDEF, undefined symbol CX3$_Z3FOOII2INROLH referenced
> source code name: "foo(int, int)"
>

ADA picks that up at compile time

--
Chris

Dave Froble <davef@tsoft-inc.com> wrote:
> On 12/1/2021 2:50 PM, Stephen Hoffman wrote:
>> On 2021-12-01 19:41:00 +0000, Dave Froble said:
>>
>>> On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
>>>> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>>>>
>>>>> You are not alone in your confusion
>>>>> See this post from a long time ago
>>>>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>>>>
>>>>>
>>>>
>>>> I'd forgotten about that thread.
>>>>
>>>> What a wonderfully inconsistent trashfire ASTs are.
>>>>
>>>> Somebody at VSI probably now has some (more) writing to do, and some (more)
>>>> of the existing documentation to review.
>>>>
>>>> And it seems some BASIC declaration somewhere for the AST API is arguably
>>>> busted.
>>>>
>>>> Ah, well.
>>>>
>>>>
>>>
>>> I'm a bit afraid to ask another question. The last question I asked seemed to
>>> start weeks of, not sure what to call it, but some of it was rather nasty.
>>>
>>> Oh, well, another question.
>>>
>>> I haven't done any research, so the question might have a simple answer.
>>>
>>> When as AST is specified while calling a system service, and an AST parameter
>>> can be specified, other than following the docs, what causes me to need to
>>> specify 5 parameters in the AST subroutine? Unless I declare the subroutine
>>> with 5 parameters, I don't know what might enforce such a requirement.
>>>
>>> Ok, I really should just go and try it myself, but, I'm lazy. Anyone have a
>>> simple answer?
>>
>> I usually declare the subroutine with one argument for an AST routine, and
>> that's the context pointer. That's worked in C and C++ for an aeon or three.
>>
>> Though whether it breaks with x86-64 port?
>>
>> And I usually use a pointer to some app-local data structure, as that's where I
>> stash the IOSB or whatever other connection-specific details are required for
>> the AST.
>>
>> It's also where I stash the "unwind in progress" flag, if I'm cancelling some
>> operation and it's unclear whether the cancel or the AST will arrive first.
>>
>> If that one-argument declaration is tolerated by BASIC, use it.
>>
>> The Linker isn't particularly sensitive to API declarations, and will probably
>> not notice any API differences. API contract "enforcement" here is usually by
>> app failure.
>>
>> Otherwise???if BASIC won't play nice with a one-argument AST declaration???specify
>> the context pointer and whatever other four values will be tolerated by BASIC
>> and the Linker.
>>
>>
>>
>
> Ok, got a bit un-lazy, tried it.
>
> This works:
>
> 1 !************************************************
> ! Timer AST Timeout Handler to Cancel I/O
> !************************************************
>
> SUB TCP_TIMER( LONG CH% , &
> LONG Z2% , &
> LONG Z3% , &
> LONG Z4% , &
> LONG Z5% )
>
> CALL SYS$CANCEL( Loc(CH%) By Value )
>
> SubEnd
>
> This does not work:
>
> 1 !************************************************
> ! Timer AST Timeout Handler to Cancel I/O
> !************************************************
>
> SUB TCP_TIMER( LONG CH% )
>
> CALL SYS$CANCEL( Loc(CH%) By Value )
>
> SubEnd
>
> It seems to have a problem when issuing a read on an I/O channel, not when
> invoking the QIO that specifies the AST routine.
>
> I'm not complaining, this was just a test. I'm a bit curious what caused the
> error, there was no evident error code or such.
>
> In the debugger, there was a report of "too many arguments" or something like
> that. I'm just guessing that at some point Basic caused some count of arguments
> and decided that there were too many arguments for the routine as declared.

And there is your answer...

$ HELP/LIBRARY=BASICHELP RUN_TIME_ERRORS TOOMANARG

RUN_TIME_ERRORS

TOOMANARG

Too many arguments (ERR=89)

A function call or a SUB or FUNCTION statement passed more arguments
than were expected. Reduce the number of arguments. A SUB or
FUNCTION statement can pass a maximum of approximately 32 arguments:
a function call can pass a maximum of eight arguments. This error
cannot be trapped with a BASIC error handler.

There is also an accompanying TOOFEWARG. BASIC does a lot of things to
protect your fingers from the saw. Howeever, this is not like a blade
guard, more like a pack up the saw in the box and send it back!

Just another reason why BASIC is not one of my favourite languages...

Regards, Tim.

On 12/1/2021 9:31 PM, Tim Sneddon wrote:
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 12/1/2021 2:50 PM, Stephen Hoffman wrote:
>>> On 2021-12-01 19:41:00 +0000, Dave Froble said:
>>>
>>>> On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
>>>>> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>>>>>
>>>>>> You are not alone in your confusion
>>>>>> See this post from a long time ago
>>>>>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>>>>>
>>>>>>
>>>>>
>>>>> I'd forgotten about that thread.
>>>>>
>>>>> What a wonderfully inconsistent trashfire ASTs are.
>>>>>
>>>>> Somebody at VSI probably now has some (more) writing to do, and some (more)
>>>>> of the existing documentation to review.
>>>>>
>>>>> And it seems some BASIC declaration somewhere for the AST API is arguably
>>>>> busted.
>>>>>
>>>>> Ah, well.
>>>>>
>>>>>
>>>>
>>>> I'm a bit afraid to ask another question. The last question I asked seemed to
>>>> start weeks of, not sure what to call it, but some of it was rather nasty.
>>>>
>>>> Oh, well, another question.
>>>>
>>>> I haven't done any research, so the question might have a simple answer.
>>>>
>>>> When as AST is specified while calling a system service, and an AST parameter
>>>> can be specified, other than following the docs, what causes me to need to
>>>> specify 5 parameters in the AST subroutine? Unless I declare the subroutine
>>>> with 5 parameters, I don't know what might enforce such a requirement.
>>>>
>>>> Ok, I really should just go and try it myself, but, I'm lazy. Anyone have a
>>>> simple answer?
>>>
>>> I usually declare the subroutine with one argument for an AST routine, and
>>> that's the context pointer. That's worked in C and C++ for an aeon or three.
>>>
>>> Though whether it breaks with x86-64 port?
>>>
>>> And I usually use a pointer to some app-local data structure, as that's where I
>>> stash the IOSB or whatever other connection-specific details are required for
>>> the AST.
>>>
>>> It's also where I stash the "unwind in progress" flag, if I'm cancelling some
>>> operation and it's unclear whether the cancel or the AST will arrive first.
>>>
>>> If that one-argument declaration is tolerated by BASIC, use it.
>>>
>>> The Linker isn't particularly sensitive to API declarations, and will probably
>>> not notice any API differences. API contract "enforcement" here is usually by
>>> app failure.
>>>
>>> Otherwise???if BASIC won't play nice with a one-argument AST declaration???specify
>>> the context pointer and whatever other four values will be tolerated by BASIC
>>> and the Linker.
>>>
>>>
>>>
>>
>> Ok, got a bit un-lazy, tried it.
>>
>> This works:
>>
>> 1 !************************************************
>> ! Timer AST Timeout Handler to Cancel I/O
>> !************************************************
>>
>> SUB TCP_TIMER( LONG CH% , &
>> LONG Z2% , &
>> LONG Z3% , &
>> LONG Z4% , &
>> LONG Z5% )
>>
>> CALL SYS$CANCEL( Loc(CH%) By Value )
>>
>> SubEnd
>>
>> This does not work:
>>
>> 1 !************************************************
>> ! Timer AST Timeout Handler to Cancel I/O
>> !************************************************
>>
>> SUB TCP_TIMER( LONG CH% )
>>
>> CALL SYS$CANCEL( Loc(CH%) By Value )
>>
>> SubEnd
>>
>> It seems to have a problem when issuing a read on an I/O channel, not when
>> invoking the QIO that specifies the AST routine.
>>
>> I'm not complaining, this was just a test. I'm a bit curious what caused the
>> error, there was no evident error code or such.
>>
>> In the debugger, there was a report of "too many arguments" or something like
>> that. I'm just guessing that at some point Basic caused some count of arguments
>> and decided that there were too many arguments for the routine as declared.
>
> And there is your answer...
>
> $ HELP/LIBRARY=BASICHELP RUN_TIME_ERRORS TOOMANARG
>
> RUN_TIME_ERRORS
>
> TOOMANARG
>
>
> Too many arguments (ERR=89)
>
> A function call or a SUB or FUNCTION statement passed more arguments
> than were expected. Reduce the number of arguments. A SUB or
> FUNCTION statement can pass a maximum of approximately 32 arguments:
> a function call can pass a maximum of eight arguments. This error
> cannot be trapped with a BASIC error handler.
>
> There is also an accompanying TOOFEWARG. BASIC does a lot of things to
> protect your fingers from the saw. Howeever, this is not like a blade
> guard, more like a pack up the saw in the box and send it back!
>
> Just another reason why BASIC is not one of my favourite languages...
>
> Regards, Tim.
>

Thanks Tim, that really does clear things up. I got no problem following the
directions, (when all else fails read the directions), I just was curious about why.

I'm told that some compilers are more rigid than some others, with insuring the
argument count when setting up the call to a subroutine or function.

--
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 2021-12-01 19:32, Simon Clubley wrote:
> On 2021-11-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> Now I am confused.
>>
>> I thought the argument was that VMS VAX was doing
>> (and VMS Alpha + VMS Itanium continued to for
>> compatibility reasons):
>>
>> VMS---(5 args)--->AST function
>>
>> and many people would have preferred:
>>
>> VMS---(1 arg)--->AST function
>>
>> The language and language runtimes of the AST function does
>> not matter for that. The arguments are there.
>>
>
> That is indeed exactly what this is about and you are right in
> what you say above. This is behaviour defined at VMS level, not
> at compiler level.

Right. VMS was doing a bit more than I was expecting. But with that
said, it's still not purely a VMS issue, although I must admit VMS is
trying to bend you here.

> Johnny was thinking this may be a compiler issue that exposed the
> extra arguments, not a VMS issue, based on something he appears to
> be seeing in Unix. (I don't have enough internals knowledge in that
> specific part of Unix to know if he's right about that or not.)

No, I wasn't thinking Unix at all. But I was thinking a bit RSX (as
usual). There, an AST isn't really looking like a normal call sequence.
So in C for example, you have to explicitly tell the compiler that the
routine is an AST handler, and the compiler will sort the rest out for you.
But even in VMS, if the language allows for variable number of argument
functions, you can certainly make it much more transparent.

But you could have done the same as in RSX, and have the functions be
tagged to be AST handlers, and then the compiler could have done all
kind of stuff under the hood to make it match just fine.

So even though VMS has one convention for how ASTs are called, any
language could easily have made it look any other way it wanted.

But yes, VMS encourages a certain pattern.

In Unix, it's simply that a signal handler is always just called with
one argument (the signal number) and is not supposed to return anything.

Whatever else is saved as a part of dispatching to the signal handler is
not exposed in the function signature, but of course, if someone wants
to be creative and reach up into the stack, all kind of stuff is there.
But it's not standardized, so I doubt anyone would write anything that
would do this.

And if people want to talk morass, signals in Unix is much worse than
ASTs. The behavior have changed over the years, as well as what kind of
function you are supposed to use to install a signal handler. Things
like what happens if a signal happens while you are in a signal handler,
and what happens when you return from a signal handler have been sortof
undefined and have changed over the years. In old times, you could just
loose signals when you were unlucky.

> However, on VMS, this is very much a part of VMS, is based on VMS
> standards, and is not something done in the compilers. It's just that
> the various compilers react differently to what VMS itself is doing.

Well, languages could still do whatever they want. But yeah, the easy
way is to just take what VMS gives straight up, and then you get those
extra arguments that VMS for some reason thought were good to have.

Johnny