On 11/24/2021 2:14 PM, Simon Clubley wrote:
> VMS should have been designed 5-10 years later on than when it was.
>
> It would have been so much cleaner internally if it had been.

Then Data General may still be around.

;-)

Arne

On 11/24/21 3:12 PM, Arne Vajhøj wrote:
> On 11/24/2021 2:14 PM, Simon Clubley wrote:
>> VMS should have been designed 5-10 years later on than when it was.
>>
>> It would have been so much cleaner internally if it had been.
>
> Then Data General may still be around.
>
> ;-)
>

And PR1ME, too. :-)

bill

On 11/24/2021 1:14 PM, Simon Clubley wrote:
>
> VMS should have been designed 5-10 years later on than when it was.
>

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

Hunter

On Wednesday, November 24, 2021 at 2:00:49 PM UTC-5, Arne Vajhøj wrote:
> On 11/24/2021 1:26 PM, Simon Clubley wrote:
> > On 2021-11-24, Dave Froble <da...@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
Arne,

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

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

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

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

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

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

On 11/24/2021 5:34 PM, Bob Gezelter wrote:
> On Wednesday, November 24, 2021 at 2:00:49 PM UTC-5, Arne Vajhøj
> wrote:
>> On 11/24/2021 1:26 PM, Simon Clubley wrote:
>>> But to directly push values into the call frame for the routine
>>> (and hence directly visible to the routine) so they can be
>>> restored afterwards is just horrible, horrible, horrible. I have
>>> never seen another OS handle this problem in such an ugly way.
>> Now I followed Robert Gezeltzer's advice and it is worth noting
>> that this is really a VAX thing. The newer platforms do not use the
>> values - they are just there for VAX compatibility.
>
> Writing a better linkage is not a particularly difficult task. One is
> somewhat limited by the limitation that two values are passed, the
> AST Entry Address and the AST Parameter.
>
> On more than a few occasions, particularly when using ASTs with QIO
> on the RSX-11 family using 16-bit integers, where ASTPARM was not
> available, the straightforward solution was to use a data structured
> headlined by the IO Status Block. Alternatively, one could create a
> transfer vector which did nothing more than set up the context and
> pass control to an identified routine via a pointer.
>
> On OpenVMS (all architectures) on, e can do something similar, either
> hiding the non-ASTPARM parameters, or loading certain parameters from
> a data structure and then invoking a routine.
>
> It is only a problem in that some languages, e.g.. C can ignore extra
> parameters, while other languages, e.g., BASIC, actually check for
> the correct number of parameters. Languages which have type checking
> on capabilities for call gates add another complexity to this
> question.
Just to clarify - the advice I took was to read the IDSM.

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

Arne

On 24/11/2021 21:45, Hunter Goatley wrote:
> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>
>> VMS should have been designed 5-10 years later on than when it was.
>>
>
> In a thread of backpedaling inanities, that has to be the most inane.
>
> Hunter

+1

--
Chris

In article <snlg1h$jrr$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>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.

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

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

I speak to machines with the voice of humanity.

In article <snlh1r$jrr$5@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>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.

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

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

I speak to machines with the voice of humanity.

In article <snlh8f$jrr$6@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>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 ?

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

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

I speak to machines with the voice of humanity.

In article <snmbpd$ose$1@dont-email.me>, Hunter Goatley <goathunter@goatley.com> writes:
>On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>
>> VMS should have been designed 5-10 years later on than when it was.
>>
>
>In a thread of backpedaling inanities, that has to be the most inane.

Well, it was Simon.

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

I speak to machines with the voice of humanity.

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

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

--
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-11-24, John Dallman <jgd@cix.co.uk> wrote:
> In article <snm2ts$oc3$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> VMS should have been designed 5-10 years later on than when it was.
>
> Would DEC have survived that long without it? Would it have been
> successful in the environment of the time?
>

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

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

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

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

Simon.

--
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:
>
> Might? You mean you don't know. Yet, you stated that it's purpose is
> because of something lacking in Macro-32. Please, answer the original
> question.
>

Already answered in another reply Brian.

