¿ªÔÆÌåÓý

  1. H390-Vm
  2. Messages
Expanded Topics Messages Polls
Date
Re: Program Interrupts (signals)

 

"This is back to front.? HX is recognised while processing an interrupt
from the console."

I thought HX was an immediate ... so no going back to what we were doing?

Joe

On Sat, Apr 25, 2020 at 9:23 AM Peter Coghlan <groups@...> wrote:
>
> What's a bit weird is the way IBM layered their hacks on hacks.
>

I'm not sure it's wierd.? Necessary for certain requirements maybe.

>
> And I am not trying to cause controversy because we all know what big
> corporations are like, and what mangers are like ... saving money but
> building up a technical debt. And we all know that (irritatingly) they
> are often right, and certainly I have buried some bodies!
>

Not much argument there.

>
> In this case ... HX should have raised an interrupt which would have
> been manageable with one of the CMS interrupt macros. Instead weird
> polling.
>

This is back to front.? HX is recognised while processing an interrupt
from the console.? What happens next is what happens in most sensible
interrupt service routines, ie a flag is set to note that it happened
and then we go back to doing whatever we were doing in the foreground.
When it is convenient to do so (not in a tight loop while doing nothing
else for example), the foreground task polls the flag and if it is set,
takes action to clean up and exit.

If you add unix signals into this mix, you are just moving part of the
interrupt service routine into the application.? All the called routine
in the application does is set a flag and return.? The foreground part
of the application then polls the flag at a convenient time and if it
is set takes action to clean up and exit.? It is the same thing but only
slighly different.

There is a time and a place for polling and ways to do it right and ways
to do it wrong.? Interrogating the console every n microseconds to see
if a HX has been issued is not a good way to do polling.? Having an
interrupt routine set a flag and acting on it when convenient is the
right way to do it.

>
> And then?REXX came along which (like us today) needed a way for clean
> interrupt for the interpretation. One answer would be to fix HX, and
> allow the interpretor to catch the interrupt.
>

And change the documentation to say that before version x HX did one thing
and since version x it does something else and by the way, it is no longer
possible to halt execution of programs written before version x?? No thanks.

>
> But no - another command HI, another flag to poll!
>

How else is REXX or anything else going to detect at a time convenient to
itself that a HI command has been issued except by looking at some flag?

Why does it seem to make a big difference that the flag being checked has
been set in the console interrupt service routine or in your own routine
that you have registered with the operating system somehow?

>
> The biggest hack was allowing the most significant byte of addresses to
> be used.
>

I wouldn't call it a hack.? I'd call it a bad design decision.

>
> Today, I would fire someone on the spot for doing that (or the equivalent)
> ... and the hardware architects should have made sure CPUs fired a machine
> abend if it ever found anything other than zero in that byte. Just think
> how much easier it would have been to migrate to 32 (yes 32 bit)!
>

What would you do if the hardware already sticks non-address related stuff
into that byte when certain instructions are executed or requires you to
use that byte for something else entirely every time you want to do an I/O?

After you have come back from firing someone or asking the hardare architects
to do something they can't do without breaking existing functionality, you
still have to come up with a way of getting to use more address bits while
maintaining compatibility with large amounts of software that took the
designers at their word that addresses would never exceed 24 bits and used
that extra byte for something else.? How would you do that?? Especially when
you've already fired your best software people and driven your hardware
architects crazy by giving them contraditory design specifications?

>
> And to get a more sympathetic hearing from this forum. In a parallel universe
> IBM launched their PC computer with CMS on metal not DOS.
>

As far as I understand it, CMS was only supplied with VM in order to be able
to maintain it, to rebuild the nucleus, to apply updates etc.? It was never
intended that users would actually use CMS to do real work because it was
totally unsuitable for this.? Does that make it easier to understand some
of the limitations in CMS?

>
> impact on the mainframe business but this was completely offset by new
> customers and use cases. OS emulation was there from day one and later CP
> was introduced as the processors got more powerful. SAA was important
> ... etc.
>

OS emulation was there so that stuff already written for OS (the assembler
for example) could easily be used on CMS without having to rewrite it from
scratch for CMS.

I can't figure out what the rest means.

Regards,
Peter Coghlan.
Re: Program Interrupts (signals)

 


