In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>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 doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

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

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

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

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

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

I speak to machines with the voice of humanity.

In article <619d35db$0$706$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>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?

Manure slinging, of course.

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

I speak to machines with the voice of humanity.

In article <619d417a$0$699$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>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.

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

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

Correct. Use them on a need to know basis.

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

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

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

I speak to machines with the voice of humanity.

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

Ok, but, what is the harm?

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

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

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

--
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/23/2021 1:41 PM, Arne Vajhøj 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?
>
> Arne
>
>

Ya know, that sort of gets back to my 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 11/23/2021 2:31 PM, Arne Vajhøj wrote:
> 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.

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

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

Same with Basic.

> 2) Why are those arguments there?

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

--
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/23/2021 8:40 PM, Dave Froble wrote:
> On 11/23/2021 2:31 PM, Arne Vajhøj wrote:
>> 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:
>>>>> That information is only needed because the lowest supported
>>>>> application
>>>>> language on VMS is Macro-32 and not C (or another comparable low-level
>>>>> language).
>>>>
>>>> What does the Macro-32 application developers need those
>>>> arguments for that the C application developers does not need
>>>> them for?
>>>
>>> You miss the point Arne.
>>>
>>> If C was the lowest level supported language then the compiler would
>>> simply have a pragma or function attribute that marked it as an AST
>>> routine so that the compiler would generate the required code (or not
>>> generate troublesome code sequences) as required.
>>>
>>> This happens all the time with C language interrupt handlers in some
>>> embedded environments for example.
>>>
>>> The SP/PC/R0/R1 parameters are implementation details that the person
>>> writing the AST routine should never see or have to deal with.
>>
>> ????
>>
>> There are two questions here.
>>
>> 1) How to deal with side effects from those arguments.
>>
>> Basic apparently has a problem. It could be fixed like you describe
>> for C. John Reagan already confirmed that.
>
> No, Basic does not have any problems.  Works just fine.  No use for
> arguments 2,3,4,5, just ignore them.

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

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

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

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

Arne

On 11/23/2021 8:34 PM, Dave Froble wrote:
> On 11/23/2021 1:37 PM, Simon Clubley wrote:
>> That VMS API passes in a stack pointer, a PC and what were originally
>> two architecture-specific registers.
>>
>> That kind of information simply would not be exposed at application
>> code level in a modern version of that API as it would (rightly) be
>> treated as an implementation specific detail that would be handled
>> by the compiler.
>>
>> That information is only needed because the lowest supported application
>> language on VMS is Macro-32 and not C (or another comparable low-level
>> language).
>
> Ok, but, what is the harm?
>
> Perhaps there are uses for that data.  If one doesn't need to use them,
> ignore them.  No blood, no foul.
>
> Just because something is not "how things should be according to Simon"
> doesn't necessarily make that something bad.
>
> Perhaps when using Macro-32 there might be some use.  Yes, Macro-32 as a
> compiler language sort of sucks.  But what's your alternative?  Re-write
> everything each year, even if it's working as designed and needed?

Rewrite comes with both short term cost and risk.

But not rewriting comes with long term cost and risk.

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

Arne

On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>That VMS API passes in a stack pointer, a PC and what were originally
>>two architecture-specific registers.
>
> That doesn't answer your aspersions WRT Macro-32. Try, do try again.
> I'll be waiting. Also, please tell me about this stack pointer you've
> now claimed to be passed along too.
>

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

>
>
>>That kind of information simply would not be exposed at application
>>code level in a modern version of that API as it would (rightly) be
>>treated as an implementation specific detail that would be handled
>>by the compiler.
>
> Oh, please explain then how are ASTs handled in *ix? <LOL>
>

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

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

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

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

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

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

>
>
>>That information is only needed because the lowest supported application
>>language on VMS is Macro-32 and not C (or another comparable low-level
>>language).
>
> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
> requested previously, if you want to be slinging manure in here, please
> show us your shovel.
>

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

Simon.

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

On 11/24/2021 8:31 AM, Simon Clubley wrote:
> On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> That information is only needed because the lowest supported application
>>> language on VMS is Macro-32 and not C (or another comparable low-level
>>> language).
>>
>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>> requested previously, if you want to be slinging manure in here, please
>> show us your shovel.
>
> Fine. So why are these architecture-specific registers passed to what
> is essentially a callback function in a normal application program
> and why do those registers need to be visible from that same callback
> function ?

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

Arne

On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> 2) Why are those arguments there?
>
> It is not obvious to me why Macro-32 code would want to use them
> any more than C or Basic code.
>

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

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

Simon.

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

