info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
6120 differences in GTF/RTF?
80 views
Skip to first unread message
Bob Armstrong
Aug 20, 2022, 10:17:30 AM8/20/22
to
This is a bit long but, as Norb said, it's almost interesting...
The PDP8 has two instructions, GTF and RTF, that get and restore the flags, including the LINK, current EMA fields, GT flag, user mode FF, etc. The usual application for these opcodes is in an interrupt service routine to save and restore the state of the machine. One of the flag bits, though, is the interrupt enable flip flop, IEFF. Interrupts are disabled when an interrupt is granted, so if a program uses GTF to get the flags in an ISR the state of the IEFF bit will always be zero. If a program simply does an RTF when the ISR exits, then we'll always leave with interrupts disabled. Probably not what you wanted...
Now a program could just OR a 1 into the flags for the IEFF before doing the RTF, but PDP8s aren't good at OR operations and I guess the DEC designers wanted an easier way. On all the OMNIBUS PDP8s (8/A/E/F/M) and the IM6100 VT78, there's a hack in the RTF instruction. On these machines GTF returns the accurate state of the IEFF, but RTF always enables interrupts regardless of IEFF bit in the saved flags. I don't know what the pre-OMNIBUS machines do, but I'd guess that they work the same way. Okay...
For the HD6120 they flipped this around. On the 6120 RTF actually enables or disables interrupts as specified by the IEFF bit in the flags being restored. BUT, the GTF instruction always returns a 1 in the IEFF position regardless of the current state of the IEFF. So the net result, at least for a simple minded ISR, is the same but the hack has been shifted to the other end of the process. FWIW, the 6120 actually has another instruction, GCF, which is identical to GTF except that GCF returns the real state of the IEFF.
This is admittedly a trival difference, but some of the 8/E/A diagnostics check this behavior and will fail on the 6120 for this reason. The 6120 adds several extensions to the traditional PDP-8 instruction set, but this is the only case I know of where a long standing instruction is actually incompatible. This isn't an accident, either - the DEC internal purchasing specification for the 6120 is on BitSavers and this behavior is specified explicitly, and it's documented in the Harris data sheets.
And yes, I know about the DECmate incompatibilities in the 603x/604x console IOTs, but that was an issue with the 6121 I/O controller chip. It didn't have anything to do with the 6120 CPU itself, and it's certainly possible to design a "standard" terminal interface around the 6120.
So my question is, why?? Does anybody know any history behind this? Why did DEC decide to specify this particular change?
The PDP8 has two instructions, GTF and RTF, that get and restore the flags, including the LINK, current EMA fields, GT flag, user mode FF, etc. The usual application for these opcodes is in an interrupt service routine to save and restore the state of the machine. One of the flag bits, though, is the interrupt enable flip flop, IEFF. Interrupts are disabled when an interrupt is granted, so if a program uses GTF to get the flags in an ISR the state of the IEFF bit will always be zero. If a program simply does an RTF when the ISR exits, then we'll always leave with interrupts disabled. Probably not what you wanted...
Now a program could just OR a 1 into the flags for the IEFF before doing the RTF, but PDP8s aren't good at OR operations and I guess the DEC designers wanted an easier way. On all the OMNIBUS PDP8s (8/A/E/F/M) and the IM6100 VT78, there's a hack in the RTF instruction. On these machines GTF returns the accurate state of the IEFF, but RTF always enables interrupts regardless of IEFF bit in the saved flags. I don't know what the pre-OMNIBUS machines do, but I'd guess that they work the same way. Okay...
For the HD6120 they flipped this around. On the 6120 RTF actually enables or disables interrupts as specified by the IEFF bit in the flags being restored. BUT, the GTF instruction always returns a 1 in the IEFF position regardless of the current state of the IEFF. So the net result, at least for a simple minded ISR, is the same but the hack has been shifted to the other end of the process. FWIW, the 6120 actually has another instruction, GCF, which is identical to GTF except that GCF returns the real state of the IEFF.
This is admittedly a trival difference, but some of the 8/E/A diagnostics check this behavior and will fail on the 6120 for this reason. The 6120 adds several extensions to the traditional PDP-8 instruction set, but this is the only case I know of where a long standing instruction is actually incompatible. This isn't an accident, either - the DEC internal purchasing specification for the 6120 is on BitSavers and this behavior is specified explicitly, and it's documented in the Harris data sheets.
And yes, I know about the DECmate incompatibilities in the 603x/604x console IOTs, but that was an issue with the 6121 I/O controller chip. It didn't have anything to do with the 6120 CPU itself, and it's certainly possible to design a "standard" terminal interface around the 6120.
So my question is, why?? Does anybody know any history behind this? Why did DEC decide to specify this particular change?
Johnny Billquist
Aug 21, 2022, 10:57:16 AM8/21/22
to
No an answer to your actual question, but a few additional comments...
On 2022-08-20 16:17, Bob Armstrong wrote:
> This is a bit long but, as Norb said, it's almost interesting...
Infocom reference. Nice. :-)
> The PDP8 has two instructions, GTF and RTF, that get and restore the flags, including the LINK, current EMA fields, GT flag, user mode FF, etc. The usual application for these opcodes is in an interrupt service routine to save and restore the state of the machine. One of the flag bits, though, is the interrupt enable flip flop, IEFF. Interrupts are disabled when an interrupt is granted, so if a program uses GTF to get the flags in an ISR the state of the IEFF bit will always be zero. If a program simply does an RTF when the ISR exits, then we'll always leave with interrupts disabled. Probably not what you wanted...
>
> Now a program could just OR a 1 into the flags for the IEFF before doing the RTF, but PDP8s aren't good at OR operations and I guess the DEC designers wanted an easier way. On all the OMNIBUS PDP8s (8/A/E/F/M) and the IM6100 VT78, there's a hack in the RTF instruction. On these machines GTF returns the accurate state of the IEFF, but RTF always enables interrupts regardless of IEFF bit in the saved flags. I don't know what the pre-OMNIBUS machines do, but I'd guess that they work the same way. Okay...
I was always wondering why GTF even returned the interrupt information
bits, since they are not used by RTF anyway. And I can't see what
interest they would have for any code either.
But as far as I can remember, pre-Omnibus machines don't even have these
instructions/operations.
> For the HD6120 they flipped this around. On the 6120 RTF actually enables or disables interrupts as specified by the IEFF bit in the flags being restored. BUT, the GTF instruction always returns a 1 in the IEFF position regardless of the current state of the IEFF. So the net result, at least for a simple minded ISR, is the same but the hack has been shifted to the other end of the process. FWIW, the 6120 actually has another instruction, GCF, which is identical to GTF except that GCF returns the real state of the IEFF.
>
> This is admittedly a trival difference, but some of the 8/E/A diagnostics check this behavior and will fail on the 6120 for this reason. The 6120 adds several extensions to the traditional PDP-8 instruction set, but this is the only case I know of where a long standing instruction is actually incompatible. This isn't an accident, either - the DEC internal purchasing specification for the 6120 is on BitSavers and this behavior is specified explicitly, and it's documented in the Harris data sheets.
Well, if they documented it after the fact, and based on Harris design,
that don't mean it wasn't an accident, and Harris just misunderstood or
ignored how it was done on DEC CPUs. Not that I know, but I don't think
this is enough to claim it was all very intentional.
> And yes, I know about the DECmate incompatibilities in the 603x/604x console IOTs, but that was an issue with the 6121 I/O controller chip. It didn't have anything to do with the 6120 CPU itself, and it's certainly possible to design a "standard" terminal interface around the 6120.
>
> So my question is, why?? Does anybody know any history behind this? Why did DEC decide to specify this particular change?
The HD6120 was introduced in 1976. The DEC purchase order was written in
1979. I think it was more a case of documenting the actual
implementation, and not a specification of how they wanted it implemented.
Johnny
On 2022-08-20 16:17, Bob Armstrong wrote:
> This is a bit long but, as Norb said, it's almost interesting...
> The PDP8 has two instructions, GTF and RTF, that get and restore the flags, including the LINK, current EMA fields, GT flag, user mode FF, etc. The usual application for these opcodes is in an interrupt service routine to save and restore the state of the machine. One of the flag bits, though, is the interrupt enable flip flop, IEFF. Interrupts are disabled when an interrupt is granted, so if a program uses GTF to get the flags in an ISR the state of the IEFF bit will always be zero. If a program simply does an RTF when the ISR exits, then we'll always leave with interrupts disabled. Probably not what you wanted...
>
> Now a program could just OR a 1 into the flags for the IEFF before doing the RTF, but PDP8s aren't good at OR operations and I guess the DEC designers wanted an easier way. On all the OMNIBUS PDP8s (8/A/E/F/M) and the IM6100 VT78, there's a hack in the RTF instruction. On these machines GTF returns the accurate state of the IEFF, but RTF always enables interrupts regardless of IEFF bit in the saved flags. I don't know what the pre-OMNIBUS machines do, but I'd guess that they work the same way. Okay...
bits, since they are not used by RTF anyway. And I can't see what
interest they would have for any code either.
But as far as I can remember, pre-Omnibus machines don't even have these
instructions/operations.
> For the HD6120 they flipped this around. On the 6120 RTF actually enables or disables interrupts as specified by the IEFF bit in the flags being restored. BUT, the GTF instruction always returns a 1 in the IEFF position regardless of the current state of the IEFF. So the net result, at least for a simple minded ISR, is the same but the hack has been shifted to the other end of the process. FWIW, the 6120 actually has another instruction, GCF, which is identical to GTF except that GCF returns the real state of the IEFF.
>
> This is admittedly a trival difference, but some of the 8/E/A diagnostics check this behavior and will fail on the 6120 for this reason. The 6120 adds several extensions to the traditional PDP-8 instruction set, but this is the only case I know of where a long standing instruction is actually incompatible. This isn't an accident, either - the DEC internal purchasing specification for the 6120 is on BitSavers and this behavior is specified explicitly, and it's documented in the Harris data sheets.
that don't mean it wasn't an accident, and Harris just misunderstood or
ignored how it was done on DEC CPUs. Not that I know, but I don't think
this is enough to claim it was all very intentional.
> And yes, I know about the DECmate incompatibilities in the 603x/604x console IOTs, but that was an issue with the 6121 I/O controller chip. It didn't have anything to do with the 6120 CPU itself, and it's certainly possible to design a "standard" terminal interface around the 6120.
>
> So my question is, why?? Does anybody know any history behind this? Why did DEC decide to specify this particular change?
1979. I think it was more a case of documenting the actual
implementation, and not a specification of how they wanted it implemented.
Johnny
Vincent Slyngstad
Aug 21, 2022, 3:36:12 PM8/21/22
to
On 8/21/2022 7:57 AM, Johnny Billquist wrote:
> I was always wondering why GTF even returned the interrupt information
> bits, since they are not used by RTF anyway. And I can't see what
> interest they would have for any code either.
> But as far as I can remember, pre-Omnibus machines don't even have these
> instructions/operations.
Indeed. I've never understood the point of GTF/RTF, nor ever used them,
> I was always wondering why GTF even returned the interrupt information
> bits, since they are not used by RTF anyway. And I can't see what
> interest they would have for any code either.
> But as far as I can remember, pre-Omnibus machines don't even have these
> instructions/operations.
as they aren't "Family of Eight". I know they aren't used in FOCAL,
which does use interrupts. Similarly, I can't believe FORTRAN's
interrupt routines used them either, since it works on the PDP-12 and
other pre-Omnibus machines. Likewise TSS/8. So, where *were* they
used, and why?
Vince
Vincent Slyngstad
Aug 21, 2022, 8:07:27 PM8/21/22
to
On 8/21/2022 12:36 PM, Vincent Slyngstad wrote:
> Indeed. I've never understood the point of GTF/RTF, nor ever used them,
> as they aren't "Family of Eight". I know they aren't used in FOCAL,
> which does use interrupts. Similarly, I can't believe FORTRAN's
> interrupt routines used them either, since it works on the PDP-12 and
> other pre-Omnibus machines. Likewise TSS/8. So, where *were* they
> used, and why?
In an effort to answer my own question, I went over to my gigantic
> Indeed. I've never understood the point of GTF/RTF, nor ever used them,
> as they aren't "Family of Eight". I know they aren't used in FOCAL,
> which does use interrupts. Similarly, I can't believe FORTRAN's
> interrupt routines used them either, since it works on the PDP-12 and
> other pre-Omnibus machines. Likewise TSS/8. So, where *were* they
> used, and why?
collection of all the PDP-8 source code I have ever seen, and looked.
(The collection was originally assembled as a "beat it to death"
regression test for my cross assembler.)
Here's what I found for GTF usage:
80608b Disassembler mnemonic
anmon Animal Monitoring, ISR requires it
asmblr P?S-8 Assembler mnemonic
bin P?S-8 Loader, alias for 6004 constant
bsave P?S-8 BSAVE command, alias for 6004 constant
cpxdt CONDOR disassembler, mnemonic
cref Symbol table, mnemonic
d0bb Diagnostic, checks for correct operation
data Data acquisition, ISR will emulate if not 8/E
dhkag-a Same as d0bb
dhrka-e Diagnostic console interface register save; RAR equivalent.
dirxa-d Defined but unused
djkka-8p Patch djkka-c to run on 8/I. (Removes use of GTF/RTF.)
dumprx01 ISR requires it to save/restore flags. (Bug: not family of 8.)
edefs ETOS definitions file (used?)
edu20s EDU200 BASIC, ISR uses RIB and RTF.
edu250 EDU250 BASIC, ISR uses with conditional assembly.
f1095 Small real-time system, uses with conditional assembly.
fipa EDU50 Monitor definitions (unused?)
futil Diassembler, mnemonic
inita EDU50 Monitor definitions (unused?)
khodt Condor disassembler, mnemonic
m1 MULTI-8 ISR, if PDPTYP == PDP8E
m3 MULTI-8 Emulation trap, if PDP8E
ntrain Neurophysiology program ISR (PDP-8/E required)
ovrlay BASIC extensions, ISR (PDP-8/E required)
pal8 Assembler, mnemonic
palc CAPS Assembler, mnemonic
para TSS 8.25 parameters (used?)
param TSS 8.24 parameters (used?)
ratmon Rat station monitor, ISR (PDP-8/E required)
rklfmt Diagnostic console interface register save; RAR equivalent.
rts8 RTS-8, ISR, IFNZRO PDP8E
splrts RTS-8, ISR, IFNZRO PDP8E
srt8 SRT-8, ISR, IFNZRO PDP8E
train Animal training program, ISR (PDP-8/E required)
ts8 TSS 8.24 user IOT implementation (if CPU permits)
ts8a TSS 8.24 definitions
ts8c TSS 8.24 user IOT implementation (if CPU permits)
ts8_combined TSS 8.24 user IOT implementation (if CPU permits)
ts8d TSS 8.24 user IOT implementation (if CPU permits)
wpsys WPS, ISR (DECmate required)
F1095 alleges a bug in 4K 8/E -- no Mem. Extension card to implement it?
Everyone curses RTF for not clearing AC.
Long story short, the assemblers and disassemblers know about it, the
diagnostics check it, and most of the major software products either
don't use it, or allow a conditional assembly to use it.
A number of LAB-8 experiment monitors seem to use it. They aren't
presumably concerned with portability, as they also need all the LAB-8
peripherals.
Edu20s and dumprx01 use it, but arguably shouldn't.
Some of the P?S-8 code is using it literally as an alias for the
constant 6004, or perhaps (at a higher level) KSR-0030.
Vince
Tim
Aug 22, 2022, 12:01:55 AM8/22/22
to
On Sunday, August 21, 2022 at 7:07:27 PM UTC-5, Vincent Slyngstad wrote:
>
> Here's what I found for GTF usage:
>
>
> Here's what I found for GTF usage:
>
> F1095 alleges a bug in 4K 8/E -- no Mem. Extension card to implement it?
>
> Everyone curses RTF for not clearing AC.
>
> Long story short, the assemblers and disassemblers know about it, the
> diagnostics check it, and most of the major software products either
> don't use it, or allow a conditional assembly to use it.
>
> A number of LAB-8 experiment monitors seem to use it. They aren't
> presumably concerned with portability, as they also need all the LAB-8
> peripherals.
>
> Edu20s and dumprx01 use it, but arguably shouldn't.
>
> Some of the P?S-8 code is using it literally as an alias for the
> constant 6004, or perhaps (at a higher level) KSR-0030.
>
I looked at the TSS/8 code and it emulates the GTF/RTF only if selected by a specific CPU setting.
>
> Everyone curses RTF for not clearing AC.
>
> Long story short, the assemblers and disassemblers know about it, the
> diagnostics check it, and most of the major software products either
> don't use it, or allow a conditional assembly to use it.
>
> A number of LAB-8 experiment monitors seem to use it. They aren't
> presumably concerned with portability, as they also need all the LAB-8
> peripherals.
>
> Edu20s and dumprx01 use it, but arguably shouldn't.
>
> Some of the P?S-8 code is using it literally as an alias for the
> constant 6004, or perhaps (at a higher level) KSR-0030.
>
Johnny Billquist
Aug 22, 2022, 7:43:40 AM8/22/22
to
PDP-8 models (I did actually start such work, but so far didn't finish
it), I would definitely use GTF/RTF for the interrupt handling. It is
much better than the alternatives. But, as noted, it would limit which
machines it would work on.
Johnny
Bob Armstrong
Aug 22, 2022, 9:22:34 AM8/22/22
to
On Sunday, August 21, 2022 at 7:57:16 AM UTC-7, Johnny Billquist wrote:
> The HD6120 was introduced in 1976.
The 6100 was around in 1976, but not the 6120. All the literature I have from Harris on the 6120 dates to the early 80s. The first application for the 6120 was in the VT278/DECmate-I, which Wikipedia claims was introduced in 1980. I have a Harris microprocessor databook from 1979 and it lists all the 6100 family parts, but neither the 6120 nor 6121. OTOH, I have a 1982 Harris databook that lists both. So 1979 for the spec is not unrealistic.
> The HD6120 was introduced in 1976.
But you could still be right that DEC just specified what had already been done. I don't know much about the politics behind either the 6100 or the 6120 development.
Bob Armstrong
Aug 22, 2022, 9:29:39 AM8/22/22
to
On Monday, August 22, 2022 at 6:22:34 AM UTC-7, Bob Armstrong wrote:
> On Sunday, August 21, 2022 at 7:57:16 AM UTC-7, Johnny Billquist wrote:
> > The HD6120 was introduced in 1976.
> The 6100 was around in 1976, but not the 6120.
Oh, and it's worth noting that the 6100 has the "correct" implementation of GTF/RTF where as the 6120 does not.
> On Sunday, August 21, 2022 at 7:57:16 AM UTC-7, Johnny Billquist wrote:
> > The HD6120 was introduced in 1976.
> The 6100 was around in 1976, but not the 6120.
Vincent Slyngstad
Aug 22, 2022, 9:43:15 AM8/22/22
to
On 8/22/2022 4:43 AM, Johnny Billquist wrote:
> *If* I were to write an interrupt driven system for just a subset of
> PDP-8 models (I did actually start such work, but so far didn't finish
> it), I would definitely use GTF/RTF for the interrupt handling. It is
> much better than the alternatives. But, as noted, it would limit which
> machines it would work on.
Lord help you if you have a type 189 A-D converter :-).
> *If* I were to write an interrupt driven system for just a subset of
> PDP-8 models (I did actually start such work, but so far didn't finish
> it), I would definitely use GTF/RTF for the interrupt handling. It is
> much better than the alternatives. But, as noted, it would limit which
> machines it would work on.
The only abstract justification I can find that forces the use of GTF is
that if your EAE supports mode B, *and* your code wants to inspect GT to
do rounding after a right shift, your ISR will need to save and restore
GT. Which is to say that you'd only need GTF/RTF to support an SGT with
the interrupts on. (Or your code could just inspect MQ11 before the
shift, as must be done in mode A.)
RIB/RMF does save/restore the user mode bit. Saving interrupt inhibit
is silly, since you can't take an interrupt if interrupts are inhibited.
(Can you even set II from user mode?) The previous values of IR and
IE can be inspected (but not restored), I suppose. Link was easy enough
to save/restore the old way.
I think it should work otherwise to replace GTF with
RIB; RAL
and RTF with
CLL RAR; RMF
which is roughly what some of the CPU dependent conditional assemblies
were doing.
Vince
Johnny Billquist
Aug 22, 2022, 4:18:34 PM8/22/22
to
https://gordonbell.azurewebsites.net/Digital/DEC%20PDP_Tree_Poster_1980.jpg
But of course, there is no guarantee that he didn't get it wrong.
Johnny
Johnny Billquist
Aug 22, 2022, 4:38:27 PM8/22/22
to
Harris version of the 6100. I thought it was the 6120 based on the
Wikipedia page: https://en.wikipedia.org/wiki/PDP-8, where the 6120 is
claimed to be 1976, and reference the Gordon page.
But it might be just more misunderstandings. So, sorry if I made an
error in here.
Anyway, I do find it odd if DEC really wanted the GTF/RTF of the 6120 to
behave differently.
Johnny
Bob Armstrong
Aug 23, 2022, 9:04:50 AM8/23/22
to
On Monday, August 22, 2022 at 1:38:27 PM UTC-7, Johnny Billquist wrote:
> And with that said, I wonder if Gordon's picture was just about the
> Harris version of the 6100.
I think it's that. Harris did second source the 6100, about a year after Intersil started selling them. And if you look at Gordon Bell's chart, both the Intersil and Harris boxes lead to the VT78, which was an IM6100 machine.
> And with that said, I wonder if Gordon's picture was just about the
> Harris version of the 6100.
Interestingly, there's no mention of either the 6120 nor any of the DECmates (and there were three models of the latter!) on Bell's chart. Seems like they should rate a branch of their own; they were arguably more successful than the 6100/VT78.
Johnny Billquist
Aug 23, 2022, 12:35:23 PM8/23/22
to
On 2022-08-23 15:04, Bob Armstrong wrote:
> On Monday, August 22, 2022 at 1:38:27 PM UTC-7, Johnny Billquist wrote:
>> And with that said, I wonder if Gordon's picture was just about the
>> Harris version of the 6100.
>
> I think it's that. Harris did second source the 6100, about a year after Intersil started selling them. And if you look at Gordon Bell's chart, both the Intersil and Harris boxes lead to the VT78, which was an IM6100 machine.
Yeah. The more I looked at that. the more it felt like that's what was
> On Monday, August 22, 2022 at 1:38:27 PM UTC-7, Johnny Billquist wrote:
>> And with that said, I wonder if Gordon's picture was just about the
>> Harris version of the 6100.
>
> I think it's that. Harris did second source the 6100, about a year after Intersil started selling them. And if you look at Gordon Bell's chart, both the Intersil and Harris boxes lead to the VT78, which was an IM6100 machine.
intended. I was fooled by Wikipedia (not the first time).
> Interestingly, there's no mention of either the 6120 nor any of the DECmates (and there were three models of the latter!) on Bell's chart. Seems like they should rate a branch of their own; they were arguably more successful than the 6100/VT78.
Johnny
0 new messages