Simon.

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

In article <sno35i$lmh$5@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>
>> Might? You mean you don't know. Yet, you stated that it's purpose is
>> because of something lacking in Macro-32. Please, answer the original
>> question.
>>
>
>Already answered in another reply Brian.

No, you haven't.

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

I speak to machines with the voice of humanity.

In article <sno33i$lmh$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, John Dallman <jgd@cix.co.uk> wrote:
>> In article <snm2ts$oc3$1@dont-email.me>,
>> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>>
>>> VMS should have been designed 5-10 years later on than when it was.
>>
>> Would DEC have survived that long without it? Would it have been
>> successful in the environment of the time?
>>
>
>Probably not. It's a pity the timing didn't work out however.
>
>OS design was starting to become a lot cleaner by the start of
>the 1980s and much cleaner by the end of the 1980s.
>
>A VMS designed several years later would not have had the albatross
>of Macro-32 as an application programming language and as a system
>implementation language hanging around it.

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

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

--
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-25 06:42, Dave Froble wrote:
> On 11/24/2021 5:34 PM, Bob Gezelter wrote:
>> On more than a few occasions, particularly when using ASTs with QIO on
>> the
>> RSX-11 family using 16-bit integers, where ASTPARM was not available, the
>> straightforward solution was to use a data structured headlined by the IO
>> Status Block.
>
> That is a neat idea.  Of course, I'd not like the concept of messing
> with the IOSB, but, when all else fails, it is a solution.

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

Johnny

On 11/26/2021 12:19 PM, Johnny Billquist wrote:
> On 2021-11-25 06:42, Dave Froble wrote:
>> On 11/24/2021 5:34 PM, Bob Gezelter wrote:
>>> On more than a few occasions, particularly when using ASTs with QIO on the
>>> RSX-11 family using 16-bit integers, where ASTPARM was not available, the
>>> straightforward solution was to use a data structured headlined by the IO
>>> Status Block.
>>
>> That is a neat idea. Of course, I'd not like the concept of messing with the
>> IOSB, but, when all else fails, it is a solution.
>
> ??? You're not messing with the IOSB. It's just that your I/O have some context
> and information, and you keep that in a structure that also contains the IOSB.
> And when the AST comes, you get the pointer to the IOSB, and hence also the
> pointer to your data structure with all the rest of the context for your I/O.
>
> Johnny

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

1) neat idea to use the structure

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

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

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

Arne Vajhøj wrote:
> On 11/24/2021 2:14 PM, Simon Clubley wrote:
>> VMS should have been designed 5-10 years later on than when it was.
>>
>> It would have been so much cleaner internally if it had been.
>
> Then Data General may still be around.
>
> ;-)

In a way, Data General is still around.

http://www.wild-hare.com/products/

Disclaimer: I wrote the 32-bit emulation in eMV.

Just like PDP-11 and MVII systems, these systems still turn up in odd
corners, and their support companies have been gone longer.

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

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

You can find a complete official example in BASIC here:

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

On Wednesday, 1 December 2021 at 11:07:05 am UTC+10:30, Andrew Commons wrote:
> You can find a complete official example in BASIC here:
>
> http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

And you might also want to check this:

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

On 11/30/21 6:37 PM, Andrew Commons wrote:
> You can find a complete official example in BASIC here:
>
> http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping
>

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

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

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

On Wednesday, 1 December 2021 at 12:37:30 pm UTC+10:30, Craig A. Berry wrote:
> On 11/30/21 6:37 PM, Andrew Commons wrote:
> > You can find a complete official example in BASIC here:
> >
> > http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping
> >
> I already posted that way up-thread a couple of weeks ago:
>
> <https://groups.google.com/g/comp.os.vms/c/TbtTpsImDnY/m/_b1WRX9KAAAJ>
>
> along with a note that the example does not work out of the box on
> Itanium, or (presumably) x86_64. Function signatures are more strict on
> non-VAX and non-Alpha and you can't just pretend that a subroutine and a
> function are the same thing. But with minor fixes, and as far as
> handling AST parameters, it's an example that works.

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