Pointless Nostalgia: System Service Dispatching

[lawren...@gmail.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...

[Johnny Billquist]

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

[lawren...@gmail.com]

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.

[Johnny Billquist]

There isn't? Did I place the $ on the wrong side or something now? Or
what are you suggesting?

Johnny

[Michael Moroney]

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

[VAXman-]

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.

[Johnny Billquist]

On 2016-06-30 18:55, VAX...@SendSpamHere.ORG wrote:
> In article <nl3491$rou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>> On 2016-06-30 01:05, lawren...@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

[VAXman-]

In article <nl3r1k$f2f$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>On 2016-06-30 18:55, VAX...@SendSpamHere.ORG wrote:
>> In article <nl3491$rou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>> On 2016-06-30 01:05, lawren...@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.

[lawren...@gmail.com]

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.

[Johnny Billquist]

On 2016-06-30 21:52, VAX...@SendSpamHere.ORG wrote:
> In article <nl3r1k$f2f$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>> On 2016-06-30 18:55, VAX...@SendSpamHere.ORG wrote:
>>> In article <nl3491$rou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>>> On 2016-06-30 01:05, lawren...@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

[VAXman-]

In article <nl5mlr$1ou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:

>On 2016-06-30 21:52, VAX...@SendSpamHere.ORG wrote:
>> In article <nl3r1k$f2f$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>> On 2016-06-30 18:55, VAX...@SendSpamHere.ORG wrote:
>>>> In article <nl3491$rou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>>>> On 2016-06-30 01:05, lawren...@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.

[Johnny Billquist]

On 2016-07-01 14:46, VAX...@SendSpamHere.ORG wrote:
> In article <nl5mlr$1ou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>> On 2016-06-30 21:52, VAX...@SendSpamHere.ORG wrote:
>>> In article <nl3r1k$f2f$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>>> On 2016-06-30 18:55, VAX...@SendSpamHere.ORG wrote:
>>>>> In article <nl3491$rou$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>>>>> On 2016-06-30 01:05, lawren...@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.

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

[VAXman-]

In article <nl62u3$ork$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>On 2016-07-01 14:46, VAX...@SendSpamHere.ORG wrote:

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

[Johnny Billquist]

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

[VAXman-]

In article <nl6a7q$b6d$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:

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

[lawren...@gmail.com]

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

[VAXman-]

In article <c24a9ad7-4198-46cd...@googlegroups.com>, lawren...@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.

[lawren...@gmail.com]

On Sunday, July 3, 2016 at 8:02:15 AM UTC+12, VAXman- wrote:
>
> In article <c24a9ad7-4198-46cd...@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?

[Johnny Billquist]

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

[VAXman-]

In article <c9780fa2-9b98-495a...@googlegroups.com>, lawren...@gmail.com writes:
>On Sunday, July 3, 2016 at 8:02:15 AM UTC+12, VAXman- wrote:
>>
>> In article <c24a9ad7-4198-46cd...@googlegroups.com>,

>> Lawrence D=E2=80=99Oliveiro writes:
>>>
>>>It=E2=80=99s that =E2=80=9Csubtract 4=E2=80=9D I found inelegant...

>>=20

>> 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=E2=80=99t have to be a fixed length, do=
>n=E2=80=99t you?

No, I didn't know that! Now I'll have to watch out for the system service
change mode instructions changing size. Maybe, you can clue me in to what
makes them change size. Dieting perhaps? Over-indulgence? Sitting about
watching reruns of Family Feud?

[lawren...@gmail.com]

On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>
> In article <c9780fa2-9b98-495a...@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...

[VAXman-]

In article <37a99fd7-66e4-4b79...@googlegroups.com>, lawren...@gmail.com writes:
>On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>
>> In article <c9780fa2-9b98-495a...@googlegroups.com>,
>> Lawrence D=E2=80=99Oliveiro writes:
>>>
>>>You do realize VAX instructions don=E2=80=99t have to be a fixed length, =
>don=E2=80=99t you?
>>=20

>> No, I didn't know that!
>

>And you call yourself a VAXman...

The single biggest problem in communication is the illusion that it has taken place.
-- George Bernard Shaw

Are you actually an idiot or do you just play one on the internet?

[Paul Sture]

On 2016-07-04, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> In article <c9780fa2-9b98-495a...@googlegroups.com>, lawren...@gmail.com writes:
>>On Sunday, July 3, 2016 at 8:02:15 AM UTC+12, VAXman- wrote:
>>>
>>> In article <c24a9ad7-4198-46cd...@googlegroups.com>,
>>> Lawrence D=E2=80=99Oliveiro writes:
>>>>
>>>>It=E2=80=99s that =E2=80=9Csubtract 4=E2=80=9D I found inelegant...
>>>=20
>>> 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=E2=80=99t have to be a fixed length, do=
>>n=E2=80=99t you?
>
> No, I didn't know that! Now I'll have to watch out for the system service
> change mode instructions changing size. Maybe, you can clue me in to what
> makes them change size. Dieting perhaps? Over-indulgence? Sitting about
> watching reruns of Family Feud?

Can you recommend some low calorie popcorn?

--
A sure cure for sea-sickness is to sit under a tree.
-- Spike Milligan

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <37a99fd7-66e4-4b79...@googlegroups.com>, lawren...@gmail.com writes:
>> On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>> In article <c9780fa2-9b98-495a...@googlegroups.com>,
>>> Lawrence D=E2=80=99Oliveiro writes:
>>>> You do realize VAX instructions don=E2=80=99t have to be a fixed length, =
>> don=E2=80=99t you?
>>> =20
>>> No, I didn't know that!
>> And you call yourself a VAXman...
>
> The single biggest problem in communication is the illusion that it has taken place.
> -- George Bernard Shaw
>
> Are you actually an idiot or do you just play one on the internet?
>

Don't feed the trolls ....

[VAXman-]

In article <vqes4d-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>On 2016-07-04, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:

>> In article <c9780fa2-9b98-495a...@googlegroups.com>, lawren...@gmail.com writes:
>>>On Sunday, July 3, 2016 at 8:02:15 AM UTC+12, VAXman- wrote:
>>>>
>>>> In article <c24a9ad7-4198-46cd...@googlegroups.com>,
>>>> Lawrence D=E2=80=99Oliveiro writes:
>>>>>
>>>>>It=E2=80=99s that =E2=80=9Csubtract 4=E2=80=9D I found inelegant...
>>>>=20
>>>> 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=E2=80=99t have to be a fixed length, do=
>>>n=E2=80=99t you?
>>
>> No, I didn't know that! Now I'll have to watch out for the system service
>> change mode instructions changing size. Maybe, you can clue me in to what
>> makes them change size. Dieting perhaps? Over-indulgence? Sitting about
>> watching reruns of Family Feud?
>

>Can you recommend some low calorie popcorn?

Popcorn? Not me! Prof. Jerry Hathaway and myself both detest popcorn. And,
before you should ask, I detest low calorie beer as well, so I can't make any
recommendation. However, should Lawrence give up VAX consumption altogether,
he could try Alpha as its instructions are all 4 bytes but then, Lawrence may
complain about that too but I didn't design its architecture either!

In addition, I can't retro-actively edit my comp.os.vms posts to encapsulate
certain parts with <sarcasm> and </sarcasm> tags, so Sir Lawrence of Oliveiro
may never know that it was a joke at his expense.

[lawren...@gmail.com]

On Tuesday, July 5, 2016 at 12:46:20 PM UTC+12, VAXman- wrote:
>
> In article <37a99fd7-66e4-4b79...@googlegroups.com>,
> Lawrence D’Oliveiro writes:;

>>
>> On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>>
>>> In article <c9780fa2-9b98-495a...@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...
>

> Are you actually an idiot or do you just play one on the internet?

Says the one furiously trying to spew out an ad-hominem smokescreen to cover up the fact that he doesn’t know the first thing about the VAX architecture...

[VAXman-]

In article <4aac38f9-e5e2-47c4...@googlegroups.com>, lawren...@gmail.com writes:
>On Tuesday, July 5, 2016 at 12:46:20 PM UTC+12, VAXman- wrote:
>>
>> In article <37a99fd7-66e4-4b79...@googlegroups.com>,
>> Lawrence D=E2=80=99Oliveiro writes:;

>>>
>>> On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>>>
>>>> In article <c9780fa2-9b98-495a...@googlegroups.com>,
>>>> Lawrence D=E2=80=99Oliveiro writes:
>>>>>

>>>>> You do realize VAX instructions don=E2=80=99t have to be a fixed lengt=
>h,
>>>>> don=E2=80=99t you?

>>>>
>>>> No, I didn't know that!
>>>
>>>And you call yourself a VAXman...

>>=20
>> Are you actually an idiot or do you just play one on the internet?=20
>
>Says the one furiously trying to spew out an ad-hominem smokescreen to cove=
>r up the fact that he doesn=E2=80=99t know the first thing about the VAX ar=
>chitecture...

Ah, you're a comedian too or do you just portray one on the internet as well?

You still haven't answered why you have your issue over 4 bytes. Instead of
casting aspersions, why don't you illuminate all using your fractional lumen
brilliance.

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <4aac38f9-e5e2-47c4...@googlegroups.com>, lawren...@gmail.com writes:
>> On Tuesday, July 5, 2016 at 12:46:20 PM UTC+12, VAXman- wrote:
>>> In article <37a99fd7-66e4-4b79...@googlegroups.com>,
>>> Lawrence D=E2=80=99Oliveiro writes:;
>>>> On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>>>> In article <c9780fa2-9b98-495a...@googlegroups.com>,
>>>>> Lawrence D=E2=80=99Oliveiro writes:
>>>>>> You do realize VAX instructions don=E2=80=99t have to be a fixed lengt=
>> h,
>>>>>> don=E2=80=99t you?
>>>>> No, I didn't know that!
>>>> And you call yourself a VAXman...
>>> =20
>>> Are you actually an idiot or do you just play one on the internet?=20
>> Says the one furiously trying to spew out an ad-hominem smokescreen to cove=
>> r up the fact that he doesn=E2=80=99t know the first thing about the VAX ar=
>> chitecture...
>
> Ah, you're a comedian too or do you just portray one on the internet as well?
>
> You still haven't answered why you have your issue over 4 bytes. Instead of
> casting aspersions, why don't you illuminate all using your fractional lumen
> brilliance.
>

You fed him ....

[Paul Sture]

And you have just shot yourself well and truly in the foot.

[VAXman-]

In article <nlhs38$uek$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:

>VAXman- @SendSpamHere.ORG wrote:
>> In article <4aac38f9-e5e2-47c4...@googlegroups.com>, lawren...@gmail.com writes:
>>> On Tuesday, July 5, 2016 at 12:46:20 PM UTC+12, VAXman- wrote:
>>>> In article <37a99fd7-66e4-4b79...@googlegroups.com>,
>>>> Lawrence D=E2=80=99Oliveiro writes:;
>>>>> On Tuesday, July 5, 2016 at 1:25:53 AM UTC+12, VAXman- wrote:
>>>>>> In article <c9780fa2-9b98-495a...@googlegroups.com>,
>>>>>> Lawrence D=E2=80=99Oliveiro writes:
>>>>>>> You do realize VAX instructions don=E2=80=99t have to be a fixed lengt=
>>> h,
>>>>>>> don=E2=80=99t you?
>>>>>> No, I didn't know that!
>>>>> And you call yourself a VAXman...
>>>> =20
>>>> Are you actually an idiot or do you just play one on the internet?=20
>>> Says the one furiously trying to spew out an ad-hominem smokescreen to cove=
>>> r up the fact that he doesn=E2=80=99t know the first thing about the VAX ar=
>>> chitecture...
>>
>> Ah, you're a comedian too or do you just portray one on the internet as well?
>>
>> You still haven't answered why you have your issue over 4 bytes. Instead of
>> casting aspersions, why don't you illuminate all using your fractional lumen
>> brilliance.
>>
>

>You fed him ....

Oops!

[Simon Clubley]

On 2016-07-05, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> In article <vqes4d-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>>
>>Can you recommend some low calorie popcorn?
>
> Popcorn? Not me! Prof. Jerry Hathaway and myself both detest popcorn. And,
> before you should ask, I detest low calorie beer as well, so I can't make any
> recommendation. However, should Lawrence give up VAX consumption altogether,
> he could try Alpha as its instructions are all 4 bytes but then, Lawrence may
> complain about that too but I didn't design its architecture either!
>

Professor Hathaway's real problem (apart from his personality) was that
he didn't have a European style brick house and hence lost his house
instead of just his windows.

Simon.

PS: :-) (just in case)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[VAXman-]