On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/24/2021 8:31 AM, Simon Clubley wrote:
>> On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> That information is only needed because the lowest supported application
>>>> language on VMS is Macro-32 and not C (or another comparable low-level
>>>> language).
>>>
>>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>>> requested previously, if you want to be slinging manure in here, please
>>> show us your shovel.
>>
>> Fine. So why are these architecture-specific registers passed to what
>> is essentially a callback function in a normal application program
>> and why do those registers need to be visible from that same callback
>> function ?
>
> So far there has only been one guess: yours - that it is to
> support applications in Macro-32. And that explanation does
> not make any sense as Macro-32 applications do not need info
> that C applications does not.
>

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

Simon.

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

On 11/24/2021 8:46 AM, Simon Clubley wrote:
> On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> 2) Why are those arguments there?
>>
>> It is not obvious to me why Macro-32 code would want to use them
>> any more than C or Basic code.
>>
>
> Nor to me. In an OS with the proper levels of abstraction, those
> hardware-specific registers simply should not be needed (or even
> visible) to a function used as the target of what is essentially
> just another way of doing an asynchronous callback to a function
> within an application.

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

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

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

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

int __damn_ast foobar()

and the non-existing Macro-32:

..entry foobar
..damn_ast

?

Arne

On 11/24/2021 8:51 AM, Simon Clubley wrote:
> On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/24/2021 8:31 AM, Simon Clubley wrote:
>>> On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>>> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> That information is only needed because the lowest supported application
>>>>> language on VMS is Macro-32 and not C (or another comparable low-level
>>>>> language).
>>>>
>>>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>>>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>>>> requested previously, if you want to be slinging manure in here, please
>>>> show us your shovel.
>>>
>>> Fine. So why are these architecture-specific registers passed to what
>>> is essentially a callback function in a normal application program
>>> and why do those registers need to be visible from that same callback
>>> function ?
>>
>> So far there has only been one guess: yours - that it is to
>> support applications in Macro-32. And that explanation does
>> not make any sense as Macro-32 applications do not need info
>> that C applications does not.
>
> Not directly, but you might have to manually manage or preserve
> something in Macro-32 that an OS based around a higher-level language
> could handle for you automatically in the code generated by the
> compilers for that OS.

Except that it is fine to ignore those arguments.

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

Arne

In article <snlerq$jrr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>That VMS API passes in a stack pointer, a PC and what were originally
>>>two architecture-specific registers.
>>
>> That doesn't answer your aspersions WRT Macro-32. Try, do try again.
>> I'll be waiting. Also, please tell me about this stack pointer you've
>> now claimed to be passed along too.
>>
>
>You are correct Brian. I wrongly thought it was the SP for some reason
>instead of the PS/PSL. However, passing an architecture-specific PS/PSL
>register to the AST is even more ridiculous than passing the SP.
>
>>
>>
>>>That kind of information simply would not be exposed at application
>>>code level in a modern version of that API as it would (rightly) be
>>>treated as an implementation specific detail that would be handled
>>>by the compiler.
>>
>> Oh, please explain then how are ASTs handled in *ix? <LOL>
>>
>
>Here is one example of how asynchronous callbacks are handled in Linux:
>
>https://linux.die.net/man/3/dlm_lock
>
>For a proper hardware-level callback when code is written in C, looking
>at microcontroller interrupt handlers would be a good example.
>
>In that world, you can either tag the interrupt handler with an __ISR
>attribute and let the compiler generate the correct code for you, or
>the underlying OS environment can wrap calls to the C language interrupt
>handler with an assembly language handler that is utterly invisible to
>the C language interrupt handler itself.
>
>Here is how one compiler for the PIC32MX (a MIPS MCU) handles this:
>
>https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage
>
>>
>>
>>>That information is only needed because the lowest supported application
>>>language on VMS is Macro-32 and not C (or another comparable low-level
>>>language).
>>
>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>> requested previously, if you want to be slinging manure in here, please
>> show us your shovel.
>>
>
>Fine. So why are these architecture-specific registers passed to what
>is essentially a callback function in a normal application program
>and why do those registers need to be visible from that same callback
>function ?

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

--
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-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/24/2021 8:46 AM, Simon Clubley wrote:
>> On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> 2) Why are those arguments there?
>>>
>>> It is not obvious to me why Macro-32 code would want to use them
>>> any more than C or Basic code.
>>>
>>
>> Nor to me. In an OS with the proper levels of abstraction, those
>> hardware-specific registers simply should not be needed (or even
>> visible) to a function used as the target of what is essentially
>> just another way of doing an asynchronous callback to a function
>> within an application.
>
> So why did you suggest that it was for Macro-32?
>

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

