On 2013-01-06 03:33, John Wilson wrote:
From: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM>
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
I don't know the exact answer, but the I/O page in a PDT-11 is emulated by
an 8085A and it's always super slow. I don't know why DATOB would be any
worse than DATO but if DEC thought it was, I'm sure it's true (it shouldn't
have to be a read-modify-write but some PDP-11 models do gratuitous extra
cycles so it may well be). So this isn't actually a Q vs. U difference, it's
a PDT vs. real bus difference, but the LSI-11 conditionals will catch PDTs.
I know that it isn't as simple sometimes/somehow. Some devices have warnings about not doing byte operations on them, while others are fine, as far as I can remember from reading various manuals. But my memory is (as usual) fuzzy enough that I might be misremembering in one way or another.
But that would suggest that doing a DATOB might not work as expected on peripherials. Most of my brain cells actually are wasted on the 11/70, where things work slightly different, since the memory bus is actually 32 bits wide. I'm probably constantly confusing the bus cycles with the memory cycles of that machine all the time.
Thinking more, you are probably right that a DATOB shouldn't be a RMW cycle, but something in the PDT obviously don't like a byte write anyway.
Gah. I should probably re-read the bus specs now that you got me starting to think about this again... It's been too long.
Anyway, thanks Johnny! Good to know that DU and DUV are 2 for the price of 1.
(And it hadn't even clicked that the thing in a PDT is emulating a DUV, so I
guess it's 3 for the price of 1!)
You're welcome.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-01-06 03:40, Johnny Billquist wrote:
On 2013-01-06 03:17, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Well, this code runs on any Qbus, so all Qbus machines "benifit" from
the code, not just the PDT-11. It's proably that on the Unibus, the
speed penalty for a read-modify-write is less than reading a byte and
pushing it on the stack, and then popping the stack and writing the word
to the bus. Also, the DU-11 might respond much faster than the DUV-11.
The buses are asynchronous, so the time for the execution is totally
dependent on the speed of the device to respond to the bus cycles.
OK. That wasn't clear from the choice of the symbol in the conditional.
I know that the selection whether to call the driver DU or DUV is based
on the L$$SI1 symbol. Sorry I probably didn't point that out enough.
That tells me that all Qbus machines get that variant. (The choice of
symbol name is probably just simply because the LSI-11 was the first
Qbus machine.)
I assume the PDT-11 mentioned is the one with a Qbus, so it's the same
controller as all other Qbus machines. But that part is really a guess.
It might be that I'm wrong on that, and that the PDT-11 have something
else, which looks and works just the same way as any other Qbus machine,
but DEC didn't have any convenient way of setting up a specific
variation for the PDT-11, so they took the small hit on Qbus machines in
order to save the PDT-11, but could avoid even the small hit on Unibus
machines, since the PDT-11 isn't even in the picture there.
And based on John's response, it seems as if it actually is this latter guess that is right.
The cost on any other Qbus machine is pretty minimal, even if it is slower to go through the stack.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-01-06 03:17, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Well, this code runs on any Qbus, so all Qbus machines "benifit" from
the code, not just the PDT-11. It's proably that on the Unibus, the
speed penalty for a read-modify-write is less than reading a byte and
pushing it on the stack, and then popping the stack and writing the word
to the bus. Also, the DU-11 might respond much faster than the DUV-11.
The buses are asynchronous, so the time for the execution is totally
dependent on the speed of the device to respond to the bus cycles.
OK. That wasn't clear from the choice of the symbol in the conditional.
I know that the selection whether to call the driver DU or DUV is based on the L$$SI1 symbol. Sorry I probably didn't point that out enough.
That tells me that all Qbus machines get that variant. (The choice of symbol name is probably just simply because the LSI-11 was the first Qbus machine.)
I assume the PDT-11 mentioned is the one with a Qbus, so it's the same controller as all other Qbus machines. But that part is really a guess.
It might be that I'm wrong on that, and that the PDT-11 have something else, which looks and works just the same way as any other Qbus machine, but DEC didn't have any convenient way of setting up a specific variation for the PDT-11, so they took the small hit on Qbus machines in order to save the PDT-11, but could avoid even the small hit on Unibus machines, since the PDT-11 isn't even in the picture there.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM>
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
I don't know the exact answer, but the I/O page in a PDT-11 is emulated by
an 8085A and it's always super slow. I don't know why DATOB would be any
worse than DATO but if DEC thought it was, I'm sure it's true (it shouldn't
have to be a read-modify-write but some PDP-11 models do gratuitous extra
cycles so it may well be). So this isn't actually a Q vs. U difference, it's
a PDT vs. real bus difference, but the LSI-11 conditionals will catch PDTs.
Anyway, thanks Johnny! Good to know that DU and DUV are 2 for the price of 1.
(And it hadn't even clicked that the thing in a PDT is emulating a DUV, so I
guess it's 3 for the price of 1!)
John Wilson
D Bit
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Well, this code runs on any Qbus, so all Qbus machines "benifit" from
the code, not just the PDT-11. It's proably that on the Unibus, the
speed penalty for a read-modify-write is less than reading a byte and
pushing it on the stack, and then popping the stack and writing the word
to the bus. Also, the DU-11 might respond much faster than the DUV-11.
The buses are asynchronous, so the time for the execution is totally
dependent on the speed of the device to respond to the bus cycles.
OK. That wasn't clear from the choice of the symbol in the conditional.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-01-06 03:07, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
But it seems very likely that it's the byte write that is the problem.
That becomes a read-modify-write cycle on the bus, since everything on
the bus is accessed as words. And accessing the DUV-11 on a PDT-11 is
extremely slow. Just guessing, mind you...
But wouldn't all benefit from that? Why conditionalize it?
Well, this code runs on any Qbus, so all Qbus machines "benifit" from the code, not just the PDT-11. It's proably that on the Unibus, the speed penalty for a read-modify-write is less than reading a byte and pushing it on the stack, and then popping the stack and writing the word to the bus.
Also, the DU-11 might respond much faster than the DUV-11. The buses are asynchronous, so the time for the execution is totally dependent on the speed of the device to respond to the bus cycles.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
But it seems very likely that it's the byte write that is the problem.
That becomes a read-modify-write cycle on the bus, since everything on
the bus is accessed as words. And accessing the DUV-11 on a PDT-11 is
extremely slow. Just guessing, mind you...
But wouldn't all benefit from that? Why conditionalize it?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-01-06 02:46, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
One of them is a simple optimization for the PDT-11. It's not strictly
neccesary, but apparently DEC thought the time gain was enough to make
it worth exploiting. Code looks like this:
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
I'll have to make a guess, since I don't have the hardware, nor have I checked if any documentation at that level can be found anywhere.
But it seems very likely that it's the byte write that is the problem. That becomes a read-modify-write cycle on the bus, since everything on the bus is accessed as words. And accessing the DUV-11 on a PDT-11 is extremely slow. Just guessing, mind you...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
One of them is a simple optimization for the PDT-11. It's not strictly
neccesary, but apparently DEC thought the time gain was enough to make
it worth exploiting. Code looks like this:
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-01-03 22:19, Johnny Billquist wrote:
On 2013-01-03 18:37, John Wilson wrote:
Trivia question: what are the major differences between programming
the DU11 and the DUV11? At least from the handbook descriptions, it
sounds like the DUV11's isochronous (= async?) mode works and the DU11's
doesn't, but that's the only difference I can see and I don't see how
it matters for DDCMP use. And yet, DECnet/RSX has different names for
them, as if it's using separate drivers for each.
If DECnet/RSX uses different names, then it is also definitely using
different drivers.
However, who knows if the actual contents of the drivers differ, or if
they just liked having different names for them. :-)
(I can check next week. Please remind me...)
Ok. Just checked.
There are about two differences between the DU and DUV driver in DECnet under RSX.
One of them is a simple optimization for the PDT-11. It's not strictly neccesary, but apparently DEC thought the time gain was enough to make it worth exploiting. Code looks like this:
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
The other difference is probably more important. It appears there might be a hardware glitch on the DUV-11. Code looks like this:
.IF DF L$$SI1
INHIB$ ;;; LOCK OUT INTERRUPTS
.ENDC ; DF L$$SI1
BIC #TXINT,(R3) ;;; CLEAR TRANSMIT INTERRUPT ENABLE
.IF DF L$$SI1
ENABL$ ; ENABLE INTERRUPTS AGAIN
.ENDC ; DF L$$SI1
the only way I can understand that code is that there might be a spurious interrupt when manipulating the interrupt enable bit on the controller.
All else in the code is the same between the two controllers, and (as you might have guessed) the source code is shared, with just a conditional selecting which version to assemble.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
