perhaps rsx11s was planned for the pdt11 series.
On Jan 6, 2013 12:14 PM, "Lee Gleason" <lee.gleason at comcast.net> wrote:
.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'm even more curious what a PDT-11 optimization is doing in an RSX driver...was there at one time an RSX product product planned for the PDT family?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
.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'm even more curious what a PDT-11 optimization is doing in an RSX driver...was there at one time an RSX product product planned for the PDT family?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
From: Johnny Billquist <bqt at softjar.se>
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.
That's because of how the Unibus (and Q-bus) encodes cycle types.
Instead of having separate "enable" lines for low-byte and high-byte
reads and writes, it encodes the four cycle types on two lines (C0 and
C1), so the choices are DATI, DATIP, DATO, and DATOB. (DATIP is like
DATI but the master promises to follow with a DATOx, so core memories
should wait until then to rewrite, plus the whole thing might possibly
be interlocked on a PDP-11/45 etc.)
So to support byte writes (reads are always words) you have to decode
those bits (plus A0), so it adds several extra chips, which they often
don't bother with. So instead they just decode C1 alone, so DATIP is
treated like DATI (which is fine for a peripheral), and DATOB is treated
like DATO (so you're writing both bytes even though the CPU thinks it's
only writing one half). So you'll write garbage to the other byte.
Q-bus is about the same but I think they say DATIO instead of DATIP.
John Wilson
D Bit
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.