>> Since they are visible, and since they are of no use to a normal
>> compiled language, there must be some cases where you have to
>> preserve these values manually in Macro-32, whereas a OS based
>> around a higher-level language would have its compilers generate
>> the correct code sequences for you without you having to worry
>> about any of this at all.
>
> So it is there for Macro-32 because VMS C could have had a feature
> but actually does not that does something that nobody seems to be doing?
>

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

> And are there really any difference between the non-existing C:
>
> int __damn_ast foobar()
>
> and the non-existing Macro-32:
>
> .entry foobar
> .damn_ast
>

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

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

Simon.

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

On 2021-11-24, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <snlerq$jrr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Fine. So why are these architecture-specific registers passed to what
>>is essentially a callback function in a normal application program
>>and why do those registers need to be visible from that same callback
>>function ?
>
> Stop there! You stated crap, pure unadulterated crap! Answer the initial
> question! You're trying to drag this off the main street and down a side
> alley where it'll be lost amongst the riff-raff.
>

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

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

Simon.

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

On 11/24/2021 8:31 AM, Simon Clubley wrote:
> On 2021-11-23, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <snjcd1$9hn$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>> That VMS API passes in a stack pointer, a PC and what were originally
>>> two architecture-specific registers.
>>
>> That doesn't answer your aspersions WRT Macro-32. Try, do try again.
>> I'll be waiting. Also, please tell me about this stack pointer you've
>> now claimed to be passed along too.
>>
>
> You are correct Brian. I wrongly thought it was the SP for some reason
> instead of the PS/PSL. However, passing an architecture-specific PS/PSL
> register to the AST is even more ridiculous than passing the SP.
>
>>
>>
>>> That kind of information simply would not be exposed at application
>>> code level in a modern version of that API as it would (rightly) be
>>> treated as an implementation specific detail that would be handled
>>> by the compiler.
>>
>> Oh, please explain then how are ASTs handled in *ix? <LOL>
>>
>
> Here is one example of how asynchronous callbacks are handled in Linux:
>
> https://linux.die.net/man/3/dlm_lock
>
> For a proper hardware-level callback when code is written in C, looking
> at microcontroller interrupt handlers would be a good example.
>
> In that world, you can either tag the interrupt handler with an __ISR
> attribute and let the compiler generate the correct code for you, or
> the underlying OS environment can wrap calls to the C language interrupt
> handler with an assembly language handler that is utterly invisible to
> the C language interrupt handler itself.
>
> Here is how one compiler for the PIC32MX (a MIPS MCU) handles this:
>
> https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage
>
>>
>>
>>> That information is only needed because the lowest supported application
>>> language on VMS is Macro-32 and not C (or another comparable low-level
>>> language).
>>
>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>> requested previously, if you want to be slinging manure in here, please
>> show us your shovel.
>>
>
> Fine. So why are these architecture-specific registers passed to what
> is essentially a callback function in a normal application program
> and why do those registers need to be visible from that same callback
> function ?
>
> Simon.
>

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

--
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/24/2021 9:08 AM, Simon Clubley wrote:
> On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/24/2021 8:46 AM, Simon Clubley wrote:
>>> On 2021-11-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> 2) Why are those arguments there?
>>>>
>>>> It is not obvious to me why Macro-32 code would want to use them
>>>> any more than C or Basic code.
>>>>
>>>
>>> Nor to me. In an OS with the proper levels of abstraction, those
>>> hardware-specific registers simply should not be needed (or even
>>> visible) to a function used as the target of what is essentially
>>> just another way of doing an asynchronous callback to a function
>>> within an application.
>>
>> So why did you suggest that it was for Macro-32?
>
> I suggested it was needed because clearly something needs to be manually
> preserved by the programmer in Macro-32 code that simply would not be
> an issue if VMS was based around an higher-level language instead.

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

>>> Since they are visible, and since they are of no use to a normal
>>> compiled language, there must be some cases where you have to
>>> preserve these values manually in Macro-32, whereas a OS based
>>> around a higher-level language would have its compilers generate
>>> the correct code sequences for you without you having to worry
>>> about any of this at all.
>>
>> So it is there for Macro-32 because VMS C could have had a feature
>> but actually does not that does something that nobody seems to be doing?
>>
>
> No, it's there because the lowest supported application language on
> VMS is Macro-32 instead of C or another language and hence that had
> to be factored into the VMS API design.
>
>> And are there really any difference between the non-existing C:
>>
>> int __damn_ast foobar()
>>
>> and the non-existing Macro-32:
>>
>> .entry foobar
>> .damn_ast
>>
>
> Yes. Code generation in a compiled language is totally abstracted
> away from the source code the compiler is working with.

Except that it is not.

The compiler does what it is instructed to do.