What's a bit weird is the way IBM layered their hacks on hacks.
I'm not sure it's wierd. Necessary for certain requirements maybe.


And I am not trying to cause controversy because we all know what big
corporations are like, and what mangers are like ... saving money but
building up a technical debt. And we all know that (irritatingly) they
are often right, and certainly I have buried some bodies!
Not much argument there.


In this case ... HX should have raised an interrupt which would have
been manageable with one of the CMS interrupt macros. Instead weird
polling.
This is back to front. HX is recognised while processing an interrupt
from the console. What happens next is what happens in most sensible
interrupt service routines, ie a flag is set to note that it happened
and then we go back to doing whatever we were doing in the foreground.
When it is convenient to do so (not in a tight loop while doing nothing
else for example), the foreground task polls the flag and if it is set,
takes action to clean up and exit.

If you add unix signals into this mix, you are just moving part of the
interrupt service routine into the application. All the called routine
in the application does is set a flag and return. The foreground part
of the application then polls the flag at a convenient time and if it
is set takes action to clean up and exit. It is the same thing but only
slighly different.

There is a time and a place for polling and ways to do it right and ways
to do it wrong. Interrogating the console every n microseconds to see
if a HX has been issued is not a good way to do polling. Having an
interrupt routine set a flag and acting on it when convenient is the
right way to do it.


And then?REXX came along which (like us today) needed a way for clean
interrupt for the interpretation. One answer would be to fix HX, and
allow the interpretor to catch the interrupt.
And change the documentation to say that before version x HX did one thing
and since version x it does something else and by the way, it is no longer
possible to halt execution of programs written before version x? No thanks.


But no - another command HI, another flag to poll!
How else is REXX or anything else going to detect at a time convenient to
itself that a HI command has been issued except by looking at some flag?

Why does it seem to make a big difference that the flag being checked has
been set in the console interrupt service routine or in your own routine
that you have registered with the operating system somehow?


The biggest hack was allowing the most significant byte of addresses to
be used.
I wouldn't call it a hack. I'd call it a bad design decision.


Today, I would fire someone on the spot for doing that (or the equivalent)
... and the hardware architects should have made sure CPUs fired a machine
abend if it ever found anything other than zero in that byte. Just think
how much easier it would have been to migrate to 32 (yes 32 bit)!
What would you do if the hardware already sticks non-address related stuff
into that byte when certain instructions are executed or requires you to
use that byte for something else entirely every time you want to do an I/O?

After you have come back from firing someone or asking the hardare architects
to do something they can't do without breaking existing functionality, you
still have to come up with a way of getting to use more address bits while
maintaining compatibility with large amounts of software that took the
designers at their word that addresses would never exceed 24 bits and used
that extra byte for something else. How would you do that? Especially when
you've already fired your best software people and driven your hardware
architects crazy by giving them contraditory design specifications?


And to get a more sympathetic hearing from this forum. In a parallel universe
IBM launched their PC computer with CMS on metal not DOS.
As far as I understand it, CMS was only supplied with VM in order to be able
to maintain it, to rebuild the nucleus, to apply updates etc. It was never
intended that users would actually use CMS to do real work because it was
totally unsuitable for this. Does that make it easier to understand some
of the limitations in CMS?


impact on the mainframe business but this was completely offset by new
customers and use cases. OS emulation was there from day one and later CP
was introduced as the processors got more powerful. SAA was important
... etc.
OS emulation was there so that stuff already written for OS (the assembler
for example) could easily be used on CMS without having to rewrite it from
scratch for CMS.

I can't figure out what the rest means.

Regards,
Peter Coghlan.
Re: Program Interrupts (signals)

 

You keep talking about a migration... what migration?

31-bit addressing came around with the IBM 370 series of computers, in a new architecture called 370/XA. It was an evolution on the 370 line, not a migration... It was originally announced with the 308X series of processors (3081, 3083, 3084). To get a 3084, you first had to buy the 3081, then you could field upgrade it to a 3084. A 3084 was basically two tightly coupled 3081K, operating?as a single 4 processor machine. Then of course came the 3090.

The reason XA is called an evolution is because it changed the I/O subsystem completely. We went from channel I/O to CHPID, i.e. from SIO to SSCH. The biggest change of course was multipath. For instance a 3830 SCU could now have 64MB of cache, with 4 independent paths to complete I/O operations (called dynamic pathing).



