Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #59082 > unrolled thread
| Started by | lawrencedo99@gmail.com |
|---|---|
| First post | 2016-06-29 02:53 -0700 |
| Last post | 2016-07-06 15:42 +0000 |
| Articles | 20 on this page of 35 — 7 participants |
Back to article view | Back to comp.os.vms
Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-06-29 02:53 -0700
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-06-29 13:36 +0200
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-06-29 16:05 -0700
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-06-30 14:45 +0200
Re: Pointless Nostalgia: System Service Dispatching moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-30 16:53 +0000
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-06-30 15:32 -0700
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-06-30 16:55 +0000
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-06-30 21:13 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-06-30 19:52 +0000
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-07-01 14:11 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-01 12:46 +0000
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-07-01 17:40 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-01 16:59 +0000
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-07-01 19:45 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-01 20:01 +0000
Re: Pointless Nostalgia: System Service Dispatching Johnny Billquist <bqt@softjar.se> - 2016-07-04 12:35 +0200
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-07-01 15:18 -0700
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-02 20:02 +0000
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-07-03 14:10 -0700
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-07-04 14:56 -0700
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-04 13:25 +0000
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-05 00:46 +0000
Re: Pointless Nostalgia: System Service Dispatching David Froble <davef@tsoft-inc.com> - 2016-07-05 08:43 -0400
Re: Pointless Nostalgia: System Service Dispatching lawrencedo99@gmail.com - 2016-07-05 15:40 -0700
Re: Pointless Nostalgia: System Service Dispatching Paul Sture <nospam@sture.ch> - 2016-07-06 07:33 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-06 00:08 +0000
Re: Pointless Nostalgia: System Service Dispatching David Froble <davef@tsoft-inc.com> - 2016-07-05 22:57 -0400
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-06 10:43 +0000
Re: Pointless Nostalgia: System Service Dispatching Paul Sture <nospam@sture.ch> - 2016-07-05 12:30 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-05 13:00 +0000
Re: Pointless Nostalgia: System Service Dispatching Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-06 15:12 +0000
Re: Pointless Nostalgia: System Service Dispatching Paul Sture <nospam@sture.ch> - 2016-07-06 21:50 +0200
[OT] Real Genius, was: Re: Pointless Nostalgia: System Service Dispatching Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-07 19:55 +0000
Re: [OT] Real Genius, was: Re: Pointless Nostalgia: System Service Dispatching Paul Sture <nospam@sture.ch> - 2016-07-07 22:27 +0200
Re: Pointless Nostalgia: System Service Dispatching VAXman- @SendSpamHere.ORG - 2016-07-06 15:42 +0000
Page 1 of 2 [1] 2 Next page →
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-29 02:53 -0700 |
| Subject | Pointless Nostalgia: System Service Dispatching |
| Message-ID | <d52289cd-00cc-4356-a3bd-03b8c574c356@googlegroups.com> |
This is all water under the bridge now, but I remember something peculiar about the way system services were dispatched on the VAX using the CHMK instruction, particularly. As I recall from reading the “Internals & Data Structures” manual, each system service was invoked using the “CHMK #<code>” instruction, with a code identifying the system service. This instruction had to be 4 bytes long. To ensure this (and prevent optimization to short literals by the assembler), the codes were forward-defined in MACRO. This seemed an unnecessarily roundabout way to do things, when you could have just written “CHMK I^#<code>” to force immediate-mode literals. The other thing was, the CHMx instructions caused traps, not faults. Thus, restartable services (e.g. $HIBER) required the caller’s PC to be backed up by 4 before putting the process on a suitable wait queue. When it was woken up, the CHMK instruction would be automatically re-executed. This allowed, for example, ASTs to temporarily interrupt a hibernating process, after which the process would return to hibernation, unless a $WAKE had been done in the meantime (perhaps in the AST itself), whereupon the $HIBER call would simply fall through and the process would resume normal execution. Again, this could have been done a little simpler: why could the CHMx instructions not have triggered a fault (saved PC left pointing at start of instruction) rather than a trap (saved PC pointing at next instruction)? And the saved PSL would have had the FPD bit set. When one of these instructions was executed with FPD set, it would simply fall through as a no-op. Thus, restarting the system service would be as simple as clearing FPD in the saved PSL. The REI would do the rest. So much more elegant, do you think? I think the original VAX engineers missed a trick there...
[toc] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-29 13:36 +0200 |
| Message-ID | <nl0br9$5q7$1@Iltempo.Update.UU.SE> |
| In reply to | #59082 |
On 2016-06-29 11:53, lawrencedo99@gmail.com wrote: > This is all water under the bridge now, but I remember something peculiar about the way system services were dispatched on the VAX using the CHMK instruction, particularly. > > As I recall from reading the “Internals & Data Structures” manual, each system service was invoked using the “CHMK #<code>” instruction, with a code identifying the system service. > > This instruction had to be 4 bytes long. To ensure this (and prevent optimization to short literals by the assembler), the codes were forward-defined in MACRO. This seemed an unnecessarily roundabout way to do things, when you could have just written “CHMK I^#<code>” to force immediate-mode literals. > > The other thing was, the CHMx instructions caused traps, not faults. Thus, restartable services (e.g. $HIBER) required the caller’s PC to be backed up by 4 before putting the process on a suitable wait queue. When it was woken up, the CHMK instruction would be automatically re-executed. > > This allowed, for example, ASTs to temporarily interrupt a hibernating process, after which the process would return to hibernation, unless a $WAKE had been done in the meantime (perhaps in the AST itself), whereupon the $HIBER call would simply fall through and the process would resume normal execution. > > Again, this could have been done a little simpler: why could the CHMx instructions not have triggered a fault (saved PC left pointing at start of instruction) rather than a trap (saved PC pointing at next instruction)? And the saved PSL would have had the FPD bit set. When one of these instructions was executed with FPD set, it would simply fall through as a no-op. Thus, restarting the system service would be as simple as clearing FPD in the saved PSL. The REI would do the rest. > > So much more elegant, do you think? > > I think the original VAX engineers missed a trick there... I don't know for sure about VMS here, but if it works the same way as RSX, the system calls are never restarted, so no need to backup, and thus also no need to figure out the size of the instruction that caused the system call. (On a PDP-11 it's trivial, though, as the instruction used to cause a system call is fixed size anyway, and would be easy to back up and re-execute). Normally, at the end of an AST, the system will either just directly cause the process to go back to sleep, or wake up, depending on why it was stopped before, and if those conditions still apply. The system call that caused the process to get into this state is not re-executed. That would actually be a rather silly waste of time, and potentially cause other odd side effect you do not want. Consider a $QIOW for example. If you get an AST, you do not want the $QIOW to be reexecuted. You just want the process to continue the wait, unless the conditions for the wait are now fulfilled. Also, returning back to user mode at the end of an AST, to only immediately do a system call to get back into the kernel again is a rather long way for something you want to process. Better just get there directly without all that overhead. And if I'm thus right, then your idea wouldn't really be of that much use. And then I really wonder if the CHMx instructions really must be coded with a constant as the argument in the first place. Anyone else who knows some specifics on VMS here who can confirm or correct? However, all this said, I bet this is something required by Unix on VAXen, as you often restart system calls there... Johnny
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-29 16:05 -0700 |
| Message-ID | <11185428-ecac-4acc-814e-b3a1063a4bf4@googlegroups.com> |
| In reply to | #59087 |
On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: > Consider a $QIOW for example. If you get an AST, you do not want the $QIOW > to be reexecuted. That’s not a problem, because there is no actual $QIOW system call.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-30 14:45 +0200 |
| Message-ID | <nl3491$rou$1@Iltempo.Update.UU.SE> |
| In reply to | #59114 |
On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: > On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >> to be reexecuted. > > That’s not a problem, because there is no actual $QIOW system call. There isn't? Did I place the $ on the wrong side or something now? Or what are you suggesting? Johnny
[toc] | [prev] | [next] | [standalone]
| From | moroney@world.std.spaamtrap.com (Michael Moroney) |
|---|---|
| Date | 2016-06-30 16:53 +0000 |
| Message-ID | <nl3ipt$cs$2@pcls7.std.com> |
| In reply to | #59146 |
Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>> to be reexecuted. >> >> That'冱 not a problem, because there is no actual $QIOW system call. >There isn't? Did I place the $ on the wrong side or something now? Or >what are you suggesting? $QIOW (and most $xxxW services which also have a corresponding $xxx service) are implemented as a $QIO followed immediately by a $SYNCH of the specified event flag/IOSB pair. I believe there is a stub routine that makes both calls. I believe only $HIBER can potentially be re-executed. It does (at least on VAX) some funky stack manipulation to place a call to the internal routine back on the stack rather than the following instruction. The called routine determines whether to actually hibernate based on internal states.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-30 15:32 -0700 |
| Message-ID | <66792029-1a95-4a36-8fcf-c4243881252c@googlegroups.com> |
| In reply to | #59163 |
On Friday, July 1, 2016 at 4:54:03 AM UTC+12, Michael Moroney wrote: > $QIOW (and most $xxxW services which also have a corresponding $xxx service) > are implemented as a $QIO followed immediately by a $SYNCH of the specified > event flag/IOSB pair. That was the one. Originally it was a simple $WAITFR, but this was replaced with the more robust $SYNCH in VMS V4 or something. > I believe only $HIBER can potentially be re-executed. All the process-blocking ones, including $SYNCH and all the $WAITxx calls, were restartable.
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-30 16:55 +0000 |
| Message-ID | <00B0B657.24DF3378@SendSpamHere.ORG> |
| In reply to | #59146 |
In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>> to be reexecuted. >> >> That’s not a problem, because there is no actual $QIOW system call. > >There isn't? Did I place the $ on the wrong side or something now? Or >what are you suggesting? SYS$QIOW => SYS$QIO+SYS$SYNCH -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-30 21:13 +0200 |
| Message-ID | <nl3r1k$f2f$1@Iltempo.Update.UU.SE> |
| In reply to | #59164 |
On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote: > In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>>> to be reexecuted. >>> >>> That’s not a problem, because there is no actual $QIOW system call. >> >> There isn't? Did I place the $ on the wrong side or something now? Or >> what are you suggesting? > > SYS$QIOW => SYS$QIO+SYS$SYNCH Functionally, yes. But does it actually put two different syscalls in your instruction stream, one after the other? On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really is the same as a QIO$ followed by a WTEF$ Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S calls different functions. But what those functions do, in turn, I don't know. (SYS$QIO and SYS$QIOW) Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-30 19:52 +0000 |
| Message-ID | <00B0B66F.E33DC123@SendSpamHere.ORG> |
| In reply to | #59172 |
In article <nl3r1k$f2f$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote:
>> In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote:
>>>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote:
>>>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW
>>>>> to be reexecuted.
>>>>
>>>> That’s not a problem, because there is no actual $QIOW system call.
>>>
>>> There isn't? Did I place the $ on the wrong side or something now? Or
>>> what are you suggesting?
>>
>> SYS$QIOW => SYS$QIO+SYS$SYNCH
>
>Functionally, yes. But does it actually put two different syscalls in
>your instruction stream, one after the other?
In *your* instruction stream meaning the code YOU'VE written? No. There's
a vector you'd call that maintains the 2 system calls.
>On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really
>is the same as a QIO$ followed by a WTEF$
>
>Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S
>calls different functions. But what those functions do, in turn, I don't
>know. (SYS$QIO and SYS$QIOW)
.MACRO $QIO_S EFN=#0,CHAN,FUNC,IOSB=0,ASTADR=0,ASTPRM=#0,-
P1=0,P2=#0,P3=#0,P4=#0,P5=#0,P6=#0
.GLOBL SYS$QIO
$PUSHTWO P6,P5
$PUSHTWO P4,P3
PUSHL P2
$PUSHADR P1
$QIOPUSH ASTPRM,ASTADR
$PUSHADR IOSB,CONTEXT=Q
MOVZWL FUNC,-(SP)
MOVZWL CHAN,-(SP)
PUSHL EFN
CALLS #12,G^SYS$QIO
.ENDM $QIO_S
.MACRO $QIOW_S EFN=#0,CHAN,FUNC,IOSB=0,ASTADR=0,ASTPRM=#0,-
P1=0,P2=#0,P3=#0,P4=#0,P5=#0,P6=#0
.GLOBL SYS$QIOW
$PUSHTWO P6,P5
$PUSHTWO P4,P3
PUSHL P2
$PUSHADR P1
$QIOPUSH ASTPRM,ASTADR
$PUSHADR IOSB,CONTEXT=Q
MOVZWL FUNC,-(SP)
MOVZWL CHAN,-(SP)
PUSHL EFN
CALLS #12,G^SYS$QIOW
.ENDM $QIOW_S
But that SYS$QIOW looks something like:
.ENTRY SYS$QIOW,0
$QIOWDEF
$SYNCHDEF
CALLG (AP),G^SYS$QIO
BLBC R0,ERROR
PUSHL QIOW$_IOSB(AP)
PUSHL QIOW$_EFN(AP)
CALLS #SYNCH$_NARGS,G^SYS$SYNCH
ERROR: RET
It's actually a bit more elaborate today due to threads but nothing to write
home about.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-07-01 14:11 +0200 |
| Message-ID | <nl5mlr$1ou$1@Iltempo.Update.UU.SE> |
| In reply to | #59176 |
On 2016-06-30 21:52, VAXman-@SendSpamHere.ORG wrote: > In article <nl3r1k$f2f$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote: >>> In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >>>>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>>>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>>>>> to be reexecuted. >>>>> >>>>> That’s not a problem, because there is no actual $QIOW system call. >>>> >>>> There isn't? Did I place the $ on the wrong side or something now? Or >>>> what are you suggesting? >>> >>> SYS$QIOW => SYS$QIO+SYS$SYNCH >> >> Functionally, yes. But does it actually put two different syscalls in >> your instruction stream, one after the other? > > In *your* instruction stream meaning the code YOU'VE written? No. There's > a vector you'd call that maintains the 2 system calls. I was meaning in my instruction stream as in the userland code. If that is code I wrote, or code in a library makes no difference. As the question was if the system call is restarted, we're talking about the system call that happens from userland, in my instruction stream. >> On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really >> is the same as a QIO$ followed by a WTEF$ >> >> Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S >> calls different functions. But what those functions do, in turn, I don't >> know. (SYS$QIO and SYS$QIOW) > [...] Already told you I knew what the macros did... :-) > But that SYS$QIOW looks something like: > > .ENTRY SYS$QIOW,0 > $QIOWDEF > $SYNCHDEF > CALLG (AP),G^SYS$QIO > BLBC R0,ERROR > PUSHL QIOW$_IOSB(AP) > PUSHL QIOW$_EFN(AP) > CALLS #SYNCH$_NARGS,G^SYS$SYNCH > ERROR: RET > > > It's actually a bit more elaborate today due to threads but nothing to write > home about. Ok, so it would be two separate system calls under VMS then. Like I said, in RSX, QIO and QIOW are two different system calls. Even though QIOW is actually a combination of a QIO and a WTEF. So redoing the system call would be a bad thing. At exit from whatever, the system call is never backed up and reexecuted. So could you confirm that VMS backs up the PC and re-execute the system call sometimes? Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-07-01 12:46 +0000 |
| Message-ID | <00B0B6FD.93802360@SendSpamHere.ORG> |
| In reply to | #59176 |
In article <nl5mlr$1ou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2016-06-30 21:52, VAXman-@SendSpamHere.ORG wrote:
>> In article <nl3r1k$f2f$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>> On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote:
>>>> In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>>> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote:
>>>>>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote:
>>>>>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW
>>>>>>> to be reexecuted.
>>>>>>
>>>>>> That’s not a problem, because there is no actual $QIOW system call.
>>>>>
>>>>> There isn't? Did I place the $ on the wrong side or something now? Or
>>>>> what are you suggesting?
>>>>
>>>> SYS$QIOW => SYS$QIO+SYS$SYNCH
>>>
>>> Functionally, yes. But does it actually put two different syscalls in
>>> your instruction stream, one after the other?
>>
>> In *your* instruction stream meaning the code YOU'VE written? No. There's
>> a vector you'd call that maintains the 2 system calls.
>
>I was meaning in my instruction stream as in the userland code. If that
>is code I wrote, or code in a library makes no difference. As the
>question was if the system call is restarted, we're talking about the
>system call that happens from userland, in my instruction stream.
>
>>> On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really
>>> is the same as a QIO$ followed by a WTEF$
>>>
>>> Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S
>>> calls different functions. But what those functions do, in turn, I don't
>>> know. (SYS$QIO and SYS$QIOW)
>>
>
>[...]
>
>Already told you I knew what the macros did... :-)
>
>> But that SYS$QIOW looks something like:
>>
>> .ENTRY SYS$QIOW,0
>> $QIOWDEF
>> $SYNCHDEF
>> CALLG (AP),G^SYS$QIO
>> BLBC R0,ERROR
>> PUSHL QIOW$_IOSB(AP)
>> PUSHL QIOW$_EFN(AP)
>> CALLS #SYNCH$_NARGS,G^SYS$SYNCH
>> ERROR: RET
>>
>>
>> It's actually a bit more elaborate today due to threads but nothing to write
>> home about.
>
>Ok, so it would be two separate system calls under VMS then.
Yes, there's both a SYS$QIO and a SYS$QQIOW.
>Like I said, in RSX, QIO and QIOW are two different system calls.
>Even though QIOW is actually a combination of a QIO and a WTEF.
>So redoing the system call would be a bad thing. At exit from whatever,
>the system call is never backed up and reexecuted.
Why sh/would it be? CHMx (x: K, E, S ,U) pushes the PC/PSL on the target mode
stack where an REI can find it. The PC is that of the instruction following the
CHMx. The CHMx also pushes the argument on the stack. There's an exception
mode handler whick will dispatch to the appropriate system service handler in
the target mode. Sanity checks, access probes, etc. are performed to validate
that everything is on the up-and-up before execution.
>So could you confirm that VMS backs up the PC and re-execute the system
>call sometimes?
I don't believe that's so. The only way back home, so to speak, is via the
REI instruction. That pops the saved PC/PSL from the stack, restoring the
original mode and execution resumes at the next instruction after the CHMx.
REI, on VAX, does a number of other things too but that's beyond what you've
asked.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-07-01 17:40 +0200 |
| Message-ID | <nl62u3$ork$1@Iltempo.Update.UU.SE> |
| In reply to | #59225 |
On 2016-07-01 14:46, VAXman-@SendSpamHere.ORG wrote: > In article <nl5mlr$1ou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-30 21:52, VAXman-@SendSpamHere.ORG wrote: >>> In article <nl3r1k$f2f$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote: >>>>> In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >>>>>>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>>>>>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>>>>>>> to be reexecuted. >>>>>>> >>>>>>> That’s not a problem, because there is no actual $QIOW system call. >>>>>> >>>>>> There isn't? Did I place the $ on the wrong side or something now? Or >>>>>> what are you suggesting? >>>>> >>>>> SYS$QIOW => SYS$QIO+SYS$SYNCH >>>> >>>> Functionally, yes. But does it actually put two different syscalls in >>>> your instruction stream, one after the other? >>> >>> In *your* instruction stream meaning the code YOU'VE written? No. There's >>> a vector you'd call that maintains the 2 system calls. >> >> I was meaning in my instruction stream as in the userland code. If that >> is code I wrote, or code in a library makes no difference. As the >> question was if the system call is restarted, we're talking about the >> system call that happens from userland, in my instruction stream. >> >>>> On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really >>>> is the same as a QIO$ followed by a WTEF$ >>>> >>>> Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S >>>> calls different functions. But what those functions do, in turn, I don't >>>> know. (SYS$QIO and SYS$QIOW) >>> >> >> [...] >> >> Already told you I knew what the macros did... :-) >> >>> But that SYS$QIOW looks something like: >>> >>> .ENTRY SYS$QIOW,0 >>> $QIOWDEF >>> $SYNCHDEF >>> CALLG (AP),G^SYS$QIO >>> BLBC R0,ERROR >>> PUSHL QIOW$_IOSB(AP) >>> PUSHL QIOW$_EFN(AP) >>> CALLS #SYNCH$_NARGS,G^SYS$SYNCH >>> ERROR: RET >>> >>> >>> It's actually a bit more elaborate today due to threads but nothing to write >>> home about. >> >> Ok, so it would be two separate system calls under VMS then. > > Yes, there's both a SYS$QIO and a SYS$QQIOW. Those are the system library routine that gets called. They, in turn, will do some system call(s). Which are done through CHMK. Those are the ones I'm curious about. Are the SYS$QIOW routine in essence doing two CHMK insturctions in the end? One to do the QIO part, and one to do the SYNCH? Your posted code above suggest that this would be the case, but since you said "looks something like this", it suggested that this is not the actual code, but your interpretation of what happens. >> Like I said, in RSX, QIO and QIOW are two different system calls. >> Even though QIOW is actually a combination of a QIO and a WTEF. >> So redoing the system call would be a bad thing. At exit from whatever, >> the system call is never backed up and reexecuted. > > Why sh/would it be? CHMx (x: K, E, S ,U) pushes the PC/PSL on the target mode > stack where an REI can find it. The PC is that of the instruction following the > CHMx. The CHMx also pushes the argument on the stack. There's an exception > mode handler whick will dispatch to the appropriate system service handler in > the target mode. Sanity checks, access probes, etc. are performed to validate > that everything is on the up-and-up before execution. Right. This is the basics. I'm not sure what your "Why sh/would it be?" refers to. Is it a question why it would be a bad thing? Is it about backing up and reexecuting? >> So could you confirm that VMS backs up the PC and re-execute the system >> call sometimes? > > I don't believe that's so. The only way back home, so to speak, is via the > REI instruction. That pops the saved PC/PSL from the stack, restoring the > original mode and execution resumes at the next instruction after the CHMx. > REI, on VAX, does a number of other things too but that's beyond what you've > asked. Right. But the OP suggested that the PC is backed up to before the CHMK instrucction, and the CHMK instruction is reexecuted. I said I wouldn't think this was the case in VMS, as I don't believe system calls are reexecuted. Just as they are not in RSX. And it can potentially be a bad thing to reexecute some system calls. But the OP suggested that it was done, and because of this, the CHMK instruction from the OS point of view had an additional requirement on the argument, so that the length of the total instruction was known, so that you actually could figure out how much to back up the PC in order to do the reexecution. However, I know that Unix uses such tricks. And I'm wondering if the OP just was a bit confused on the point, in which case there was a good reason that the DEC engineers did not use the "trick" the OP suggested, as DEC had no need of this construct in the first place. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-07-01 16:59 +0000 |
| Message-ID | <00B0B720.EF353C98@SendSpamHere.ORG> |
| In reply to | #59225 |
In article <nl62u3$ork$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-07-01 14:46, VAXman-@SendSpamHere.ORG wrote: >> In article <nl5mlr$1ou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-30 21:52, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nl3r1k$f2f$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-30 18:55, VAXman-@SendSpamHere.ORG wrote: >>>>>> In article <nl3491$rou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>> On 2016-06-30 01:05, lawrencedo99@gmail.com wrote: >>>>>>>> On Wednesday, June 29, 2016 at 11:36:10 PM UTC+12, Johnny Billquist wrote: >>>>>>>>> Consider a $QIOW for example. If you get an AST, you do not want the $QIOW >>>>>>>>> to be reexecuted. >>>>>>>> >>>>>>>> That’s not a problem, because there is no actual $QIOW system call. >>>>>>> >>>>>>> There isn't? Did I place the $ on the wrong side or something now? Or >>>>>>> what are you suggesting? >>>>>> >>>>>> SYS$QIOW => SYS$QIO+SYS$SYNCH >>>>> >>>>> Functionally, yes. But does it actually put two different syscalls in >>>>> your instruction stream, one after the other? >>>> >>>> In *your* instruction stream meaning the code YOU'VE written? No. There's >>>> a vector you'd call that maintains the 2 system calls. >>> >>> I was meaning in my instruction stream as in the userland code. If that >>> is code I wrote, or code in a library makes no difference. As the >>> question was if the system call is restarted, we're talking about the >>> system call that happens from userland, in my instruction stream. >>> >>>>> On RSX, QIO$ and QIOW$ are two different DICs, even though QIOW$ really >>>>> is the same as a QIO$ followed by a WTEF$ >>>>> >>>>> Looking on a VMS system, it's a bit unclear. The $QIO_S and $QIOW_S >>>>> calls different functions. But what those functions do, in turn, I don't >>>>> know. (SYS$QIO and SYS$QIOW) >>>> >>> >>> [...] >>> >>> Already told you I knew what the macros did... :-) >>> >>>> But that SYS$QIOW looks something like: >>>> >>>> .ENTRY SYS$QIOW,0 >>>> $QIOWDEF >>>> $SYNCHDEF >>>> CALLG (AP),G^SYS$QIO >>>> BLBC R0,ERROR >>>> PUSHL QIOW$_IOSB(AP) >>>> PUSHL QIOW$_EFN(AP) >>>> CALLS #SYNCH$_NARGS,G^SYS$SYNCH >>>> ERROR: RET >>>> >>>> >>>> It's actually a bit more elaborate today due to threads but nothing to write >>>> home about. >>> >>> Ok, so it would be two separate system calls under VMS then. >> >> Yes, there's both a SYS$QIO and a SYS$QQIOW. > >Those are the system library routine that gets called. They, in turn, >will do some system call(s). Which are done through CHMK. Those are the >ones I'm curious about. They're fixed/static/absolute addresses/locations on VAX, not system library routines. >Are the SYS$QIOW routine in essence doing two CHMK insturctions in the >end? One to do the QIO part, and one to do the SYNCH? Your posted code >above suggest that this would be the case, but since you said "looks >something like this", it suggested that this is not the actual code, but >your interpretation of what happens. SDA> EXAMINE/INSTRUCTION EXE$QIO+2;5 EXE$QIO+00002: CHMK #0033 EXE$QIO+00006: RET EXE$QIO+00007: HALT SDA> EXAMINE/INSTRUCTION EXE$QIOW+2;B SYS$S0_VECTOR_BASE+00002: CHMK #0033 SYS$S0_VECTOR_BASE+00006: BLBC R0,EXE$QIOW_2+00007 EXE$QIOW_2+00001: PUSHL 10(AP) EXE$QIOW_2+00004: BRW EXE$SYNCH+00005 EXE$QIOW_2+00007: RET SDA> EXAMINE/INSTRUCTION EXE$SYNCH+00005;29 EXE$SYNCH+00005: BEQL EXE$SYNCH+00026 EXE$SYNCH+00007: TSTW @00(SP) EXE$SYNCH+0000A: BNEQ EXE$SYNCH+00022 EXE$SYNCH+0000C: MOVL (SP),R5 EXE$SYNCH+0000F: CHMK #003D EXE$SYNCH+00013: BRB EXE$SYNCH+00017 EXE$SYNCH+00015: NOP EXE$SYNCH+00016: NOP EXE$SYNCH+00017: CMPW R0,#0711 EXE$SYNCH+0001C: BEQL EXE$SYNCH+0002C EXE$SYNCH+0001E: BLBS R0,EXE$SYNCH+00007 EXE$SYNCH+00021: RET EXE$SYNCH+00022: MOVL #01,R0 EXE$SYNCH+00025: RET EXE$SYNCH+00026: JMP @#P1SYSVECTORS+0027A EXE$SYNCH+0002C: BRW EXE$WAIT_FORM+00032 EXE$SYNCH+0002F: HALT >>> Like I said, in RSX, QIO and QIOW are two different system calls. >>> Even though QIOW is actually a combination of a QIO and a WTEF. >>> So redoing the system call would be a bad thing. At exit from whatever, >>> the system call is never backed up and reexecuted. >> >> Why sh/would it be? CHMx (x: K, E, S ,U) pushes the PC/PSL on the target mode >> stack where an REI can find it. The PC is that of the instruction following the >> CHMx. The CHMx also pushes the argument on the stack. There's an exception >> mode handler whick will dispatch to the appropriate system service handler in >> the target mode. Sanity checks, access probes, etc. are performed to validate >> that everything is on the up-and-up before execution. > >Right. >This is the basics. I'm not sure what your "Why sh/would it be?" refers >to. Is it a question why it would be a bad thing? Is it about backing up >and reexecuting? When/why sh/would it backup? >>> So could you confirm that VMS backs up the PC and re-execute the system >>> call sometimes? >> >> I don't believe that's so. The only way back home, so to speak, is via the >> REI instruction. That pops the saved PC/PSL from the stack, restoring the >> original mode and execution resumes at the next instruction after the CHMx. >> REI, on VAX, does a number of other things too but that's beyond what you've >> asked. > >Right. But the OP suggested that the PC is backed up to before the CHMK >instrucction, and the CHMK instruction is reexecuted. I said I wouldn't Why? I probably missed that part of this as I wasn't following it from the get-go. >think this was the case in VMS, as I don't believe system calls are >reexecuted. Just as they are not in RSX. And it can potentially be a bad >thing to reexecute some system calls. But the OP suggested that it was >done, and because of this, the CHMK instruction from the OS point of >view had an additional requirement on the argument, so that the length >of the total instruction was known, so that you actually could figure >out how much to back up the PC in order to do the reexecution. > >However, I know that Unix uses such tricks. And I'm wondering if the OP >just was a bit confused on the point, in which case there was a good >reason that the DEC engineers did not use the "trick" the OP suggested, >as DEC had no need of this construct in the first place. Very likely. I can understand the re-execution for some of the more complex VAX instructions but the CHMx just produces the exception it was designed for and then it's up to the exception handler (aka, the change mode to x service dispatcher). -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-07-01 19:45 +0200 |
| Message-ID | <nl6a7q$b6d$1@Iltempo.Update.UU.SE> |
| In reply to | #59253 |
On 2016-07-01 18:59, VAXman-@SendSpamHere.ORG wrote: > In article <nl62u3$ork$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> Are the SYS$QIOW routine in essence doing two CHMK insturctions in the >> end? One to do the QIO part, and one to do the SYNCH? Your posted code >> above suggest that this would be the case, but since you said "looks >> something like this", it suggested that this is not the actual code, but >> your interpretation of what happens. > > SDA> EXAMINE/INSTRUCTION EXE$QIO+2;5 > EXE$QIO+00002: CHMK #0033 > EXE$QIO+00006: RET > EXE$QIO+00007: HALT > > SDA> EXAMINE/INSTRUCTION EXE$QIOW+2;B > SYS$S0_VECTOR_BASE+00002: CHMK #0033 > SYS$S0_VECTOR_BASE+00006: BLBC R0,EXE$QIOW_2+00007 > EXE$QIOW_2+00001: PUSHL 10(AP) > EXE$QIOW_2+00004: BRW EXE$SYNCH+00005 > EXE$QIOW_2+00007: RET > > SDA> EXAMINE/INSTRUCTION EXE$SYNCH+00005;29 > EXE$SYNCH+00005: BEQL EXE$SYNCH+00026 > EXE$SYNCH+00007: TSTW @00(SP) > EXE$SYNCH+0000A: BNEQ EXE$SYNCH+00022 > EXE$SYNCH+0000C: MOVL (SP),R5 > EXE$SYNCH+0000F: CHMK #003D > EXE$SYNCH+00013: BRB EXE$SYNCH+00017 > EXE$SYNCH+00015: NOP > EXE$SYNCH+00016: NOP > EXE$SYNCH+00017: CMPW R0,#0711 > EXE$SYNCH+0001C: BEQL EXE$SYNCH+0002C > EXE$SYNCH+0001E: BLBS R0,EXE$SYNCH+00007 > EXE$SYNCH+00021: RET > EXE$SYNCH+00022: MOVL #01,R0 > EXE$SYNCH+00025: RET > EXE$SYNCH+00026: JMP @#P1SYSVECTORS+0027A > EXE$SYNCH+0002C: BRW EXE$WAIT_FORM+00032 > EXE$SYNCH+0002F: HALT Thanks. That answered that question. So it's two system calls. Interesting. Do you know if it was always this way in VMS? Like I said, in RSX it's two different system calls, and the handling of the wait part is setup on the kernel side. But then again, RSX is more simplistic in that you don't easily handle if you have several operations using the same even flag but different IOSBs. >>>> Like I said, in RSX, QIO and QIOW are two different system calls. >>>> Even though QIOW is actually a combination of a QIO and a WTEF. >>>> So redoing the system call would be a bad thing. At exit from whatever, >>>> the system call is never backed up and reexecuted. >>> >>> Why sh/would it be? CHMx (x: K, E, S ,U) pushes the PC/PSL on the target mode >>> stack where an REI can find it. The PC is that of the instruction following the >>> CHMx. The CHMx also pushes the argument on the stack. There's an exception >>> mode handler whick will dispatch to the appropriate system service handler in >>> the target mode. Sanity checks, access probes, etc. are performed to validate >>> that everything is on the up-and-up before execution. >> >> Right. >> This is the basics. I'm not sure what your "Why sh/would it be?" refers >> to. Is it a question why it would be a bad thing? Is it about backing up >> and reexecuting? > > When/why sh/would it backup? When "interrupted". This comes from the OP, so I'm maybe not the right person to answer. But in a Unix system, system calls can be interrupted, and then they are restarted. But for this, you back up the PC, and redo the system call. A typical example is if you are doing a read, for example, and no data have been read yet, and you get a signal. The signal cause a signal handler to be called. Rather similar to ASTs in many ways. But since Unix is pretty single-minded, and synchronous in nature, the fact that the signal handler gets called means the read system call is terminated. But as the read had not read anything yet, instead if continuing after the read once the signal handler finishes, the read system call will be re-executed. If, on the other hand, some data had already been read by the read system call, your read will instead finish, and deliver only the data already read in, and errno will be set to EINTR, signalling that the system call was interrpted. The application can then issue a new read, after taking care of the data already delivered. (Don't blame me for this design, but it's the way things work in Unix.} >>>> So could you confirm that VMS backs up the PC and re-execute the system >>>> call sometimes? >>> >>> I don't believe that's so. The only way back home, so to speak, is via the >>> REI instruction. That pops the saved PC/PSL from the stack, restoring the >>> original mode and execution resumes at the next instruction after the CHMx. >>> REI, on VAX, does a number of other things too but that's beyond what you've >>> asked. >> >> Right. But the OP suggested that the PC is backed up to before the CHMK >> instrucction, and the CHMK instruction is reexecuted. I said I wouldn't > > Why? I probably missed that part of this as I wasn't following it from the > get-go. Oh, you need to go back and read the original post of this thread. :-) >> think this was the case in VMS, as I don't believe system calls are >> reexecuted. Just as they are not in RSX. And it can potentially be a bad >> thing to reexecute some system calls. But the OP suggested that it was >> done, and because of this, the CHMK instruction from the OS point of >> view had an additional requirement on the argument, so that the length >> of the total instruction was known, so that you actually could figure >> out how much to back up the PC in order to do the reexecution. >> >> However, I know that Unix uses such tricks. And I'm wondering if the OP >> just was a bit confused on the point, in which case there was a good >> reason that the DEC engineers did not use the "trick" the OP suggested, >> as DEC had no need of this construct in the first place. > > Very likely. I can understand the re-execution for some of the more complex > VAX instructions but the CHMx just produces the exception it was designed for > and then it's up to the exception handler (aka, the change mode to x service > dispatcher). Right. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-07-01 20:01 +0000 |
| Message-ID | <00B0B73A.4F8D1985@SendSpamHere.ORG> |
| In reply to | #59253 |
In article <nl6a7q$b6d$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-07-01 18:59, VAXman-@SendSpamHere.ORG wrote: >> In article <nl62u3$ork$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> Are the SYS$QIOW routine in essence doing two CHMK insturctions in the >>> end? One to do the QIO part, and one to do the SYNCH? Your posted code >>> above suggest that this would be the case, but since you said "looks >>> something like this", it suggested that this is not the actual code, but >>> your interpretation of what happens. >> >> SDA> EXAMINE/INSTRUCTION EXE$QIO+2;5 >> EXE$QIO+00002: CHMK #0033 >> EXE$QIO+00006: RET >> EXE$QIO+00007: HALT >> >> SDA> EXAMINE/INSTRUCTION EXE$QIOW+2;B >> SYS$S0_VECTOR_BASE+00002: CHMK #0033 >> SYS$S0_VECTOR_BASE+00006: BLBC R0,EXE$QIOW_2+00007 >> EXE$QIOW_2+00001: PUSHL 10(AP) >> EXE$QIOW_2+00004: BRW EXE$SYNCH+00005 >> EXE$QIOW_2+00007: RET >> >> SDA> EXAMINE/INSTRUCTION EXE$SYNCH+00005;29 >> EXE$SYNCH+00005: BEQL EXE$SYNCH+00026 >> EXE$SYNCH+00007: TSTW @00(SP) >> EXE$SYNCH+0000A: BNEQ EXE$SYNCH+00022 >> EXE$SYNCH+0000C: MOVL (SP),R5 >> EXE$SYNCH+0000F: CHMK #003D >> EXE$SYNCH+00013: BRB EXE$SYNCH+00017 >> EXE$SYNCH+00015: NOP >> EXE$SYNCH+00016: NOP >> EXE$SYNCH+00017: CMPW R0,#0711 >> EXE$SYNCH+0001C: BEQL EXE$SYNCH+0002C >> EXE$SYNCH+0001E: BLBS R0,EXE$SYNCH+00007 >> EXE$SYNCH+00021: RET >> EXE$SYNCH+00022: MOVL #01,R0 >> EXE$SYNCH+00025: RET >> EXE$SYNCH+00026: JMP @#P1SYSVECTORS+0027A >> EXE$SYNCH+0002C: BRW EXE$WAIT_FORM+00032 >> EXE$SYNCH+0002F: HALT > >Thanks. That answered that question. So it's two system calls. >Interesting. Do you know if it was always this way in VMS? I'm pretty sure. You could, if you wanted to, issue a $QIO, do something in your code and then, do a $SYNCH (wait) on the $QIO. The $QIOW has this logic without any intervening code. >Like I said, in RSX it's two different system calls, and the handling of >the wait part is setup on the kernel side. > >But then again, RSX is more simplistic in that you don't easily handle >if you have several operations using the same even flag but different IOSBs. > >>>>> Like I said, in RSX, QIO and QIOW are two different system calls. >>>>> Even though QIOW is actually a combination of a QIO and a WTEF. >>>>> So redoing the system call would be a bad thing. At exit from whatever, >>>>> the system call is never backed up and reexecuted. >>>> >>>> Why sh/would it be? CHMx (x: K, E, S ,U) pushes the PC/PSL on the target mode >>>> stack where an REI can find it. The PC is that of the instruction following the >>>> CHMx. The CHMx also pushes the argument on the stack. There's an exception >>>> mode handler whick will dispatch to the appropriate system service handler in >>>> the target mode. Sanity checks, access probes, etc. are performed to validate >>>> that everything is on the up-and-up before execution. >>> >>> Right. >>> This is the basics. I'm not sure what your "Why sh/would it be?" refers >>> to. Is it a question why it would be a bad thing? Is it about backing up >>> and reexecuting? >> >> When/why sh/would it backup? > >When "interrupted". This comes from the OP, so I'm maybe not the right >person to answer. > >But in a Unix system, system calls can be interrupted, and then they are >restarted. But for this, you back up the PC, and redo the system call. > >A typical example is if you are doing a read, for example, and no data >have been read yet, and you get a signal. The signal cause a signal >handler to be called. Rather similar to ASTs in many ways. But since >Unix is pretty single-minded, and synchronous in nature, the fact that >the signal handler gets called means the read system call is terminated. >But as the read had not read anything yet, instead if continuing after >the read once the signal handler finishes, the read system call will be >re-executed. >If, on the other hand, some data had already been read by the read >system call, your read will instead finish, and deliver only the data >already read in, and errno will be set to EINTR, signalling that the >system call was interrpted. The application can then issue a new read, >after taking care of the data already delivered. > >(Don't blame me for this design, but it's the way things work in Unix.} > >>>>> So could you confirm that VMS backs up the PC and re-execute the system >>>>> call sometimes? >>>> >>>> I don't believe that's so. The only way back home, so to speak, is via the >>>> REI instruction. That pops the saved PC/PSL from the stack, restoring the >>>> original mode and execution resumes at the next instruction after the CHMx. >>>> REI, on VAX, does a number of other things too but that's beyond what you've >>>> asked. >>> >>> Right. But the OP suggested that the PC is backed up to before the CHMK >>> instrucction, and the CHMK instruction is reexecuted. I said I wouldn't >> >> Why? I probably missed that part of this as I wasn't following it from the >> get-go. > >Oh, you need to go back and read the original post of this thread. :-) > >>> think this was the case in VMS, as I don't believe system calls are >>> reexecuted. Just as they are not in RSX. And it can potentially be a bad >>> thing to reexecute some system calls. But the OP suggested that it was >>> done, and because of this, the CHMK instruction from the OS point of >>> view had an additional requirement on the argument, so that the length >>> of the total instruction was known, so that you actually could figure >>> out how much to back up the PC in order to do the reexecution. >>> >>> However, I know that Unix uses such tricks. And I'm wondering if the OP >>> just was a bit confused on the point, in which case there was a good >>> reason that the DEC engineers did not use the "trick" the OP suggested, >>> as DEC had no need of this construct in the first place. >> >> Very likely. I can understand the re-execution for some of the more complex >> VAX instructions but the CHMx just produces the exception it was designed for >> and then it's up to the exception handler (aka, the change mode to x service >> dispatcher). > >Right. If there's an interrupt (context switch or AST or whatever), I don't see why the CHMx would have to be re-executed. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-07-04 12:35 +0200 |
| Message-ID | <nlde65$bjl$1@Iltempo.Update.UU.SE> |
| In reply to | #59267 |
On 2016-07-01 22:01, VAXman-@SendSpamHere.ORG wrote: > In article <nl6a7q$b6d$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-07-01 18:59, VAXman-@SendSpamHere.ORG wrote: >>> In article <nl62u3$ork$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> Are the SYS$QIOW routine in essence doing two CHMK insturctions in the >>>> end? One to do the QIO part, and one to do the SYNCH? Your posted code >>>> above suggest that this would be the case, but since you said "looks >>>> something like this", it suggested that this is not the actual code, but >>>> your interpretation of what happens. >>> >>> SDA> EXAMINE/INSTRUCTION EXE$QIO+2;5 >>> EXE$QIO+00002: CHMK #0033 >>> EXE$QIO+00006: RET >>> EXE$QIO+00007: HALT >>> >>> SDA> EXAMINE/INSTRUCTION EXE$QIOW+2;B >>> SYS$S0_VECTOR_BASE+00002: CHMK #0033 >>> SYS$S0_VECTOR_BASE+00006: BLBC R0,EXE$QIOW_2+00007 >>> EXE$QIOW_2+00001: PUSHL 10(AP) >>> EXE$QIOW_2+00004: BRW EXE$SYNCH+00005 >>> EXE$QIOW_2+00007: RET >>> >>> SDA> EXAMINE/INSTRUCTION EXE$SYNCH+00005;29 >>> EXE$SYNCH+00005: BEQL EXE$SYNCH+00026 >>> EXE$SYNCH+00007: TSTW @00(SP) >>> EXE$SYNCH+0000A: BNEQ EXE$SYNCH+00022 >>> EXE$SYNCH+0000C: MOVL (SP),R5 >>> EXE$SYNCH+0000F: CHMK #003D >>> EXE$SYNCH+00013: BRB EXE$SYNCH+00017 >>> EXE$SYNCH+00015: NOP >>> EXE$SYNCH+00016: NOP >>> EXE$SYNCH+00017: CMPW R0,#0711 >>> EXE$SYNCH+0001C: BEQL EXE$SYNCH+0002C >>> EXE$SYNCH+0001E: BLBS R0,EXE$SYNCH+00007 >>> EXE$SYNCH+00021: RET >>> EXE$SYNCH+00022: MOVL #01,R0 >>> EXE$SYNCH+00025: RET >>> EXE$SYNCH+00026: JMP @#P1SYSVECTORS+0027A >>> EXE$SYNCH+0002C: BRW EXE$WAIT_FORM+00032 >>> EXE$SYNCH+0002F: HALT >> >> Thanks. That answered that question. So it's two system calls. >> Interesting. Do you know if it was always this way in VMS? > > I'm pretty sure. You could, if you wanted to, issue a $QIO, do something in > your code and then, do a $SYNCH (wait) on the $QIO. The $QIOW has this logic > without any intervening code. Yes, that is also true in RSX. That's a different issue/story/whatever. A QIO is still a separate from a QIOW call in RSX. Saves both on memory and CPU usage. One system call is much cheaper than two system calls. But if you want to, you can certainly write code yourself that do a QIO followed by a wait, if you want to. End effect is the same. >>>> think this was the case in VMS, as I don't believe system calls are >>>> reexecuted. Just as they are not in RSX. And it can potentially be a bad >>>> thing to reexecute some system calls. But the OP suggested that it was >>>> done, and because of this, the CHMK instruction from the OS point of >>>> view had an additional requirement on the argument, so that the length >>>> of the total instruction was known, so that you actually could figure >>>> out how much to back up the PC in order to do the reexecution. >>>> >>>> However, I know that Unix uses such tricks. And I'm wondering if the OP >>>> just was a bit confused on the point, in which case there was a good >>>> reason that the DEC engineers did not use the "trick" the OP suggested, >>>> as DEC had no need of this construct in the first place. >>> >>> Very likely. I can understand the re-execution for some of the more complex >>> VAX instructions but the CHMx just produces the exception it was designed for >>> and then it's up to the exception handler (aka, the change mode to x service >>> dispatcher). >> >> Right. > > If there's an interrupt (context switch or AST or whatever), I don't see why > the CHMx would have to be re-executed. This is getting deep into how Unix works. Would it suffice for me to just say that trust me, in Unix, the CHMx call needs to be re-executed. It's a part of how it's designed. Johnny
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-07-01 15:18 -0700 |
| Message-ID | <c24a9ad7-4198-46cd-bc4f-5268690e186e@googlegroups.com> |
| In reply to | #59225 |
On Saturday, July 2, 2016 at 12:46:53 AM UTC+12, VAXman- wrote: > In article <nl5mlr$1ou$1@Iltempo.Update.UU.SE>, Johnny Billquist writes: >>So could you confirm that VMS backs up the PC and re-execute the system >>call sometimes? > > I don't believe that's so. The only way back home, so to speak, is via the > REI instruction. That pops the saved PC/PSL from the stack, restoring the > original mode and execution resumes at the next instruction after the CHMx. Time to re-read the Internals and Data Structures Manual? On VAX, the procedure for executing a restartable system service (e.g. $HIBER, $WAITFR, $SYNCH) goes broadly something like this (omitting irrelevant detail which I can’t remember anyway): * Set the relevant PCB state and put the PCB on the relevant wait queue. * Subtract 4 from the saved PC on the stack. * Save the current process context and go find another process to make current. So when the process gets made current again, the CHMK instruction, and hence the system call, is re-executed. If the condition it was waiting for has not occurred yet, it goes right back onto the wait queue again. Otherwise, it resumes execution. It’s that “subtract 4” I found inelegant...
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-07-02 20:02 +0000 |
| Message-ID | <00B0B803.8FB98ACE@SendSpamHere.ORG> |
| In reply to | #59225 |
In article <c24a9ad7-4198-46cd-bc4f-5268690e186e@googlegroups.com>, lawrencedo99@gmail.com writes: >On Saturday, July 2, 2016 at 12:46:53 AM UTC+12, VAXman- wrote: >> In article <nl5mlr$1ou$1@Iltempo.Update.UU.SE>, Johnny Billquist writes: >>>So could you confirm that VMS backs up the PC and re-execute the system= >=20 >>>call sometimes? >>=20 >> I don't believe that's so. The only way back home, so to speak, is via t= >he >> REI instruction. That pops the saved PC/PSL from the stack, restoring t= >he=20 >> original mode and execution resumes at the next instruction after the CHM= >x. > >Time to re-read the Internals and Data Structures Manual? > >On VAX, the procedure for executing a restartable system service (e.g. $HIB= >ER, $WAITFR, $SYNCH) goes broadly something like this (omitting irrelevant = >detail which I can=E2=80=99t remember anyway): > >* Set the relevant PCB state and put the PCB on the relevant wait queue. >* Subtract 4 from the saved PC on the stack. >* Save the current process context and go find another process to make curr= >ent. > >So when the process gets made current again, the CHMK instruction, and henc= >e the system call, is re-executed. If the condition it was waiting for has = >not occurred yet, it goes right back onto the wait queue again. Otherwise, = >it resumes execution. > >It=E2=80=99s that =E2=80=9Csubtract 4=E2=80=9D I found inelegant... One byte instruction, one byte operand specifier, two bytes for the CHMx operand. That looks like 4 bytes to me. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-07-03 14:10 -0700 |
| Message-ID | <c9780fa2-9b98-495a-afbd-f3f07ef10a52@googlegroups.com> |
| In reply to | #59291 |
On Sunday, July 3, 2016 at 8:02:15 AM UTC+12, VAXman- wrote: > > In article <c24a9ad7-4198-46cd-bc4f-5268690e186e@googlegroups.com>, > Lawrence D’Oliveiro writes: >> >>It’s that “subtract 4” I found inelegant... > > One byte instruction, one byte operand specifier, two bytes for the CHMx > operand. > That looks like 4 bytes to me. You do realize VAX instructions don’t have to be a fixed length, don’t you?
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-07-04 14:56 -0700 |
| Message-ID | <37a99fd7-66e4-4b79-90ed-631cc23df30d@googlegroups.com> |
| In reply to | #59291 |
On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote: > > In article <c9780fa2-9b98-495a-afbd-f3f07ef10a52@googlegroups.com>, > Lawrence D’Oliveiro writes: >> >>You do realize VAX instructions don’t have to be a fixed length, don’t you? > > No, I didn't know that! And you call yourself a VAXman...
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.os.vms
csiph-web