Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #59267

Re: Pointless Nostalgia: System Service Dispatching

Show all headers | View raw

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.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web