Joe



On Sat, Apr 25, 2020 at 8:31 AM adriansutherland67 <adrian@...> wrote:
Exactly .... but if the high byte was clean and app developers religiously ignored assuming anything about addressability. Well ... the migration could have been seemless (ish).

Re: Program Interrupts (signals)

 

Exactly .... but if the high byte was clean and app developers religiously ignored assuming anything about addressability. Well ... the migration could have been seemless (ish).
Re: Program Interrupts (signals)

 

BTW, you should note that every IBM 360 or 370 is a 32-bit machine. It is only the memory addressing that is 24 bits. The GPRs are all 32 bit, and most of the instructions are 32 bit.

So, just because?the machine does not address 4GB of memory does not make it a non 32bit machine.

Joe

On Sat, Apr 25, 2020 at 8:10 AM adriansutherland67 <adrian@...> wrote:
On Sat, Apr 25, 2020 at 01:03 PM, Joe Monk wrote:
32-bit was tried by IBM with the 360/67
Interesting ... I didn't know that ... presumably machines didn't have much real storage at that time and it seemed outlandish!
Re: Program Interrupts (signals)

 

On Sat, Apr 25, 2020 at 01:03 PM, Joe Monk wrote:
32-bit was tried by IBM with the 360/67
Interesting ... I didn't know that ... presumably machines didn't have much real storage at that time and it seemed outlandish!
Re: Program Interrupts (signals)

 

So yes, thats right, the machine that gave birth to VM (back in those days it was called CP/67) had 32-bit addressing!

Joe

On Sat, Apr 25, 2020 at 8:03 AM Joe Monk via <joemonk64=[email protected]> wrote:
"Just think how much easier it would have been to migrate to 32 (yes 32 bit)!"

32-bit was tried by IBM with the 360/67 and it was found there was no appetite for it in the market. If you want to see what it is all about, spin up hercules with?a BC mode PSW, with bits 4 and 5 of the PSW turned on, which indicates 32 bit addressing. There even was an OS IBM developed which supports 32 bit addressing called TSS/360.



Joe

On Sat, Apr 25, 2020 at 7:28 AM adriansutherland67 <adrian@...> wrote:
What's a bit weird is the way IBM layered their hacks on hacks. And I am not trying to cause controversy because we all know what big corporations are like, and what mangers are like ... saving money but building up a technical debt. And we all know that (irritatingly) they are often right, and certainly I have buried some bodies!

In this case ... HX should have raised an interrupt which would have been manageable with one of the CMS interrupt macros. Instead weird polling.

And then?REXX came along which (like us today) needed a way for clean interrupt for the interpretation. One answer would be to fix HX, and allow the interpretor to catch the interrupt. But no - another command HI, another flag to poll!

The biggest hack was allowing the most significant byte of addresses to be used. Today, I would fire someone on the spot for doing that (or the equivalent) ... and the hardware architects should have made sure CPUs fired a machine abend if it ever found anything other than zero in that byte. Just think how much easier it would have been to migrate to 32 (yes 32 bit)!

And to get a more sympathetic hearing from this forum. In a parallel universe IBM launched their PC computer with CMS on metal not DOS. There was some impact on the mainframe business but this was completely offset by new customers and use cases. OS emulation was there from day one and later CP was introduced as the processors got more powerful. SAA was important ... etc.

Re: Program Interrupts (signals)

 

"Just think how much easier it would have been to migrate to 32 (yes 32 bit)!"

32-bit was tried by IBM with the 360/67 and it was found there was no appetite for it in the market. If you want to see what it is all about, spin up hercules with?a BC mode PSW, with bits 4 and 5 of the PSW turned on, which indicates 32 bit addressing. There even was an OS IBM developed which supports 32 bit addressing called TSS/360.



Joe


On Sat, Apr 25, 2020 at 7:28 AM adriansutherland67 <adrian@...> wrote:
What's a bit weird is the way IBM layered their hacks on hacks. And I am not trying to cause controversy because we all know what big corporations are like, and what mangers are like ... saving money but building up a technical debt. And we all know that (irritatingly) they are often right, and certainly I have buried some bodies!

In this case ... HX should have raised an interrupt which would have been manageable with one of the CMS interrupt macros. Instead weird polling.

