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


Groups > comp.os.vms > #59253

Re: Pointless Nostalgia: System Service Dispatching

Newsgroups comp.os.vms
Subject Re: Pointless Nostalgia: System Service Dispatching
References (3 earlier) <nl3491$rou$1@Iltempo.Update.UU.SE> <00B0B657.24DF3378@SendSpamHere.ORG> <nl3r1k$f2f$1@Iltempo.Update.UU.SE> <00B0B66F.E33DC123@SendSpamHere.ORG> <00B0B6FD.93802360@SendSpamHere.ORG>
From VAXman- @SendSpamHere.ORG
Message-ID <00B0B720.EF353C98@SendSpamHere.ORG> (permalink)
Organization c.2016 Brian Schenkenberger. Prior employers of copyright holder and their agents must first obtain written permission to copy this posting.
Date 2016-07-01 16:59 +0000

Show all headers | View raw


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.

Back to comp.os.vms | Previous | NextPrevious 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