In this case a fictive __damn_ast directive.

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

And the MAcro-32 use a fictive damn_ast macro.

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

Arne

On 2021-11-24, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/24/2021 8:31 AM, Simon Clubley wrote:
>>
>> Fine. So why are these architecture-specific registers passed to what
>> is essentially a callback function in a normal application program
>> and why do those registers need to be visible from that same callback
>> function ?
>>
>
> Steve Hoffman answered that question way back up-thread. I'll leave it as an
> exercise for you to go back and take a look.
>

Thank you David, I have found that posting.

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

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

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

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

Simon.

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

On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/24/2021 9:08 AM, Simon Clubley wrote:
>>
>> I suggested it was needed because clearly something needs to be manually
>> preserved by the programmer in Macro-32 code that simply would not be
>> an issue if VMS was based around an higher-level language instead.
>
> But it is an observable fact that it is not needed.
>

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

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

Yuck.

Simon.

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

On 11/24/2021 1:34 PM, Simon Clubley wrote:
> On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/24/2021 9:08 AM, Simon Clubley wrote:
>>>
>>> I suggested it was needed because clearly something needs to be manually
>>> preserved by the programmer in Macro-32 code that simply would not be
>>> an issue if VMS was based around an higher-level language instead.
>>
>> But it is an observable fact that it is not needed.
>
> Turns out it's not the programmer who needs to preserve the registers
> but the OS and it turns out that VMS did it by pushing the registers
> directly into the user-visible call frame and hence making them directly
> available to the callback function. :-(
>
> That is incredibly ugly. It should have been handled by either the
> compiler itself generating the required AST code sequence or the OS ABI
> saving the registers privately outside of the user-visible call frame
> before calling the AST.

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

:-)

Arne

On 11/24/2021 1:26 PM, Simon Clubley wrote:
> On 2021-11-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 11/24/2021 8:31 AM, Simon Clubley wrote:
>>>
>>> Fine. So why are these architecture-specific registers passed to what
>>> is essentially a callback function in a normal application program
>>> and why do those registers need to be visible from that same callback
>>> function ?
>>
>> Steve Hoffman answered that question way back up-thread. I'll leave it as an
>> exercise for you to go back and take a look.
>
> Thank you David, I have found that posting.
>
> So basically, I was right that the VMS abstraction layers are horribly
> broken when it comes to ASTs even though the reason is a bit different
> (and worse) than what I was expecting.
>
> In other operating systems that have this functionality, this is either
> handled by the compiler generating the appropriate code sequences after
> the function is tagged by the programmer or is handled directly by the
> underlying OS ABI _before_ calling the routine.
>
> In either case, the saved registers are private to the OS ABI or compiler
> and are _not_ visible to the user code.
>
> But to directly push values into the call frame for the routine (and hence
> directly visible to the routine) so they can be restored afterwards is just
> horrible, horrible, horrible. I have never seen another OS handle this
> problem in such an ugly way.

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

Arne

On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/24/2021 1:34 PM, Simon Clubley wrote:
>> On 2021-11-24, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/24/2021 9:08 AM, Simon Clubley wrote:
>>>>
>>>> I suggested it was needed because clearly something needs to be manually
>>>> preserved by the programmer in Macro-32 code that simply would not be
>>>> an issue if VMS was based around an higher-level language instead.
>>>
>>> But it is an observable fact that it is not needed.
>>
>> Turns out it's not the programmer who needs to preserve the registers
>> but the OS and it turns out that VMS did it by pushing the registers
>> directly into the user-visible call frame and hence making them directly
>> available to the callback function. :-(
>>
>> That is incredibly ugly. It should have been handled by either the
>> compiler itself generating the required AST code sequence or the OS ABI
>> saving the registers privately outside of the user-visible call frame
>> before calling the AST.
>
> So do we now agree that the Macro-32 thing was pure manure?
>
>:-)
>

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

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

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

Simon.

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

On 11/24/2021 9:12 AM, Simon Clubley wrote:
> On 2021-11-24, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <snlerq$jrr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>> Fine. So why are these architecture-specific registers passed to what
>>> is essentially a callback function in a normal application program
>>> and why do those registers need to be visible from that same callback
>>> function ?
>>
>> Stop there! You stated crap, pure unadulterated crap! Answer the initial
>> question! You're trying to drag this off the main street and down a side
>> alley where it'll be lost amongst the riff-raff.
>>
>
> No, I am not. Are the arguments passed to the AST because the Macro-32
> programmer has to manually preserve them in some cases ?
>
> The same kind of thing that a programmer would never have to worry
> about if the lowest supported language on VMS was not Macro-32 ?
>
> Simon.
>

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

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

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

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