And then?REXX came along which (like us today) needed a way for clean interrupt for the interpretation. One answer would be to fix HX, and allow the interpretor to catch the interrupt. But no - another command HI, another flag to poll!

The biggest hack was allowing the most significant byte of addresses to be used. Today, I would fire someone on the spot for doing that (or the equivalent) ... and the hardware architects should have made sure CPUs fired a machine abend if it ever found anything other than zero in that byte. Just think how much easier it would have been to migrate to 32 (yes 32 bit)!

And to get a more sympathetic hearing from this forum. In a parallel universe IBM launched their PC computer with CMS on metal not DOS. There was some impact on the mainframe business but this was completely offset by new customers and use cases. OS emulation was there from day one and later CP was introduced as the processors got more powerful. SAA was important ... etc.

Re: Program Interrupts (signals)

 

What's a bit weird is the way IBM layered their hacks on hacks. And I am not trying to cause controversy because we all know what big corporations are like, and what mangers are like ... saving money but building up a technical debt. And we all know that (irritatingly) they are often right, and certainly I have buried some bodies!

In this case ... HX should have raised an interrupt which would have been manageable with one of the CMS interrupt macros. Instead weird polling.

And then?REXX came along which (like us today) needed a way for clean interrupt for the interpretation. One answer would be to fix HX, and allow the interpretor to catch the interrupt. But no - another command HI, another flag to poll!

The biggest hack was allowing the most significant byte of addresses to be used. Today, I would fire someone on the spot for doing that (or the equivalent) ... and the hardware architects should have made sure CPUs fired a machine abend if it ever found anything other than zero in that byte. Just think how much easier it would have been to migrate to 32 (yes 32 bit)!

And to get a more sympathetic hearing from this forum. In a parallel universe IBM launched their PC computer with CMS on metal not DOS. There was some impact on the mainframe business but this was completely offset by new customers and use cases. OS emulation was there from day one and later CP was introduced as the processors got more powerful. SAA was important ... etc.
Re: Program Interrupts (signals)

 


After thought, and considering the HX suppression mod posted by Dave, and that
intercepting HX would allow BREXX to have HI type behaviour, and that if a
divide by zero requires a IPL you can blame/fix the source of the exception,
I think the biggest priority is to attempt to intercept HX.
The HX suppression mod is a bit of a hack which abuses one of the batch flags.
It is not a really awful hack but I think we should be able to do better.

I'm not sure what exactly HI type behaviour is. I am guessing it is a way of
having an EXEC or REXX program stop, clean up and exit in response to a HI
immediate command which is processed similarly to a HX immediate command.


Therefore ... is anyone willing to take a look? I need a call to register an
alternative HX handler. I.e. when CMS checks if an HX has bee issued (during
an Io interrupt, or SVC call) instead of calling the default behaviour it
calls the registered handler.
Not me anyway.

[snip]


For BREXX as an example it would set a BREXX flag that would cause a clean
exit at the next statement end.
Is this "HI type behaviour"? If this is what is deisred, maybe this is what
should be done rather than messing about with HX behaviour?

It might be plausable to create a HI flag in the CMS nucleus, assuming
this is what happens in later versions of CMS. Then BREXX (and EXEC)
could check this flag each time it completes processing a statement
(or each time it completes n statements) and clean up and exit if
the flag is found to be set.

Regards,
Peter Coghlan.

Thoughts?

Adrian
Re: Program Interrupts (signals)

 

After thought, and considering the HX suppression mod posted by Dave, and that intercepting HX would allow BREXX to have HI type behaviour, and that if a divide by zero requires a IPL you can blame/fix the source of the exception, I think the biggest priority is to attempt to intercept HX.

Therefore ... is anyone willing to take a look? I need a call to register an alternative HX handler. I.e. when CMS checks if an HX has bee issued (during an Io interrupt, or SVC call) instead of calling the default behaviour it calls the registered handler.

I only need a single handler registration and can handle scenarios where there might be multiple clients in the master GCCLIB HX handler itself, if that makes sense.

In short happy if it is basic and requires the handler to jump through hoops to work (for example if the handler needs to provide its own save area).

It is envisaged that the handler would.

- Provide a chance for the application to cleanup,
- Exit the application, or?
- Ignore the HX request.