In article <nlj757$m5$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>On 2016-07-05, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <vqes4d-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>>>
>>>Can you recommend some low calorie popcorn?
>>
>> Popcorn? Not me! Prof. Jerry Hathaway and myself both detest popcorn. And,
>> before you should ask, I detest low calorie beer as well, so I can't make any
>> recommendation. However, should Lawrence give up VAX consumption altogether,
>> he could try Alpha as its instructions are all 4 bytes but then, Lawrence may
>> complain about that too but I didn't design its architecture either!
>>
>

>Professor Hathaway's real problem (apart from his personality) was that
>he didn't have a European style brick house and hence lost his house
>instead of just his windows.

Professor Hathaway's real problem was that he used the intellect of several
good and brilliant others to produce for him as his own effort and for his
own personal selfish gains, and then he fucked over the others after they'd
produced for him. I'm all too aware of schmucks like that; I just haven't
put a corner cube reflector and giant jiffy-pop popcorn basket in his home
to help him acquire self-realization. ;)

[Paul Sture]

On 2016-07-06, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2016-07-05, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <vqes4d-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>>>
>>>Can you recommend some low calorie popcorn?
>>
>> Popcorn? Not me! Prof. Jerry Hathaway and myself both detest popcorn. And,
>> before you should ask, I detest low calorie beer as well, so I can't make any
>> recommendation. However, should Lawrence give up VAX consumption altogether,
>> he could try Alpha as its instructions are all 4 bytes but then, Lawrence may
>> complain about that too but I didn't design its architecture either!
>>
>
> Professor Hathaway's real problem (apart from his personality) was that
> he didn't have a European style brick house and hence lost his house
> instead of just his windows.
>

> PS: :-) (just in case)
>

I missed the film unfortunately. Is it worth seeking out?

[Simon Clubley]

I liked it enough that I picked it up for my DVD collection some
years ago although I probably picked it up when it was heavily
discounted at somewhere like Amazon.

Just remember it was made 30 years ago so it's your typical mid 1980s
comedy even though it's set in a geek/academic environment.

Simon.

[Paul Sture]

On 2016-07-07, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2016-07-06, Paul Sture <nos...@sture.ch> wrote:
>> On 2016-07-06, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>> Professor Hathaway's real problem (apart from his personality) was that
>>> he didn't have a European style brick house and hence lost his house
>>> instead of just his windows.
>>>
>>> PS: :-) (just in case)
>>>
>>
>> I missed the film unfortunately. Is it worth seeking out?
>>
>
> I liked it enough that I picked it up for my DVD collection some
> years ago although I probably picked it up when it was heavily
> discounted at somewhere like Amazon.
>
> Just remember it was made 30 years ago so it's your typical mid 1980s
> comedy even though it's set in a geek/academic environment.
>

Thanks. A decently discounted price is fine but Youtube was offering it
for rather too much. :(