[OT PDP-10 stuff] Re: Pointers to pointers to functions declaration
David Thompson
> OT digression that probably should move to alt.folklore.computers
> or some such; note that I never laid hands on an actual PDP-10
> (although I typed at MIT-ITS now and then :-) ).
>
alt.sys.pdp10 is more specific and much less crowded;
suggest followups there but M$OE won't set them, sorry.
> >Chris Torek <to...@BSDI.COM> writes:
> >>There have been machines with registers in "ordinary" RAM (e.g.,
> >>PDP-10, TI 9900) but it is relatively unusual.
>
> In article <9qa40d$k...@gap.cco.caltech.edu>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> >On the PDP-10 I believe that they were real registers that looked
> >like ordinary RAM.
>
> The low however-many words of memory were the registers. If you
16
> paid extra for the "hardware registers" option, you got a pile of
> transistors that would overlay this low-address-space and run at
Or rather, a bunch of transistors and other components
carefully mounted on circuit boards placed in backplanes
installed in the racks and connected to the right places,
accompanied by a nice thick binder of schematics, wirelists, etc.
Most of the cost was in the labor of designing, building,
testing, and maintaining the things; the actual components
were probably only USD 100 or so (in USD of the time).
> higher speed. An instruction that meant "use R1" would read and/or
> write the memory address for R1, and if you had the expensive
> option, this would be the fast transistors. Because of that:
>
Although it was an option in the (initial) design and price list,
I think the collective memory on alt.sys.pdp10 (last time this
came up) is that no 10 was ever actually delivered without it.
Any that was would have been unbearably slow.
Later CPU models used integrated circuits and any possible
cost savings became much less than the engineering and
adminstrative overhead so "fast" registers became standard.
> >There are stories of programs with a small loop
> >loading the instructions into the registers and executing them much
> >faster than in ordinary RAM.
>
> Right: if you put code in low memory, that low memory was of course
> also the registers. Point the program counter at the low memory and
> it executes the contents of the registers. If you paid extra for the
> "hardware registers" option, it goes that much faster.
>
> (This all happened because memory was made of "core": little magnetic
> donuts with wires run through it, which had slow cycle times.
> Magnetic core memory uses destructive read, sort of like DRAM but
> for different reasons, and requires rewrite-after-read. ...
Right. Which is why a lot of (us) old farts, and a lot of software
and/or documentation that traces well back, often refer to any
primary memory as "core". And perhaps also why some of us
forget everything if you interrupt us mid-cycle. <G>
--
- David.Thompson 1 now at worldnet.att.net
Paul Repacholi
> Chris Torek <to...@BSDI.COM> wrote in comp.lang.c:
> > OT digression that probably should move to alt.folklore.computers
> > or some such; note that I never laid hands on an actual PDP-10
> > (although I typed at MIT-ITS now and then :-) ).
> alt.sys.pdp10 is more specific and much less crowded; suggest
> followups there but M$OE won't set them, sorry.
> > >Chris Torek <to...@BSDI.COM> writes:
> > >>There have been machines with registers in "ordinary" RAM (e.g.,
> > >>PDP-10, TI 9900) but it is relatively unusual.
> > In article <9qa40d$k...@gap.cco.caltech.edu>,
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > >On the PDP-10 I believe that they were real registers that looked
> > >like ordinary RAM.
> > The low however-many words of memory were the registers. If you
> > paid extra for the "hardware registers" option, you got a pile of
> > transistors that would overlay this low-address-space and run at
> Or rather, a bunch of transistors and other components carefully
> mounted on circuit boards placed in backplanes installed in the
> racks and connected to the right places, accompanied by a nice thick
> binder of schematics, wirelists, etc. Most of the cost was in the
> labor of designing, building, testing, and maintaining the things;
> the actual components were probably only USD 100 or so (in USD of
> the time).
> > higher speed. An instruction that meant "use R1" would read
> > and/or write the memory address for R1, and if you had the
> > expensive option, this would be the fast transistors. Because of
> > that:
> Although it was an option in the (initial) design and price list, I
> think the collective memory on alt.sys.pdp10 (last time this came
> up) is that no 10 was ever actually delivered without it. Any that
> was would have been unbearably slow. Later CPU models used
> integrated circuits and any possible cost savings became much less
> than the engineering and adminstrative overhead so "fast" registers
> became standard.
Correct. There was at least one machine ordered without FM, but was
shipped with it. Unknown is if DEC swallowed the cost and shipped it
to avoid an odd-ball, or if they did a deal post sale. Did the KI
have a front panel 'Fast Memory Enable' switch?
> > >There are stories of programs with a small loop loading the
> > >instructions into the registers and executing them much faster
> > >than in ordinary RAM.
> > Right: if you put code in low memory, that low memory was of
> > course also the registers. Point the program counter at the low
> > memory and it executes the contents of the registers. If you paid
> > extra for the "hardware registers" option, it goes that much
> > faster.
Until the KL came along. TECO's searches are the classic example.
Compilers could not handle the overlapped register/memory at all well,
and that contributed to the demise of the 6/10 arch.
> > (This all happened because memory was made of "core": little
> > magnetic donuts with wires run through it, which had slow cycle
> > times. Magnetic core memory uses destructive read, sort of like
> > DRAM but for different reasons, and requires rewrite-after-read.
> > ...
> Right. Which is why a lot of (us) old farts, and a lot of software
> and/or documentation that traces well back, often refer to any
> primary memory as "core". And perhaps also why some of us forget
> everything if you interrupt us mid-cycle. <G>
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
jmfb...@aol.com
Paul Repacholi <pr...@prep.synonet.com> wrote:
>"David Thompson" <david.t...@worldnet.att.net> writes:
>
>> Chris Torek <to...@BSDI.COM> wrote in comp.lang.c:
>
>> > OT digression that probably should move to alt.folklore.computers
>> > or some such; note that I never laid hands on an actual PDP-10
>> > (although I typed at MIT-ITS now and then :-) ).
>
>> alt.sys.pdp10 is more specific and much less crowded; suggest
>> followups there but M$OE won't set them, sorry.
>
>> > >Chris Torek <to...@BSDI.COM> writes:
>
>> > >>There have been machines with registers in "ordinary" RAM (e.g.,
>> > >>PDP-10, TI 9900) but it is relatively unusual.
>
>> > In article <9qa40d$k...@gap.cco.caltech.edu>,
>> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> > >On the PDP-10 I believe that they were real registers that looked
>> > >like ordinary RAM.
>
>> > The low however-many words of memory were the registers. If you
>> > paid extra for the "hardware registers" option, you got a pile of
>> > transistors that would overlay this low-address-space and run at
>
>> > >There are stories of programs with a small loop loading the
>> > >instructions into the registers and executing them much faster
>> > >than in ordinary RAM.
>
>> > Right: if you put code in low memory, that low memory was of
>> > course also the registers. Point the program counter at the low
>> > memory and it executes the contents of the registers. If you paid
>> > extra for the "hardware registers" option, it goes that much
>> > faster.
>
>Until the KL came along. TECO's searches are the classic example.
>Compilers could not handle the overlapped register/memory at all well,
>and that contributed to the demise of the 6/10 arch.
What? I think you need new glasses.
<snip>
/BAH
Subtract a hundred and four for e-mail.
glen herrmannsfeldt
(snip about the PDP-10 being able to execute instructions out of
registers, among other things.)
(someone wrote)
>>Until the KL came along. TECO's searches are the classic example.
>>Compilers could not handle the overlapped register/memory at all well,
>>and that contributed to the demise of the 6/10 arch.
>What? I think you need new glasses.
It might mean that compilers couldn't generate code that would
optimize loops this way. I did hear about some machines that had
the ability to execute out of registers disabled. It made instruction
fetch in the normal case a little faster.
To me, the main advantage of mapping the registers to the beginning
of addressable memory is that separate memory and register addressing
modes are not required. On machines with a fixed instruction size there
is no advantage to a register addressing mode in reducing code size.
It would seem to complicate instruction decode slightly, and if commonly
used is a waste of instruction bits. Even worse is the complication
due to the indirect bit and indirect addressing.
-- glen
Paul Repacholi
> (someone wrote)
That was me.
> >>Until the KL came along. TECO's searches are the classic example.
> >>Compilers could not handle the overlapped register/memory at all
> >>well, and that contributed to the demise of the 6/10 arch.
> >What? I think you need new glasses.
> It might mean that compilers couldn't generate code that would
> optimize loops this way. I did hear about some machines that had
> the ability to execute out of registers disabled. It made
> instruction fetch in the normal case a little faster.
The problem was, that with registers and memory overlapping, and
indirection, it was a massive job to do and sort of register
allocation etc in the compiler. You could often not know what *may*
get stepped on by an indirection. Bad juju if you want to get
mega-smarts from the compiler. Worse if you can't throw hundreds on MB
at the compiler as well...
So it was just another nail in the coffin.
David Eppstein
Paul Repacholi <pr...@prep.synonet.com> wrote:
> The problem was, that with registers and memory overlapping, and
> indirection, it was a massive job to do and sort of register
> allocation etc in the compiler. You could often not know what *may*
> get stepped on by an indirection. Bad juju if you want to get
> mega-smarts from the compiler. Worse if you can't throw hundreds on MB
> at the compiler as well...
I seem to remember that in KCC the solution was to store all local
variables on the stack, and to assume that all registers were dirty after a
function call. Not great for efficiency compared to hand-coded assembly...
but its peephole optimizer did have enough intelligence to remove the stack
operations for simple leaf functions.
Another fun compiler trick was trying to duplicate human programmers'
ability to use nested conditional skips to avoid breaking control flow.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Jim Thomas
Paul> "David Thompson" <david.t...@worldnet.att.net> writes:
>> Chris Torek <to...@BSDI.COM> wrote in comp.lang.c:
>> > In article <9qa40d$k...@gap.cco.caltech.edu>,
>> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> > >There are stories of programs with a small loop loading the
>> > >instructions into the registers and executing them much faster
>> > >than in ordinary RAM.
>> > Right: if you put code in low memory, that low memory was of
>> > course also the registers. Point the program counter at the low
>> > memory and it executes the contents of the registers. If you paid
>> > extra for the "hardware registers" option, it goes that much
>> > faster.
Paul> Until the KL came along. TECO's searches are the classic example.
Which version of TECO? At least as of Texas TECO the old style search is
30 (base 10) words. That doesn't fit in the registers. And that's not
counting the 6 registers it used as registers. I don't remember any
version of the search code running in fast memory.
Paul> Compilers could not handle the overlapped register/memory at all well,
Paul> and that contributed to the demise of the 6/10 arch.
Them's fighting words :-) But I was not in on the F10 design and can't
defend it :-( Alan?
Nothead
Jim Thomas
Paul> g...@ugcs.caltech.edu (glen herrmannsfeldt) writes:
>> (someone wrote)
Paul> That was me.
>> >>Until the KL came along. TECO's searches are the classic example.
>> >>Compilers could not handle the overlapped register/memory at all
>> >>well, and that contributed to the demise of the 6/10 arch.
>> >What? I think you need new glasses.
/BAH wrote that.
>> It might mean that compilers couldn't generate code that would
>> optimize loops this way. I did hear about some machines that had
>> the ability to execute out of registers disabled. It made
>> instruction fetch in the normal case a little faster.
Paul> The problem was, that with registers and memory overlapping, and
Paul> indirection, it was a massive job to do and sort of register
Paul> allocation etc in the compiler. You could often not know what *may*
Paul> get stepped on by an indirection. Bad juju if you want to get
Paul> mega-smarts from the compiler. Worse if you can't throw hundreds on MB
Paul> at the compiler as well...
? Umm, isn't the compiler generating the indirection (which ISTR it did
not do very often anyway)? Seems much easier than load/store timing and
delay slot optimization :-)
Nothead
John Sauter
It might mean that compilers couldn't generate code
that would optimize loops this way. I did hear about
some machines that had the ability to execute out of
registers disabled. It made instruction fetch in the
normal case a little faster.
John Sauter:
I find that hard to believe. Didn't the bootstrap code
run in the registers? I remember hearing stories about
how difficult it was to fit the bootstrap code in
the registers.
John Sauter (J_Sa...@Empire.Net)
Joe Smith
Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>>>>>> "Paul" == Paul Repacholi <pr...@prep.synonet.com> writes:
> >> > Right: if you put code in low memory, that low memory was of
> >> > course also the registers. Point the program counter at the low
> >> > memory and it executes the contents of the registers. If you paid
> >> > extra for the "hardware registers" option, it goes that much
> >> > faster.
>
> Paul> Until the KL came along. TECO's searches are the classic example.
>
>Which version of TECO? At least as of Texas TECO the old style search is
>30 (base 10) words. That doesn't fit in the registers.
DEC TECO verion 21 or earlier - the one that came before Texas TECO.
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
Ric Werme
>>>>>> "Paul" == Paul Repacholi <pr...@prep.synonet.com> writes:
> Paul> Until the KL came along. TECO's searches are the classic example.
>Which version of TECO? At least as of Texas TECO the old style search is
>30 (base 10) words. That doesn't fit in the registers. And that's not
>counting the 6 registers it used as registers.
Back in the early days of BLISS at C-MU, the macro facility was
written in TECO. I could tell from the console lights (KA-10) when it
was nearly done as it spent less and less time executing from
registers. It may not have been a search routine, it may have been
insert/delete code.
The "6 registers it used as registers" can often hare an instruction.
Only if you have byte pointers or need AOBJN pointers do you need to
allocate a whole register. If you just need a random index register,
the low half of an instruction works fine, e.g.
10/ addm 1, buff
11/ skipe 1(10)
12/ aoja 10, 10
13/ popj p,
10/ skipn 0(12)
11/ popj p,
12/ addm 1, buff
13/ aoja 12, 10
will add whatever is in AC 1 to a block of memory that is terminated with
a zero. AC 10 is both instruction and index register. Note that the
the right half of AC 11 is available, actually the whole effective address
bits are available!
While I rarely needed to write code to run in registers, I was surprised at
the change in mindset it required. And I really wished that location 20
could be used for the exit instruction. On TOPS-10 it changed each interrupt
or so.
-Ric Werme
--
"When we allow fundamental freedoms to be sacrificed in the name of real or
perceived emergency, we invariably regret it. -- Thurgood Marshall
Ric Werme | we...@nospam.mediaone.net
http://people.ne.mediaone.net/werme | ^^^^^^^ delete
Mike McMahon
"Jim Thomas" <tho...@atlas.cfht.hawaii.edu> wrote in message
news:wwitd7m...@atlas.cfht.hawaii.edu...
> Which version of TECO? At least as of Texas TECO the old style search is
> 30 (base 10) words. That doesn't fit in the registers. And that's not
> counting the 6 registers it used as registers. I don't remember any
> version of the search code running in fast memory.
The inner loop of the ITS TECO search was nine instructions and ran in the
ACs. Even though it ran a bit slower on KLs, RMS insisted on keeping it
this way, since it ran _so much_ faster on KAs.
The search string was compiled into a linked list of instruction sequences,
with elements like CAIN for a simple constant character. The search loop
then did ILDB through the buffer and XCTed these as it went. Special
characters turned into PUSHJ instructions. The linked list elements were
the OR alternatives.
Why this was more the right thing makes sense when you remember that the
purpose was not to speed up the S command typed on a VT05. Rather it was to
make the language commands like indentation in EMACS run faster. These, for
the all important LISP mode in particular, were full of syntax wildcards and
other complex searches. These "internal" searches happened much more often
than user-initiated ones. Also, the default interactive search command in
EMACS was Incremental Search, which caused some heated debate back then, but
is now taken for granted by GNU-Emacs users. Except when searching for
something very specific in a very large file, all the CPU time went to
updating the display for the incremental behavior. Editors with only the
simpler commands would do better with a search with the same simple
semantics, but a better implementation algorithm, such as Boyer-Moore.
Ric Werme
>glen herrmannsfeldt (excerpted):
>It might mean that compilers couldn't generate code
>that would optimize loops this way.
Hardly a reason to bring the demise of an architecture! It wasn't until
RISC systems and their larger register files did compilers start passing
arguments in registers, that was a much bigger impediment than the
rare cases of executing out of registers.
I did hear about
>some machines that had the ability to execute out of
>registers disabled. It made instruction fetch in the
>normal case a little faster.
>John Sauter:
>I find that hard to believe. Didn't the bootstrap code
>run in the registers?
I heard the ITS folks at MIT removed that as it saved a ucode test and
gave a decent speedup.
Umm, which bootstrap code? The paper tape reader, DECtape, and
magtape, at least on the KA and KI used the hardware bootstrap
mechanism to load a block of bootstrap code into memory. The paper
tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
that.
John Sauter
Umm, which bootstrap code? The paper tape reader,
DECtape, and magtape, at least on the KA and KI used
the hardware bootstrap mechanism to load a block of
bootstrap code into memory. The paper tape boot, IIRC,
read the RIM10B loader into _core_ and jumped to
that.
John Sauter:
I thought the RIM loader was read into the registers.
Wasn't it the PDP-6 that used a keyed-in loader that
resided in "shadow memory:" the core that was normally
inaccessible because it occupied the same address space
as the registers?
John Sauter (J_Sa...@Empire.Net)
Arthur Krewat
>
> > Paul> Until the KL came along. TECO's searches are the classic example.
> >
> >Which version of TECO? At least as of Texas TECO the old style search is
> >30 (base 10) words. That doesn't fit in the registers.
>
> DEC TECO verion 21 or earlier - the one that came before Texas TECO.
As of 24A, there was still some utilization of fast ac's, but no
mention in the search routine. I have an idea it got too big :)
I wonder if fast ac's are even a gain with KL/KS architecture?
I'm sure it's a wash with the current simulators...
From TECO.MAC 24A(235):
;PUT MOVE ROUTINE IN FAST ACS
HRLI 11,200000+B+A*40 ;AC11:=MOVE A,[Q(PT/5)](B)
HRLOI 12,241000+A*40 ;AC12:=ROT A,-1
HRLI 13,245000+A*40 ;AC13:=ROTC A,-(REM(REQ/5))*7
HRLI 14,202000+B+AA*40 ;AC14:=MOVEM AA,[Q(PT/5)+1](B)
HRLI 15,245000+A*40 ;AC15:=ROTC A,(REM(REQ/5))*7-43
MOVE 17,[JRST,NROOM7] ;AC16:=SOJGE B,11
MOVE 16,.+1 ;AC17:=JRST NROOM7
SOJGE B,11 ;B:=B-1. DONE?
aak
Arthur Krewat
>
> >I find that hard to believe. Didn't the bootstrap code
> >run in the registers?
>
> I heard the ITS folks at MIT removed that as it saved a ucode test and
> gave a decent speedup.
>
> Umm, which bootstrap code? The paper tape reader, DECtape, and
> magtape, at least on the KA and KI used the hardware bootstrap
> mechanism to load a block of bootstrap code into memory. The paper
> tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
> that.
The way I heard it and remember it, it was the PDP-6, or at least the
KA10 where they were trying to figure out the least number of instructions
so that the bootstrap fit into the registers. And, as a side-effect, less
switches for the operator to twiddle with. The less the operators do,
the better :)
aak
Mark Crispin
> It might mean that compilers couldn't generate code that would
> optimize loops this way. I did hear about some machines that had
> the ability to execute out of registers disabled. It made instruction
> fetch in the normal case a little faster.
Maybe there was some machine that did that, but it wasn't a PDP-10.
That includes the ITS systems.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Christopher Stacy
>> to execute out of registers disabled.
Maybe this is some very confused recollection of the switch on the
PDP-10 that disabled "fast ACs". If you turned off the "FM ENB"
switch, then references to the ACs (locations 0-15) will access
the first sixteen core memory words instead.
jmfb...@aol.com
It certainly wasn't the demise of the PDP-10 architecture. I certainly
don't remember any conversations about the system not being "fast
enough". In addition, sharable code wasn't in the low core. I can
guarantee you that all of the compiler's segments were sharable.
A hundred kiddies writing a 10 line Fortran program would bring
the system down if the EXEs weren't sharable.
/BAH
Jim Thomas
Arthur> From TECO.MAC 24A(235):
Arthur> ;PUT MOVE ROUTINE IN FAST ACS
Arthur> HRLI 11,200000+B+A*40 ;AC11:=MOVE A,[Q(PT/5)](B)
Arthur> HRLOI 12,241000+A*40 ;AC12:=ROT A,-1
Arthur> HRLI 13,245000+A*40 ;AC13:=ROTC A,-(REM(REQ/5))*7
Arthur> HRLI 14,202000+B+AA*40 ;AC14:=MOVEM AA,[Q(PT/5)+1](B)
Arthur> HRLI 15,245000+A*40 ;AC15:=ROTC A,(REM(REQ/5))*7-43
Arthur> MOVE 17,[JRST,NROOM7] ;AC16:=SOJGE B,11
Arthur> MOVE 16,.+1 ;AC17:=JRST NROOM7
Arthur> SOJGE B,11 ;B:=B-1. DONE?
That code was kept in Texas TECO :-) But then it was done on KI's :-)
Nothead
Jim Thomas
Joe> In article <wwitd7m...@atlas.cfht.hawaii.edu>,
Joe> Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>> Which version of TECO? At least as of Texas TECO the old style search is
>> 30 (base 10) words. That doesn't fit in the registers.
Joe> DEC TECO verion 21 or earlier - the one that came before Texas TECO.
You wouldn't happen to have the source ? :-(
Nothead
Jim Thomas
Mike> "Jim Thomas" <tho...@atlas.cfht.hawaii.edu> wrote in message
Mike> news:wwitd7m...@atlas.cfht.hawaii.edu...
>> Which version of TECO? At least as of Texas TECO the old style search is
>> 30 (base 10) words. That doesn't fit in the registers. And that's not
>> counting the 6 registers it used as registers. I don't remember any
>> version of the search code running in fast memory.
Mike> The inner loop of the ITS TECO search was nine instructions and ran
Mike> in the ACs. Even though it ran a bit slower on KLs, RMS insisted on
Mike> keeping it this way, since it ran _so much_ faster on KAs.
Mike> The search string was compiled into a linked list of instruction
Mike> sequences, with elements like CAIN for a simple constant character.
Mike> The search loop then did ILDB through the buffer and XCTed these as
Mike> it went. Special characters turned into PUSHJ instructions. The
Mike> linked list elements were the OR alternatives.
Mike> Why this was more the right thing makes sense when you remember that
Mike> the purpose was not to speed up the S command typed on a VT05.
Mike> Rather it was to make the language commands like indentation in
Mike> EMACS run faster. These, for the all important LISP mode in
Mike> particular, were full of syntax wildcards and other complex
Mike> searches. These "internal" searches happened much more often than
Mike> user-initiated ones. Also, the default interactive search command
Mike> in EMACS was Incremental Search, which caused some heated debate
Mike> back then, but is now taken for granted by GNU-Emacs users. Except
Mike> when searching for something very specific in a very large file, all
Mike> the CPU time went to updating the display for the incremental
Mike> behavior. Editors with only the simpler commands would do better
Mike> with a search with the same simple semantics, but a better
Mike> implementation algorithm, such as Boyer-Moore.
Interesting, thank you! But since the internal search patterns were
somewhat known, was there any discussion of "pre-compiled" B-M search
tables and a B-M search as the default? Or were most of the searches of
the .* type that B-M can't deal with?
Nothead
Jim Thomas
Ric> Umm, which bootstrap code? The paper tape reader, DECtape, and
Ric> magtape, at least on the KA and KI used the hardware bootstrap
Ric> mechanism to load a block of bootstrap code into memory. The paper
Ric> tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
Ric> that.
And what was the "core" address of the code? 0 no?
Nothead
Ric Werme
No.
The hardware boot function first told the device to rewind (DECtapes
and magtapes did, the PTR didn't), then it read one IOWD, I think into
AC0. IOWDs (I/O word) have a negative count in the left half and the
address (-1?) in the right half. The device keeps reading and the CPU
stores data per the IOWD, incrementing both halves, until the count is
exhausted. Execution begins with the last word read, almost always some
sort of jump. (Duh!) Hmm. The PTR must've done something to skip
all the blank tape before the RIM10B code.
Oh, lessee if I'm right - The "Phone Book" calls it "readin mode", the
CPU does the functions of a DATAI to location 0, and then a series of
BLKIs. The RH is address-1. "Upon completing the block, the
processor halts only if the single instruction switch is on. Otherwise
it leaves readin mode, and begins normal operation by executing the
last word in the block as an instruction."
The MACRO manual includes the RIM10B code because it could generate
bootable paper tapes. That loaded at location 1 and fit in the registers.
If you look, you should be able to find a WWW page that describes it.
However, there was no point in protecting that code since it was on
the beginning of all tapes.
Some other posts mentioned PDP-6. That makes some sense. While I never used
one, I did visit SAIL's. I don't think it supported readin mode, but I don't
think it had fast ACs, either, making it pretty hard to keep the bootstrap
around in shadow memory. The MACRO manual lists the RIM10 bootstrap and
says it's normally toggled into memory ard started at location 20.
On PDP-11s before ROM cards showed up, we generally tried to keep bootstrap
code at the top of memory.
-Ric
Joe Smith
Ric Werme <we...@mediaone.net> wrote:
>John Sauter <J_Sa...@Empire.Net> writes:
> I did hear about
>>some machines that had the ability to execute out of
>>registers disabled. It made instruction fetch in the
>>normal case a little faster.
I remember seeing comments in the KL microcode that if the PC was
executing the opcode in AC and it modified AC+1, there was a big
performanc hit. Something about a roundabout path to the the modified
data back into the opcode fetch+decode registers. In other words,
executing code from the ACs was not too bad, just as long as you didn't
have self-modifying code in the ACs.
>>John Sauter:
>
>>I find that hard to believe. Didn't the bootstrap code
>>run in the registers?
>
>I heard the ITS folks at MIT removed that as it saved a ucode test and
>gave a decent speedup.
>
>Umm, which bootstrap code? The paper tape reader, DECtape, and
>magtape, at least on the KA and KI used the hardware bootstrap
>mechanism to load a block of bootstrap code into memory. The paper
>tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
>that.
True, but you could skip the first step by using shadow memory.
1) After running core-heating diagnostics, turn "Fast Memory" off.
2) Put bootstrap tape into paper-tape reader. Press Read-In-Mode button.
3) RIM10B loader gets stored in core locations 0-16, loads medium-short
bootstrap routine (one that can load SYS:SYSTEM from disk). Halts.
4) Turn "Fast Memory" on. RIM10B loader still in core locations 0-16.
5) Press "Continue" to run the bootstrap. Load Monitor.
If the system crashes, turn "Fast Memory" off, set address to 000001,
press "Continue". No need to reload RIM10B loader from paper tape
since the copy in core memory is still good.
The KL and KS did not use the RIM10B loader; they had front-end systems
that poked the bootstrap program into -10's memory. I believe that the
routine to determine how much physical memory was present executed in
physical page zero, not the ACs.
Joe Smith
Ric Werme <we...@mediaone.net> wrote:
>The MACRO manual includes the RIM10B code because it could generate
>bootable paper tapes. That loaded at location 1 and fit in the registers.
>If you look, you should be able to find a WWW page that describes it.
http://www.inwap.com/pdp10/rim10b.html
glen herrmannsfeldt
>>>>>> "Mike" == Mike McMahon <mmc...@mediaone.net> writes:
> Mike> "Jim Thomas" <tho...@atlas.cfht.hawaii.edu> wrote in message
> Mike> news:wwitd7m...@atlas.cfht.hawaii.edu...
> >> Which version of TECO? At least as of Texas TECO the old style search is
> >> 30 (base 10) words. That doesn't fit in the registers. And that's not
> >> counting the 6 registers it used as registers. I don't remember any
> >> version of the search code running in fast memory.
(snip)
>Interesting, thank you! But since the internal search patterns were
>somewhat known, was there any discussion of "pre-compiled" B-M search
>tables and a B-M search as the default? Or were most of the searches of
>the .* type that B-M can't deal with?
Boyer-Moore was 1977 I think. I presume TECO-10 was older than that.
-- glen
John Sauter
Hmm. The PTR must've done something to skip
all the blank tape before the RIM10B code.
John Sauter:
I vaguely recall that binary data on paper tape was
six bits per frame, with hole 8 punch and hole 7 not
punched. That would allow skipping blank tape to
look for binary data.
Rick Werme:
The MACRO manual includes the RIM10B code because it
could generate bootable paper tapes. That loaded at
location 1 and fit in the registers.
John Sauter:
So a CPU that could not execute from the registers would
be unable to run the RIM10B code when read from paper tape?
Rick Werme:
Some other posts mentioned PDP-6. That makes some sense.
While I never used one, I did visit SAIL's. I don't think
it supported readin mode, but I don't think it had fast
ACs, either, making it pretty hard to keep the bootstrap
around in shadow memory. The MACRO manual lists the RIM10
bootstrap and says it's normally toggled into memory ard
started at location 20.
John Sauter:
SAIL's PDP-6 did have fast ACs. They were the bay
at the left of the processor. That bay held 16 words,
and took as much floor space as the 164 memory, which
held 16,384 words!
John Sauter (J_Sa...@Empire.Net)
Paul Repacholi
> Some other posts mentioned PDP-6. That makes some sense. While I
> never used one, I did visit SAIL's. I don't think it supported
> readin mode, but I don't think it had fast ACs, either, making it
> pretty hard to keep the bootstrap around in shadow memory. The
> MACRO manual lists the RIM10 bootstrap and says it's normally
> toggled into memory ard started at location 20.
The 6 definatly has registers!! Failed Circus hated that part of the CPU,
know as 'The Harp' from the second set of interconections on the
front of cards. To do anything, it had to be unsoldered to remove
the cards.
I'm certain it also had Readin-Mode as well.
Jim Thomas
glen> Jim Thomas <tho...@atlas.cfht.hawaii.edu> writes:
>> Interesting, thank you! But since the internal search patterns were
>> somewhat known, was there any discussion of "pre-compiled" B-M search
>> tables and a B-M search as the default? Or were most of the searches of
>> the .* type that B-M can't deal with?
glen> Boyer-Moore was 1977 I think. I presume TECO-10 was older than that.
Communications of the ACM, October 1977, Vol. 20 Number 10, page 762
copied and pasted from Texas TECO where I put it in about 1978 - argh, the
edit history "standard" for TECO did not include dates.
TECO-10 was older but was not neglected :-)
Nothead
Jim Thomas
Ric> Jim Thomas <tho...@atlas.cfht.hawaii.edu> writes:
>>>>>>> "Ric" == Ric Werme <we...@mediaone.net> writes:
Ric> Umm, which bootstrap code? The paper tape reader, DECtape, and
Ric> magtape, at least on the KA and KI used the hardware bootstrap
Ric> mechanism to load a block of bootstrap code into memory. The paper
Ric> tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
Ric> that.
>> And what was the "core" address of the code? 0 no?
Ric> No.
Ric> ....
Ric> Oh, lessee if I'm right - The "Phone Book" calls it "readin mode", the
Ric> CPU does the functions of a DATAI to location 0, and then a series of
Ric> BLKIs. The RH is address-1. ....
Ric> The MACRO manual includes the RIM10B code because it could generate
Ric> bootable paper tapes. That loaded at location 1 and fit in the
Ric> registers. ....
Umm, again :-) You said "_core_" up above in reference to a previous
discussion about running code out of the fast AC's. I asked what the
"_core_" address was. You said it was not 0 and described how RIM10-B read
into 0-17(8). Them's the fast AC's, i.e., it runs out of the registers as
I was prompting. :-) Or else I misunderstood your point :-(
Nothead
Ric Werme
>>>>>> "Ric" == Ric Werme <we...@mediaone.net> writes:
> Ric> Jim Thomas <tho...@atlas.cfht.hawaii.edu> writes:
> >>>>>>> "Ric" == Ric Werme <we...@mediaone.net> writes:
> Ric> Umm, which bootstrap code? The paper tape reader, DECtape, and
> Ric> magtape, at least on the KA and KI used the hardware bootstrap
> Ric> mechanism to load a block of bootstrap code into memory. The paper
> Ric> tape boot, IIRC, read the RIM10B loader into _core_ and jumped to
> Ric> that.
> >> And what was the "core" address of the code? 0 no?
> Ric> No.
>Umm, again :-) You said "_core_" up above in reference to a previous
>discussion about running code out of the fast AC's. I asked what the
>"_core_" address was. You said it was not 0 and described how RIM10-B read
>into 0-17(8). Them's the fast AC's, i.e., it runs out of the registers as
>I was prompting. :-) Or else I misunderstood your point :-(
My point was that readin mode didn't necessarily start at 0. (Even Rim10B
starts at 16.) And when I typed that I had misplaced my memory about
where RIM10B ran from.
Another one that definitely ran in core was:
The DECtape layout reserved blocks 0, 1, & 2 for a DECtape bootstrap routine.
Hit readin, the CTY would LF, and then you could type the name of the
file to load or ask for a directory. (One day the CPU died mysteriously
and my clue to diagnose it was that the filename would print followed
by infinite '_'s (left arrows). A story for another day....)
So we'd have to type the name of the boot program for the disk, wait
for the directory to be read (block 100, decimal I think), wait for
the boot program to load and then type the name for the disk file to
load. Pain in the neck, especially when the RCA memory was
misbehaving. Unfortunately, the disk boot program was four blocks
long. So I wrote a hack to write it at the start of the tape anyway
and then updated the directory block to mark block 3 in use.
It was so much better - readin didn't have to rewind the tape far, so we
could pretty much push the button, turn around and type the file name,
or perhaps just hit return, I forget.