For BREXX as an example it would set a BREXX flag that would cause a clean exit at the next statement end.

Thoughts?

Adrian
Re: memset help

 

Thank you everyone - to close this subject this is the code I am going to use.

I don't use this approach too often but I thought folks might be interested in seeing a non-standard GCC meld of C and Assembler.

void* memset(void* s, int c, size_t sz) {
? if (!s) return 0;
? if (!sz) return s;
?
? /* MVCL uses register pairs so we have to force register assignment by gcc */
? register size_t src_addr __asm__("2") = s;? /* Source Addr to R4 */
? register size_t src_len_pad __asm__("3") = (size_t)(c & 0xff) << 24; /* Fill Char in high byte + 0 length */
? register size_t dest_addr __asm__("4") = s; /* Dest Addr to R4 */
? register size_t dest_len __asm__("5") = sz & 0x00ffffff; /* Dest Length to R5 */
?
? /* USe MVCL for memory move / set */
? __asm__("MVCL 4,2"
? ? ? ? ? :
? ? ? ? ? : "d" (src_addr), "d" (src_len_pad), "d" (dest_addr), "d" (dest_len)
? ? ? ? ?);
?
? return s;
}
Re: memset help

 

Source files?

memset4.assemble
memset4.assemble
memset5.assemble
memset5.assemble
memset6.assemble
memset6.assemble
memsetc.c
memsetc.c
memsett.c
memsett.c

Re: memset help

 

Well the results are in - apologies for the long email and not formatting into table - but you know how it is!

I declaring Peter the WINNER for providing the?MVCL code (although it was suggested by others) - well done all.

Certainly passes the at least 100 times faster challenge by Dave :-)

Some functional defects - and so I also note also that MVCL?has the advantage of being simple enough not to have defects ...

And folks might be interested in the improvements made by the C optimiser.

****
?
Buffer 4,096 chars x 30,000 loops
C optimiser turned OFF
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
A 16 STs memset()
Mismatch at 4079
Body Error in iteration 1
?... failed
A MVCL memset()
Tests completed
Ready; T=6.08/6.51 11:34:53
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=35.78/35.79 11:35:33
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=43.94/43.95 11:36:18
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=11.03/11.03 11:36:30
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=26.87/26.89 11:36:58
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.10/0.10 11:36:58
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=1.53/1.54 11:37:01
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.08/0.09 11:37:02
?
****
?
Buffer 100 chars X 300,000 loops
C optimiser turned OFF
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A 16 STs memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A MVCL memset()
Tests completed
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=9.60/9.61 12:01:40
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=10.78/10.78 12:01:52
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=3.60/3.60 12:01:56
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=6.09/6.10 12:02:03
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.47/0.47 12:02:04
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=0.38/0.38 12:02:05
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.44/0.44 12:02:06
?
****
?
Buffer 100,000 chars x 5,000 loops
C optimiser turned OFF
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A 16 STs memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A MVCL memset()
Tests completed
Ready; T=89.65/90.22 12:05:44
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=173.65/173.72 12:08:39
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=182.83/182.89 12:11:43
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=45.22/45.24 12:12:30
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=104.68/104.75 12:14:15
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.24/0.24 12:14:16
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=4.62/4.64 12:14:22
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.03/0.04 12:14:23
?
****
?
Buffer 4,096 chars x 30,000 loops
C optimiser turned ON
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
A 16 STs memset()
Mismatch at 4095
Body Error in iteration 300
?... failed
A MVCL memset()
Tests completed
Ready; T=7.27/7.66 12:20:59
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=35.10/35.11 12:21:35
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=9.38/9.39 12:21:45
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=2.63/2.63 12:21:49
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=8.00/8.00 12:21:58
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.07/0.08 12:21:59
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=0.01/0.01 12:22:00
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.03/0.03 12:22:01
?
****
?
Buffer 100 chars X 300,000 loops
C optimiser turned ON
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A 16 STs memset()
Mismatch at 99
Postscript Error in iteration 300
?... failed
A MVCL memset()
Tests completed
Ready; T=5.55/6.03 12:39:00
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=9.22/9.22 12:39:10
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=2.82/2.82 12:39:13
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=1.29/1.29 12:39:16
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=2.40/2.40 12:39:19
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.34/0.34 12:39:20
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=0.01/0.01 12:39:21
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.24/0.24 12:39:22
?
****
?
Buffer 100,000 chars x 5,000 loops
C optimiser turned ON
?
memset() functional test
Builtin memset()
C bytewise memset()
C wordwise 32 unaligned memset()
C duffs device memset()
A MVC memset()
Mismatch at 99
Postscript Error in iteration 1
?... failed
A 16 STs memset()
Mismatch at 99
Postscript Error in iteration 300
?... failed
A MVCL memset()
Tests completed
Ready; T=60.24/60.68 12:42:42
?
memset() performance test 1
Builtin memset()
Tests completed
Ready; T=164.75/164.84 12:45:28
?
memset() performance test 2
C bytewise memset()
Tests completed
Ready; T=41.58/41.59 12:46:10
?
memset() performance test 3
C wordwise 32 unaligned memset()
Tests completed
Ready; T=11.08/11.08 12:46:22
?
memset() performance test 4
C duffs device memset()
Tests completed
Ready; T=33.17/33.18 12:46:56
?
memset() performance test 5
A MVC memset()
Tests completed
Ready; T=0.19/0.19 12:46:57
?
memset() performance test 6
A 16 STs memset()
Tests completed
Ready; T=0.01/0.01 12:46:58
?
memset() performance test 7
A MVCL memset()
Tests completed
Ready; T=0.03/0.04 12:46:59
?
Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

My take on this:

a long poll wait time is not that bad, important is that the exec can stop without me forcing off the user
a short poll time is wasteful, and we are not in the business of using HX all day, only when we need to

on VM I have the experience of needing to wait for dirmaint, or to have to send CP WNG userid hello before a FORCE takes effect; a long poll time before a HX takes effect is OK.

¸é±ð²Ô¨¦.


On 23 Apr 2020, at 14:21, adriansutherland67 <adrian@...> wrote:

On Thu, Apr 23, 2020 at 12:13 PM, Dave Wade wrote:
I think that would be a challenge and you would either waste lot of time polling the flag, or risk running for a long time before detecting it.
Indeed, I abhor polling - but isn't that how CMS itself does HX?

The HX command is executed when the next SVC or I/O interruption occurs: therefore a delay may occur between keying HX and the return to CMS.

I too can poll on an I/O interrupt ...

Is the challenge that the flag does not exist - or the worry about polling?

Re: Program Interrupts (signals)

 

On Thu, Apr 23, 2020 at 12:13 PM, Dave Wade wrote:
I think that would be a challenge and you would either waste lot of time polling the flag, or risk running for a long time before detecting it.
Indeed, I abhor polling - but isn't that how CMS itself does HX?

The HX command is executed when the next SVC or I/O interruption occurs: therefore a delay may occur between keying HX and the return to CMS.

I too can poll on an I/O interrupt ...

Is the challenge that the flag does not exist - or the worry about polling?
Re: Program Interrupts (signals)

 

dave,

i didnt?mean that CP would abend. i meant that the PIC would be thrown by CP. Sorry for the confusion.

Joe

On Thu, Apr 23, 2020 at 6:02 AM Dave Wade <dave.g4ugm@...> wrote:

Joe,

?

How can CP ABEND? Really CP is a distraction in this case AND CAN BE IGNORED. Saying CP ABENDS is like saying MVS abends when a program interrupts. Certainly, CP will receive control because CMS is running in REAL problem state.

But CP will simulate the effect of the divide by zero and pass control to the address specified in the VM¡¯s low storage location, just as if CMS was running on real hardware .

?A program running in a VM always runs in real problem state. If its in virtual supervisor state then CP has to simulate any operations the VM carries out that require real supervisor state, converting between real/virtual addresses as required.

In this case CMS is un-aware that CP got involved. All it knows is it plugged an address, as part of a new PSW into the appropriate low store location, a pic 9 has occurred, and execution has transferred to the handler pointed to by the new PSW.

The address where the exception occurred will be part of the old psw in the VM¡¯s low store. S/370 hardware is designed so that any operation that could allow the supervisor state to be examined is a privileged instruction. ?

?This is not true for XA onwards which is why you need SIE for VM on these architectures¡­..

?

Adrian,

?

Sadly my searches indicate that catching HX needs a CMS mod.

?

?

(note that¡¯s SP3 that¡¯s mentioned in there which is much later than R6)

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 23 April 2020 11:26
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

I think?you might be slightly confused.

?

Lets take the example of a divide by zero.

?

CMS will not abend that. Rather, CP will because its a hardware abend.?You will get a PIC 9.?CMS will detect it and take action by default, which may be undesirable. Within a C runtime, you can trap a PIC 9 by issuing a SPIE, and specifying?an exit to take.

?

SPIE stands for Set Program Interrupt Exit.?

?

So, as part of your C runtime prolog, you issue an SPIE for PIC 9 before you give control to main, and set a branch to a location where you have the ability to cleanly close any IO in process and de-allocate?any memory before termination by the C runtime epilog.

?

Joe

?

On Thu, Apr 23, 2020 at 4:58 AM adriansutherland67 <adrian@...> wrote:

On Thu, Apr 23, 2020 at 09:52 AM, Dave Wade wrote:

Doesn¡¯t SPIE cover all of these. Also STAE is available

You see - I have no idea really! I can only follow advice. There are two additional concerns, which are specific if GCCLIB.

1/ If a CMS Abent clears freemen (and I think it doesn't?), we have a bit of a problem because multiple programs memory will be trashed so I would seek to stop the CMS ABEND and instead just close the program if that makes sense?

2/ HX ... how can I convert that to a signal?

Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

Adrian,

?

I think that would be a challenge and you would either waste lot of time polling the flag, or risk running for a long time before detecting it.

I must say CMS is by design, single threaded, pretty much interrupt free, so it uses blocking CP calls for disk IO, for example.

The idea was that anything ¡°multi¡± was handled by CP. Especially at the level we are at there is very clean divide between CP and CMS.

CP provides a virtual 370 (VM) to each user. It manages mapping the users virtual world back to the ¡°real¡± world.

Virtual devices back to real devices and stops users from trampling on each other. Handling device sharing¡­

?

¡­ this means CMS is pretty simple about the same as MS DOS 1.1. No directories, no virtual memory, no shared file store, no passwords.

All it sees is a console, some disks, and a reader/punch/printer. It knows nothing of any other virtual machine.

So for example the MVS file IO simulation is much smaller and lighter than the MVS equivalent, but it does not have to worry about concurrent access¡­

?

Dave

?

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 23 April 2020 12:31
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

On Thu, Apr 23, 2020 at 11:02 AM, Dave Wade wrote:

Sadly my searches indicate that catching HX needs a CMS mod.

?

Thanks Dave

Great find however.

Would this work:

Could I use the HX suppression mod to stop HX. But them within GCCLIB poll the HX flag myself (is there a flag?) and if set, exit gracefully. By the way if this works it means I can make HX do what HI does for BREXX if that makes sense.

A
Re: Program Interrupts (signals)

 

On Thu, Apr 23, 2020 at 11:02 AM, Dave Wade wrote:

Sadly my searches indicate that catching HX needs a CMS mod.

?

Thanks Dave

Great find however.

Would this work:

Could I use the HX suppression mod to stop HX. But them within GCCLIB poll the HX flag myself (is there a flag?) and if set, exit gracefully. By the way if this works it means I can make HX do what HI does for BREXX if that makes sense.

A
Re: Program Interrupts (signals)

 

On Thu, Apr 23, 2020 at 10:26 AM, Joe Monk wrote:
I think?you might be slightly confused.
I think I am very confused :-)

What I will do is
- Make sure the GCCLIB internals is worked wrt signals (fake signals if you like)
- Do a PoC with SPIE?etc. and see what happens with closing files, memory etc etc. See what (if anything) HX does. That might be a stopgap or the final answer.
- Suggest a "pure-CMS" approach that Rob (and others) might want to help on. Obs IBM introduced ABNEXIT to fill this very gap - and maybe that is the spec (but that might be much too hard to do), it can be more rough and ready as its only user will be GCCLIB.

And I will do some diagrams to help people understand the dependencies now between the resident nature of GCCLIB, BREXX, and other GCCLIB clients.?

It is interesting.

And it kind of shows the rough and ready nature of CMS itself - certainly back in the day (I don't? know now). It must have been a culture shock for the OS guys :-)
5421 - 5440 of 6538