jhallen@wpi.wpi.edu (Joseph H Allen) (07/16/89)
A question for those old diehard dec fans... We (WPI) used to have a DECSYSTEM 20. One interesting thing about the DEC 20 (and I guess DEC 10 and pdp-6 as well) is that the registers are the first 8 or 16 locations in the main memory map. Does anyone know if code can be run in the registers? And if so, does it execute any faster than if it was in normal memory? Here's some other interesting DEC 20 features for those who don't know: - Each address had an indirect bit. Therefore you could do infinite levels of indirections. You can even crash your program by having self indirections. - An address was calculated for all instructions. Even those which didn't use the address. - Since every instruction generates an address, DEC made user definable instructions which were like software interrupts but which had an addressing mode. - For debugging purposes you could trap page faults- that is, you can have some code get executed each time a page virtual memory page gets loaded. There's a security flaw in one of the old versions of Tops-20- what you did was place a password accross a page boundary. Then you call some O.S. function which required a password. If the part of the password which is before the page boundary is correct, then you don't get a page fault. You can use this to reduce password searches from 96^8 to 96*8 character changes. - Some Tops-20 calls used 36-bit passwords. - There's an execute instructions which executes the instruction at the calculated address. (and yes, executing an execute instruction got things very confused) - There's instructions for handling bytes of any arbitrary size less than 36 bits (the world length). You had to access these bytes with special "byte pointers" - The family of computers which the DEC 20 was based didn't originally use a stack. There are a bunch of instructions which allow subroutine calls to occure with linked lists instead of stacks. - The DEC 20 didn't really have CC bits and all instructions were 1 word long so the O.S. (Tops-20 aka. Twenex) indicated different return conditions from O.S. calls by returning at different places. So an error return might be the next instruction after the O.S. call and a success condition would be 2 at 2 instructions after the O.S. call.
johnl@ima.ima.isc.com (John R. Levine) (07/16/89)
In article <3256@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >A question for those old diehard dec fans... We (WPI) used to have a >DECSYSTEM 20. One interesting thing about the DEC 20 (and I guess DEC 10 and >pdp-6 as well) is that the registers are the first 8 or 16 locations in the >main memory map. Does anyone know if code can be run in the registers? And >if so, does it execute any faster than if it was in normal memory? On the PDP-6 and the earlier PDP-10s, running code in the registers was considerably faster than from core. Fitting your inner loop into the registers was a pleasant intellectual exercise. On the '20 there was a cache so running from the registers no longer helped. >Here's some other interesting DEC 20 features for those who don't know: > > - Each address had an indirect bit. Therefore you could do > infinite levels of indirections. You can even crash your program > by having self indirections. If an interrupt arruved while calculating an address, it abandoned the address calculation, took the interrupt, and restarted the instruction when the interrupt returned. It occurred to me that I could find the interval between clock interrupts by writing a program that made a longer and longer indirect chain until it finally stalled because the chain was too long to deference between clock interrupts. > - An address was calculated for all instructions. Even those which > didn't use the address. Quite true. The instruction set was quite orthogonal which meant there were more different kinds of no-ops than on any machine before or since, e.g. test register and don't jump, test memory and don't skip, test bits against a register and disregard the result, etc. > - There's an execute instructions which executes the instruction at > the calculated address. (and yes, executing an execute instruction > got things very confused) It wasn't confusing at all. Execute instructions were a very fast way to have a program switch. I had complicated switches with two or three nested executes which worked very nicely. > - The family of computers which the DEC 20 was based didn't originally > use a stack. There are a bunch of instructions which allow > subroutine calls to occure with linked lists instead of stacks. Not true. When they designed the PDP-6 it wasn't clear what kind of subroutine linkage would be the most useful, so they gave you three -- store the return address in a register, store it in the memory location at the beginning of the routine, or push it on the stack. In fact all three turned out to be useful, though the last dominated in later years. Gordon Bell has said that the goal of the PDP-6 was to be an efficient Lisp and Fortran machine, so they put stacks in for the benefit of Lisp. > - The DEC 20 didn't really have CC bits and all instructions were 1 > word long so the O.S. (Tops-20 aka. Twenex) indicated different > return conditions from O.S. calls by returning at different places. > So an error return might be the next instruction after the O.S. call > and a success condition would be 2 at 2 instructions after the O.S. > call. This was consistent with the conditional instructions, most of which skipped the next instruction if the condition was met. The PDP-6 architecture was an excellent one for its day. It was both easy to program in assembler and easy to compile code for. It would probably still be around if the addresses were more than 18 bits long. They put a truly stupendous addressing crock into the DEC-20 but it was too incompatible with the regular addressing, and by then it was clear that 32-bit byte addressed machines, e.g. the Vax, would dominate. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
nelson@udel.EDU (Mark Nelson) (07/17/89)
In article <3256@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: > >A question for those old diehard dec fans... We (WPI) used to have a >DECSYSTEM 20. One interesting thing about the DEC 20 (and I guess DEC 10 and >pdp-6 as well) is that the registers are the first 8 or 16 locations in the >main memory map. Does anyone know if code can be run in the registers? And >if so, does it execute any faster than if it was in normal memory? > >Here's some other interesting DEC 20 features for those who don't know: > > - Each address had an indirect bit. Therefore you could do > infinite levels of indirections. You can even crash your program > by having self indirections. > We had DEC-20s where I went to school (Wesleyan University). One of the things that bothered me about the machines is that they didn't have an instruction I wanted: MOVEMI (move to memory immediate). Some explanation: The DEC-20 was a 1 1/2 address machine: every instruction could contain one memory location and one register source or destination. There were three basic move instructions: MOVE R1 mem Load the contents of memory location mem to register 1 MOVEM R1 mem Store the contents of R1 to memory location mem MOVEI R1 exp Put exp in R1 (load immediate, in other words) Now comes the fun part. As noted above, each address had an indirect bit, written symbolically as @, and as long as the address in the original instruction had the indirect bit set, indirection could continue to an arbitrary depth (with loops possible :-). So for example, if memory were set up as (location : contents) 100 : @200 200 : 300 300 : 400 Then MOVE R1 @100 would load 400 into R1, but MOVEI R1 @100 would load 300 into R1. The way I remembered it was that MOVE would load the second word in the indirection chain with the indirect bit clear, while MOVEI would load the first word with a clear indirect bit. Going to memory, MOVEM R1 @100 would store the contents of R1 in location 300, so it was basically the inverse of MOVE. But there wasn't any inverse of MOVEI. For an project I was working on, I wanted to do the equivalent in invisible forwarding pointers in some Lisp implementations. MOVEI for loads and my mythical MOVEMI for stores fit perfectly. But without MOVEMI I ended up having to add an extra level of indirection to all addresses. Mark Nelson ...!rutgers!udel!nelson or nelson@udel.edu This function is occasionally useful as an argument to other functions that require functions as arguments. -- Guy Steele
moj@utu.fi (Matti Jokinen) (07/17/89)
>One interesting thing about the DEC 20 (and I guess DEC 10 and >pdp-6 as well) is that the registers are the first 8 or 16 locations in the >main memory map. Does anyone know if code can be run in the registers? And >if so, does it execute any faster than if it was in normal memory? Yes, it could be done and it was considerably faster at least in the older DEC-10 models. I remember reading that a separate register set was not an essential part of the architecture --- if it was removed, the first 16 words of the main memory were used instead and the machine still functioned correctly, only more slowly. -- Matti Jokinen
jhallen@wpi.wpi.edu (Joseph H Allen) (07/17/89)
To: johnl@ima
Subject: Re: DECSYSTEM 20
Newsgroups: comp.arch
In-Reply-To: <4173@ima.ima.isc.com>
References: <3256@wpi.wpi.edu>
Organization: Worcester Polytechnic Institute, Worcester, MA. USA{Cc:
Bcc:
In article <4173@ima.ima.isc.com> you write:
>The PDP-6 architecture was an excellent one for its day. It was both easy to
>program in assembler and easy to compile code for. It would probably
>still be around if the addresses were more than 18 bits long. They put a
>truly stupendous addressing crock into the DEC-20 but it was too incompatible
>with the regular addressing, and by then it was clear that 32-bit byte
>addressed machines, e.g. the Vax, would dominate.
>John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
>{ bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something
>Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
By the time they got to the Dec-20, I think it was the fastest single
processor DEC ever made. I think even the high end VAX's of today only get
their speed from multi-CPUs. The DEC-20 was about 6 on the VAX speed scale.
The computer which replaced it (an Encore) is faster also only because it has
8 32332s. Each of these are about 1/2 speed of the '20.
But, as you say, it's best feature is that it was fun.mmm@cup.portal.com (Mark Robert Thorson) (07/18/89)
I heard a story that DEC had real problems getting one particular pdp-6 to function (not surprising, it's made out of something called "delay-line logic"), and that they pushed this lemon into the lake behind the converted textile mill which was DEC's main plant in those days. Anyone care to confirm that?
richard@aiai.ed.ac.uk (Richard Tobin) (07/19/89)
In article <929@tucos.UUCP> moj@polaris.utu.fi (Matti O. Jokinen) writes: >I remember reading that a separate register set was not an >essential part of the architecture --- if it was removed, the first 16 words >of the main memory were used instead and the machine still functioned >correctly, only more slowly. This is quite true. I have before a (UK) PDP-10 price list dated November 1969. Part KM10 is described as follows: FAST REGISTERS: 16 36-bit integrated circuit registers used as multiple accumulators and/or index registers and for highly iterative program loops. Replaces the first 16 locations of main core memory. The price is 4500 pounds. Incidentally, for a further 4500 pounds you could get part KT10A: DUAL MEMORY PROTECTION & RELOCATION REGISTERS: provide multiprogramming hardware for automatic protection and relocation of re-entrant and non-re-entrant code. (Required for timesharing). 16384 words of 1uS core memory cost 25750 pounds. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
cook@pinocchio.Encore.COM (Dale C. Cook) (07/19/89)
mmm@cup.portal.com (Mark Robert Thorson) recently posted that: |I heard a story that DEC had real problems getting one particular pdp-6 to |function (not surprising, it's made out of something called "delay-line |logic"), and that they pushed this lemon into the lake behind the converted |textile mill which was DEC's main plant in those days. Anyone care to |confirm that? They drained the mill pond not so many years ago and found all sorts of strange stuff! I know of one fellow who got into an argument with a tech and threw his entire toolbox out the window into the pond. Lots of dead boards that couldn't be debugged are in there too. The first generation 10, the KA, was also a non-synchronous machine and used "trickle down" logic. You could single step and watch the register lights change over the front panel and do a pretty good job of debug. All you needed to do really was find where the pulses failed to make the next rank toggle. The front panel (with lights) was a pretty big cost on that machine! One last story. This one is about Alan Kotok (whose initials backwards gave the KA it's model designation) and a certain PDP-6 that was sold to a major New York City firm and installed in a curtained fishbowl. In those days each machine was a one-of-a-kind job complete with its own set of prints annotated with added capacitors "for noise suppression" and so forth. If an engineer's machine failed in the field, the engineer got on the plane and fixed it! So it was that Alan was dispatched to NYC to fix the machine in the fishbowl. After some consideration he had them close the curtains and everyone but a security guard leave the room. The guard and Alan then proceeded to pick up one end of the 6 and drop it! And sure enough, the little bit of wire that had fallen into the backplane came loose and timesharing was restored. As Pogo observed, "Them war the days." - Dale (N1US) Encore Computer Corporation, Marlborough, Mass. INTERNET: cook@encore.com UUCP: {buita || talcott || husc6 || bellcore} !encore!cook
clements@bbn.com (Bob Clements) (07/20/89)
I've been resisting posting on this thread, but I guess I will break down and comment on this one. As an introduction, I was the project engineer for the KA10. This means I was the junior of the two engineers (Alan Kotok was the senior) who designed the logic. Being the junior, I had to do more paperwork, so I was Project Engineer. The true story behind JFFO: The European sales force came to us and said they need a bit-search instruction. A potential customer wanted to build a digital phone exchange and needed to poll bits representing phone lines. We were reluctant to add another incompatibility with the PDP-6. We said "How many machines will we sell if we add this instruction?" Answer: "Guaranteed five for a test bed, and hundreds if they go with the project." So we added the instruction. The customer didn't buy any. In article <10907@xenna.Encore.COM> cook@encore.com writes: >mmm@cup.portal.com (Mark Robert Thorson) recently posted that: >|I heard a story that DEC had real problems getting one particular pdp-6 to >|function (not surprising, it's made out of something called "delay-line >|logic"), and that they pushed this lemon into the lake behind the converted >|textile mill which was DEC's main plant in those days. Anyone care to >|confirm that? No way. Those babies cost a lot of money. Only 23 were built. Major surgery might have been done, but never junking one. And if one were junked, the parts would have been used. >One last story. This one is about Alan Kotok (whose initials backwards >gave the KA it's model designation) Sorry, not so. Just a coincidence. All assemblies in those days were assigned a two-letter/two-digit name. The trailing "10" is obvious. The first letter named the general type of equipment. "A" for Analog interfaces, "D" for Data communications, "M" for memories, "R" for Rotating memories, etc. "K" was all processors and their internal options. "KA" meant the main processor. The first PDP-11 processor was a KA-11. >and a certain PDP-6 that was sold >to a major New York City firm and installed in a curtained fishbowl. I can't think which machine this might be. I don't recall any -6's in NYC. >In those days each machine was a one-of-a-kind job complete with its >own set of prints annotated with added capacitors "for noise suppression" >and so forth. If an engineer's machine failed in the field, the >engineer got on the plane and fixed it! Well, there was a pretty good field service organization. Us engineers got called out, but rarely. And usually I went out to nearby sites. Alan got to go to the more exotic ones (U of Western Australia, etc.) due to his two more years of seniority. >So it was that Alan was dispatched to NYC to fix the machine in the >fishbowl. After some consideration he had them close the curtains >and everyone but a security guard leave the room. The guard and >Alan then proceeded to pick up one end of the 6 and drop it! And >sure enough, the little bit of wire that had fallen into the backplane >came loose and timesharing was restored. First, two guys couldn't lift the end of a PDP-6. Second, Alan wouldn't have volunteered to do it if it could be done. Third, that wasn't his debugging style. Sorry, I just don't believe this story a-tall. There were a lot of good stories, though. Pick up the DECUS tape of the 20th anniversary 36-bit session in Anaheim (1984?) to hear some of them. Like Alan filling for time at a live demo at FJCC while I snuck around the back and replaced a card in a PDP-10 while the machine was running, without crashing the machine. [Gee, this IS getting to be an old fart reminiscence thread. Well, the JFFO story is "computer.architecture in the real world".] > - Dale (N1US) Encore Computer Corporation, Marlborough, Mass. >INTERNET: cook@encore.com >UUCP: {buita || talcott || husc6 || bellcore} !encore!cook /Rcc Bob Clements, K1BC, clements@bbn.com (Making TC2000's these days.)
paul@moncam.co.uk (Paul Hudson) (07/20/89)
What? Is this comp.archaic? (groan). -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" These opinions void where prohibited by law.
dworkin@Solbourne.COM (Dieter Muller) (07/21/89)
In article <4173@ima.ima.isc.com> johnl@ima (John R. Levine) writes: >In article <3256@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >>A question for those old diehard dec fans... We (WPI) used to have a >>DECSYSTEM 20. One interesting thing about the DEC 20 (and I guess DEC 10 and >>pdp-6 as well) is that the registers are the first 8 or 16 locations in the >>main memory map. Does anyone know if code can be run in the registers? And >>if so, does it execute any faster than if it was in normal memory? > >On the PDP-6 and the earlier PDP-10s, running code in the registers was >considerably faster than from core. Fitting your inner loop into the registers >was a pleasant intellectual exercise. On the '20 there was a cache so running >from the registers no longer helped. [ discussing '20s here ] That's assuming, of course, that your cache was working at the time. The way the timing worked out was that _executing_ out of cache was the fastest (I want to say ~600 ns, but my Processor Handbook's at home at the moment; let me know if you're really interested in the numbers), registers was next to fastest (~750 ns), then MOS memory (~850 ns), then core (1024 ns). Putting code in the registers was slower than cache, because register values didn't go though the cache (separate data path). But, you couldn't page fault on a register, so you could be much more compute-bound if you wanted. Friend of mine hacked up a Mandelbrot program whose kernel fit in the registers. It was *real* noticeable when that puppy got fired up. BTW, there were 16 (decimal) registers, numbered 0-17 (octal). DEC had this thing about octal. One of the more amusing `features' of the early processors was that the indirect bit was handled purely in microcode, and wasn't interruptable. Translation: a indirection loop meant you got to power cycle the CPU to get it back. There was new version of microcode distributed to fix this eventually. Made for a few interesting nights when the MACRO-20 class had a project due. >The PDP-6 architecture was an excellent one for its day. It was both easy to >program in assembler and easy to compile code for. My favorite language was and still is MACRO-20. But then, I kinda liked TECO ;-) >They put a >truly stupendous addressing crock into the DEC-20 but it was too incompatible >with the regular addressing, and by then it was clear that 32-bit byte >addressed machines, e.g. the Vax, would dominate. Not much worse than the contortions involved in some of the PDP-11 segment- ation schemes. And after all, the segments themselves were quite reasonably sized (18 bits worth of 36-bit words was a fair amount of address space back in those days). To think there are Unix kernels these days that wouldn't fit into the memory the -20 I played on had.... Dieter -- I'm a killer, and I'm a clown -- Alice Cooper, 1971 Ha ha ha ha ha ha ha ha ha ha! What a day! -- the Joker, 1989 boulder!stan!dworkin dworkin%stan@boulder.colorado.edu dworkin@solbourne.com
egdorf@zaphod.lanl.gov (Skip Egdorf) (07/22/89)
In article <3256@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes:
A question for those old diehard dec fans... We (WPI) used to have
a DECSYSTEM 20. One interesting thing about the DEC 20 (and I
guess DEC 10 and pdp-6 as well) is that the registers are the first
8 or 16 locations in the main memory map. Does anyone know if code
can be run in the registers? And if so, does it execute any faster
than if it was in normal memory?
YES, it was common practice for very small tight loops to use 'blt'
(block transfer) to put a few instructions into the registers and then
transfer control to them. Yes it sped things up. I once did this as
a hack to get the most performance out of a GCD routine for some
rational arithmetic and it was found in a lot of other pieces of
software.
From "The Evolution of the DECsystem 10", CACM V21 n1, Jan 1978:
C. G. Bell, A. Kotok, T. N. Hastings, R. Hill. Copyright 1977
Association for computing Machinery. Permission is granted to
republish, but not for profit, all or part of the material provided
that ACM's copyright notice is given, ... see the magazine for the
rest...
(Also printed, I believe in "Computer Engineering, a DEC view of
hardware system design" Digital Press, 1978. The book prohibits copying,
so I am including this from the CACM article rather than the identical
text in the book :-)
"Since the ACs were in the address space, ordinary memory could be used
in lieu of fast registers to reduce the minimal machine price. In
reality, nearly all users bought fast registers."
Here's some other interesting DEC 20 features for those who don't know:
...
- The family of computers which the DEC 20 was based didn't
originally use a stack. There are a bunch of instructions
which allow subroutine calls to occure with linked lists
instead of stacks.
I believe that even the PDP-6 had stacks built in from the beginning.
From the same paper as above: (discussing original design issues)
"A stack machine was considered, based on B5000 and ...
The compromise we made was to provide a number of instructions to operate
on a stack, yet use the general registers as stack pointers."
...
"A general register architecture was selected with the registers in the memory
address space."
- The DEC 20 didn't really have CC bits and all
instructions were 1 word long so the O.S. (Tops-20 aka.
Twenex) indicated different return conditions from O.S.
calls by returning at different places. So an error return
might be the next instruction after the O.S. call and a
success condition would be 2 at 2 instructions after the
O.S. call.
The 1 word instructions allowed extensive use of "test-and-skip"
style branching. I recall that I thought the condition codes of the
360s and the PDP-11 when it came along to be very inelegant.
It might provide fertile noise (or is that signal?) for this newsgroup
to consider the tradeoffs in a "test and skip next instruction" vs
the more common (today) "Branch based on previous instruction's CC" in
an today's architectural climate.
Skip Egdorf
hwe@lanl.govjohn@anasaz.UUCP (John Moore) (07/23/89)
In article <19835@louie.udel.EDU> nelson@udel.EDU (Mark Nelson) writes: ]In article <3256@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: ]> ]>A question for those old diehard dec fans... We (WPI) used to have a ]>DECSYSTEM 20. One interesting thing about the DEC 20 (and I guess DEC 10 and ]>pdp-6 as well) is that the registers are the first 8 or 16 locations in the ]>main memory map. Does anyone know if code can be run in the registers? And ]>if so, does it execute any faster than if it was in normal memory? We used to have KA, KI and KL 10's. The KA and KI's both ran the TOPS-10 idle process completely in the registers. I think this was to avoid tiring out the (originally core) memory, and to avoid memory contention in closely coupled dual-processor configurations. -- John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john (602) 861-7607 (day or eve) long palladium, short petroleum 7525 Clearwater Pkwy, Scottsdale, AZ 85253 The 2nd amendment is about military weapons, NOT JUST hunting weapons!
john@anasaz.UUCP (John Moore) (07/23/89)
In article <EGDORF.89Jul21195924@zaphod.lanl.gov> egdorf@zaphod.lanl.gov (Skip Egdorf) writes: > - The family of computers which the DEC 20 was based didn't > originally use a stack. There are a bunch of instructions > which allow subroutine calls to occure with linked lists > instead of stacks. > >I believe that even the PDP-6 had stacks built in from the beginning. >From the same paper as above: (discussing original design issues) The 10, which was based on the 6, had stack operators that worked on regular registers. For example, PUSHJ (Push and Jump) would push the PC using the specified register as a stack pointer, and then jump to the effective address. POPJ would reverse that operation. The pair provided a subroutine call mechanism. You could push arguments onto the stack with PUSH and POP operators, although most assembly language hackers would just use a few of the general registers to hold arguments. We found one difference between the KL and KI 10 when we discovered some old code written by a long gone hacker that failed on the KL. It did a POP P,P (pop a value off of the stack controlled by register P and load register P with it). In one CPU version, P would be decremented before the operation, while in the other, it would be decremented afterwards. I found the ability to define multiple stacks to be very handy. A FORTH interpreter can be written in that instruction set that is very efficient. Also, I once wrote a binary tree balancing routine that used a pair of recursive co-routines. It took about 30 instructions for both routines. Try that with today's architectures! -- John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john (602) 861-7607 (day or eve) long palladium, short petroleum 7525 Clearwater Pkwy, Scottsdale, AZ 85253 The 2nd amendment is about military weapons, NOT JUST hunting weapons!
bruce@heather.pooh.com (Bruce Robertson) (07/24/89)
In article <443@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
I found the ability to define multiple stacks to be very handy.
A FORTH interpreter can be written in that instruction set that
is very efficient. Also, I once wrote a binary tree balancing routine
that used a pair of recursive co-routines. It took about 30
instructions for both routines. Try that with today's architectures!
The 680x0 can use any of its 8 address registers as stack pointers for
data. The only thing that makes its "stack pointer" register special
is that the hardware uses it for subroutine calls, interrupts, etc.
If you want to use one of the other stack pointers for flow control,
you have to do it with an instruction sequence:
; Call subroutine using A0 as a stack.
move.l #1f,-(a0)
bra subroutine
1f:
; Return from subroutine through A0 (trashes a register)
move.l (a0)+,a1
jmp (a1)
In other words, a FORTH interpreter could be made as efficient on the
680x0, but the binary tree balancing routine might take a little more
work.
I like the way the PDP-11 treats the program counter as a general
register. You can play a lot of tricks with that!
--
Bruce Robertson
Hundred Acre Software, Reno, NV
Domain: bruce@pooh.com
UUCP: ...!uunet!tahoe.unr.edu!heather!brucepeter@ficc.uu.net (Peter da Silva) (07/24/89)
In article <443@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes: > I found the ability to define multiple stacks to be very handy. > A FORTH interpreter can be written in that instruction set that > is very efficient. Also, I once wrote a binary tree balancing routine > that used a pair of recursive co-routines. It took about 30 > instructions for both routines. Try that with today's architectures! Well, the PDP-11 used the same concept (stack pointer is a general register). But, really, given that you're using 30 instructions anyway what's the overhead of an extra !mov Rn,SP! in each routine? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "...helping make the world Personal: peter@sugar.hackercorp.com. `-_-' | a quote-free zone..." Quote: Have you hugged your wolf today? 'U` | -- hjm@cernvax.cern.ch
peter@ficc2uu.net (Peter da Silva) (07/24/89)
In article <443@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes: > I found the ability to define multiple stacks to be very handy. > A FORTH interpreter cMark Mwritten in that instruction sete: p4 is very efficient. Also, I once wrote a binary tree balancing routlne > that used a pair of recursive co-routlnes. It took about 30 > instructions for both 26lnes. Try that with today's architectures! Wvariablehe PDP-11 used the same concept (stack pointer is a general register). But, really, given that you're using 30 instructions anyway what's the overhead of an0extra !mov Rn,SP! in each 26lne? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc2uu.net, +1 713 274 5180. | "...helping make the world Personal: peter@sugar.hackercorp.com. `-_-' | a quote-free zone..." Quote: Have you hugged your wolf today? 'U` | -- hjm@cernvax.cern.ch #! r
roy@phri.UUCP (Roy Smith) (07/25/89)
In <BRUCE.89Jul23155646@heather.pooh.com> bruce@heather.pooh.com (Bruce Robertson) writes: > I like the way the PDP-11 treats the program counter as a general > register. You can play a lot of tricks with that! I always wanted to try (I don't know why I never did) using auto-decrement mode on r7 (i.e. the pc). I wonder what would happen? A tight 1-instruction infinite loop? Akin, but not as bad as, the famous GD Nova and DEC-10 infinite-indirection loops, I guess. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
muir@postgres.uucp (David Muir Sharnoff) (07/25/89)
In article <3893@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > I always wanted to try (I don't know why I never did) using >auto-decrement mode on r7 (i.e. the pc). I wonder what would happen? A >tight 1-instruction infinite loop? Akin, but not as bad as, the famous GD >Nova and DEC-10 infinite-indirection loops, I guess. How about ... mov -(pc), -(pc) (assuming I remember the assembler syntax...) I've always thought that the PDP11 is the right machine to play COREWARS on. -Dave David Muir Sharnoff. "RISC is about one year ahead" muir@postgres.berkeley.edu (415) 524-2931
art@buengc.BU.EDU (A. R. Thompson) (07/26/89)
PDP/10 (aka DECSystem 10) war story. This was told to me by a DEC service engineer many moons ago (1971 or so). It's probably apocryphal, but so what? The 10 used as a swapping disk a really big (27") head per track disk from Borroughs that rotated vertically instead of horizontally. It was so sensitive they kept it isolated behind a fence. It seems that one day at the old woolen mill all of the PDP/10 swapping disks on test began crashing at exactly the same time. Every day, the clock would chime 3:30 and all the disks would snap their heads back. Engineers descended on the test area. The dragged out every oscilloscope they could find. They monitored the power supplies, they monitored the building power, they checked for magnetic fields, everything. Nothing worked. Every day, 3:30 bang all disks down. One day at 3:25 one of the engineers who could no longer bear the sight of the crashes went downstairs to the loading dock for a cigarette. At 3:30 right on the button a big truck rolled down the ramp and crashed, kerbang, right into the dock, shaking the building and crashing all the disks. They rotated all the disks 90deg and the problem went away.
pechter@scr1.UUCP (Bill Pechter) (07/27/89)
In article <3893@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In <BRUCE.89Jul23155646@heather.pooh.com> bruce@heather.pooh.com >(Bruce Robertson) writes: >> I like the way the PDP-11 treats the program counter as a general >> register. You can play a lot of tricks with that! > > I always wanted to try (I don't know why I never did) using >auto-decrement mode on r7 (i.e. the pc). I wonder what would happen? Try this one -- toggle 014747 into memory location 10000 (or any other memory location in the lower 28kw). Set the pc to that location and start it. The pc gets copied into pc-2 (autodecremented). Next that 014747 executes (pc-2 --> pc -4 ). What you have is the old DEC Field Service single instruction memory exerciser. I fixed a flat down 11/70 with this a year ago at W.W. Grainger in Niles, Ill. The program works in low memory which must be working to bootstrap the XXDP+ diag package. The program will halt, trap to 4, or trap to 10 if anything goes wrong (usually). One thing of interest... I've seen it wrap through the gpr's on some 11's but not on others. Any explanation on this would be appreciated. Bill (ex-Field Service) Now just hacking and administering systems. No pager, no standby, no problem. -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger bulkier and not much better **
mmm@cup.portal.com (Mark Robert Thorson) (07/27/89)
My love is the pdp-11, but a microprocessor company has given small-address machines such a bad name ... With regard to the pdp-11 and the -10, I recall a puzzling fact from the PDP-11 Peripherals Handbook. Out of a large collection of peripheral products there was one which did not have "11" in its name. This was the DL10 Unibus window. It was also unusual in that it might not return slave sync for a ridiculously long time, like 30 seconds. I know DEC-20's used 11/40's as front end machines. Did they interface via a DL10? Could someone briefly describe what services the 11/40 did? (Or it might have been labelled 11/35 -- same set of CPU cards.)
rick@pavlov.tmc.edu (Richard H. Miller) (07/28/89)
In article <929@tucos.UUCP>, moj@utu.fi (Matti Jokinen) writes: > >One interesting thing about the DEC 20 (and I guess DEC 10 and > >pdp-6 as well) is that the registers are the first 8 or 16 locations in the > >main memory map. Does anyone know if code can be run in the registers? And > >if so, does it execute any faster than if it was in normal memory? > > Yes, it could be done and it was considerably faster at least in the older > DEC-10 models. I remember reading that a separate register set was not an > essential part of the architecture --- if it was removed, the first 16 words > of the main memory were used instead and the machine still functioned > correctly, only more slowly. > -- > Matti Jokinen This is true of all the PDP-10 processors. As I remember, the KA-10 had one block of fast registers and swapped them when it did a context switch. The KI-10 model had 4 sets of fast registers, 2 were reserved for real-time processes, 1 was for normal user mode and one was for the monitor. There is a switch to disable fast memory as well as a switch to force the diagnostics to use a particular set. I remember a case we had that the monitor would crash whenever we tried to re-boot with an error indicating a problem in the register set. The diagnostic routine worked fine. After going around with the CE's, I forced the diagnostics to use the register set for the monitor (set 1 as I remember) and lo and behold, we discovered a register always picked a bit. (BTW, we will finally decommission our KI-10 system in September...sigh) Richard H. Miller Email: rick@bcm.tmc.edu Asst. Dir. for Technical Support Voice: (713)798-3532 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030
cook@pinocchio.Encore.COM (Dale C. Cook) (07/28/89)
[mmm@cup.portal.com (Mark Robert Thorson) recently asked: | |I know DEC-20's used 11/40's as front end machines. Did they interface via |a DL10? Could someone briefly describe what services the 11/40 did? |(Or it might have been labelled 11/35 -- same set of CPU cards.) I can't answer about the DL10. On the 10 side the interface was called a DTE20 (DECsystem To Eleven). The 11 didn't really have a great deal to do while timesharing was going on. It handled unit record peripherals (remember the card reader/punch? :-) and ran the console program that handled booting. It's primary use was running the diagnostic set (I think this was the first DEC use of a free-standing maintenance computer.) From the 11 it was possible to diagnose troubles when the mainframe's clock was stopped! If anyone is really interested in early diagnostic lore, I'd be glad to bend your ear sometime. (Is diagnostic architecture of interest to comp.arch readers?) - Dale (N1US) Encore Computer Corporation, Marlborough, Mass. INTERNET: cook@encore.com UUCP: {buita || talcott || husc6 || bellcore} !encore!cook
cdl@mplvax.EDU (Carl Lowenstein) (07/28/89)
In article <433@scr1.UUCP> pechter@scr1.UUCP (Bill Pechter) writes: >>In <BRUCE.89Jul23155646@heather.pooh.com> bruce@heather.pooh.com >>(Bruce Robertson) writes: >>> I like the way the PDP-11 treats the program counter as a general >>> register. You can play a lot of tricks with that! >Try this one -- toggle 014747 into memory location 10000 (or any other >memory location in the lower 28kw). Set the pc to that location and start >it. >One thing of interest... I've seen it wrap through the gpr's on some >11's but not on others. Any explanation on this would be appreciated. Some of the medium-early 11's (11/10 and 11/05 specifically) had a register set that was addressable on the bus by a program. Others of earlier and later vintage did not. Of course, all *Real* PDP-11's can read and load their register set through the front panel lights and switches. Nowadays, the lights and switches must cost more than the CPU chip, so they don't make them like that. -- carl lowenstein marine physical lab u.c. san diego {decvax|ucbvax} !ucsd!mplvax!cdl cdl@mpl.ucsd.edu
spider@qarry.enet.dec.com (Spider Boardman) (07/28/89)
In article <20767@cup.portal.com>, mmm@cup.portal.com (Mark Robert Thorson) writes [in part]... >With regard to the pdp-11 and the -10, I recall a puzzling fact from the >PDP-11 Peripherals Handbook. Out of a large collection of peripheral products >there was one which did not have "11" in its name. This was the DL10 >Unibus window. The DL10 was used to map the memory of the PDP-11 for use as communications gear. The DECsystem-10 could examine and deposit anywhere in -11 memory, and it could also play with the -11's front panel through the DL10. The -10 could also allow the -11 to talk back to it. This was done by assigning a part of the -10's memory to appear in the -11's address space. The assigned locations could use the byte logic of the -10 to write to multiple addresses (or at least bytes) in the -10's memory each time the -11 referenced them. In fact, this was part of the startup protocol for the nodes. One of the first things they did when they came on line was to tell the -10 what software they were running. The DTE20 later 'replaced' the DL10. It was simpler to maintain in the field, and was much smaller. I made up for this by being slower (at least for networking applications). The DTE20 is used by the console front-end (or master -11) to load, dump, and diagnose the -10. This is its only real functional advantage over the DL10. The DL10 almost never broke, but when it did there were few people who ever wanted to try and fix it. Its complexity made it hard to debug the logic. Actually, I know of at least one DL10 still in service at a current customer site. This customer has (so far) kept it because of its bandwidth advantage for its networking. Bias warning: My duties at DEC include maintaining the native TOPS-10 network software (ANF-10). Our nodes will run fine through DTE20s, but they'd still much rather be running through DL10s. Other people might not be so supportive of the DL10. Spider Boardman UUCP: ...!decwrl!qarry.enet.dec.com!spider 200 Forest St., MRO1-2/L14 ARPA: spider%qarry.enet.dec.com@decwrl.dec.com Marlboro MA 01752-9101 Domains: spider@qarry.enet.dec.com I just work here. I don't speak for DEC, and vice versa.
wilkes@mips.COM (John Wilkes) (07/28/89)
In article <11475@xenna.Encore.COM> cook@encore.com writes: >I can't answer about the DL10. On the 10 side the interface was called >a DTE20 (DECsystem To Eleven). The 11 didn't really have a great deal >to do while timesharing was going on. It handled unit record peripherals deleted... > - Dale (N1US) Encore Computer Corporation, Marlborough, Mass. It's been a few years, but i believe that the 11 also handled the serial lines that connected terminals to the system. Seems to me that it interrupted the '20 for every character, passing them as tty,,char 16-bit words. If you used a loooong cable to the terminal, and it was not actually connected, it would "ring." The '20 would see some stray character, and would spit out "Please log in" which would trigger more ringing, which would cause the '20 to say "Please log in" etc. This could cause the load average to get quite high. Ah, those were the days... [DECsystem 20 continued] (Pardon the non-arch posting; is it time for comp.sys.reminisce?) -- -wilkes wilkes@mips.com -OR- {ames, decwrl, pyramid}!mips!wilkes
jkrueger@daitc.daitc.mil (Jonathan Krueger) (07/28/89)
In article <11475@xenna.Encore.COM>, cook@pinocchio (Dale C. Cook) writes: >The 11 didn't really have a great deal to do while timesharing was >going on. It handled unit record peripherals (remember the card >reader/punch? :-) and ran the console program that handled booting. >Its primary use was running the diagnostic set I thought it handled terminal i/o, too, offloaded character interrupts, handled handshaking, may have done ^u and ^w. No? -- Jon --
rick@servax0.essex.ac.uk (Rick Blake) (07/28/89)
In article <20767@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >With regard to the pdp-11 and the -10, I recall a puzzling fact from the >PDP-11 Peripherals Handbook. Out of a large collection of peripheral products >there was one which did not have "11" in its name. This was the DL10 >Unibus window. It was also unusual in that it might not return slave sync >for a ridiculously long time, like 30 seconds. > >I know DEC-20's used 11/40's as front end machines. Did they interface via >a DL10? Could someone briefly describe what services the 11/40 did? >(Or it might have been labelled 11/35 -- same set of CPU cards.) The DL10 was a DMA device that allowed a PDP-11 access to some portion of DEC-10 memory - indeed, we still have one :-). I don't believe that it was available on the DEC-20. It was typically used for interfacing PDP-11 comms front ends with a DEC-10. It would only handle 11/40s, but it was possible by a little tweaking of the hardware (in the -11) to get 11/34s to hang off it as well. In principle, it would take 4 -11s. Generally, the 11/40s on a DEC20 were interfaced through a device called a DTE, as (correct me if I'm wrong, someone) the DL10 needed an external I/O bus, which was not provided on the DEC-20. Rick Blake - University of Essex, Colchester, UK. JANET: rick@uk.ac.essex Internet: rick@essex.ac.uk UUCP: ....!mcvax!ukc!sx!rick
pechter@scr1.UUCP (Bill Pechter) (07/31/89)
In article <976@mplvax.EDU> cdl@mplvax.ucsd.edu.UUCP (Carl Lowenstein) writes: >Some of the medium-early 11's (11/10 and 11/05 specifically) >had a register set that was addressable on the bus by a program. >Others of earlier and later vintage did not. > I believe every 11 had the registers addressable on the bus via a program... Includeing the 11/70. The trick was knowing the addressing space (memory management). a >Of course, all *Real* PDP-11's can read and load their >register set through the front panel lights and switches. >Nowadays, the lights and switches must cost more than >the CPU chip, so they don't make them like that. I remember and love the front panels -- especially the DecDatasystem 570 version of the 11/70 (or the unreleased 11/74 type where the 11/05 type short switches were used. Bill -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger bulkier and not much better **
sra@lcs.mit.edu (Rob Austein) (08/01/89)
MIT TECO, the implementation language for the original EMACS, executed
the code to move the buffer gap in the ACs, for speed. At one point
we ran some fairly hairy custom TECO programs to sort and merge the
MIT and NIC host tables, and it was not uncommon to a TECO that was
executing that code madly spinning away in the ACs. Particularly when
the code was running on a KS-10, where the ACs weren't any faster than
the rest of memory.
TECO's sorting command ("^P") may have also run in the ACs.
--Rob Austein, MITwerme@Alliant.COM (Ric Werme) (08/01/89)
In article <612@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >In article <11475@xenna.Encore.COM>, cook@pinocchio (Dale C. Cook) writes: >>The 11 didn't really have a great deal to do while timesharing was >>going on. >I thought it handled terminal i/o, too, offloaded character >interrupts, handled handshaking, may have done ^u and ^w. No? I forget what the Dec-20 did (it may have changed after I left, anyway), but on TOPS-10 the console front-end did virtually nothing other than couple the console frontend to the OS. Other -11s attached to the DTE20 (DN87S) or -11s attached to the DL10 (DN87) handled terminal concentrating and networking tasks, including echoing. The echoing was kinda nice - whenever the -11 handled a character it wasn't sure about echoing (generally control characters), it would tell the -10 to start echoing and the -11 would take over echoing after the line went idle or at some other convenient point. I like it better than the telnet echoing stuff, which I worked on at CMU. As for offloading, well, the network overhead was so high, it was more like onloading. -- | A pride of lions | Eric J Werme | | A gaggle of geese | uucp: decvax!linus!alliant | | An odd lot of programmers | Phone: 603-673-3993 |
jk3k+@andrew.cmu.edu (Joe Keane) (08/01/89)
The 11 has its registers in _physical_ memory. This is too bad, since user programs can't take advantage of it unless they have access to a lot of other things. But you can do a lot in 7 words. I bet you could set up the memory mapping so that the address of the PC is a useful instruction. I've heard of a lot of tricks, but never executing the PC...
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (08/02/89)
In article <1698@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: >BTW, there were 16 (decimal) registers, numbered 0-17 (octal). DEC had >this thing about octal. Back in days long by, people would actually *do work* in a power-of-2-based number counting system. You would not believe how much easier it is to do arithmetic in octal instead of hex -- not to mention translating between octal and the values displayed in the lights or that you key in the switches! >One of the more amusing `features' of the early processors was that the >indirect bit was handled purely in microcode, and wasn't interruptable. >Translation: a indirection loop meant you got to power cycle the CPU >to get it back. There was new version of microcode distributed to fix >this eventually. Made for a few interesting nights when the MACRO-20 >class had a project due. Of course, by "early processors" you mean "early KL processors"; the PDP-6, KA, and KI processors were not microcoded. I seem to remember some details about this KL bug, but I think it was more complicated than simply an @. kind of reference; I think page faults were involved. Also, wasn't it fixed by the time the 20's were released? I thought only the 10 sites got bit by it. The early versions of microcode for the KS processor had some amusing bugs in which certain floating point instructions with outrageous arguments could hang the processor. >My favorite language was and still is MACRO-20. But then, I kinda liked >TECO ;-) Me too. There are any number of times in which I would *kill* to get a version of TECO that ran on Unix. >>They put a >>truly stupendous addressing crock into the DEC-20 but it was too incompatible >>with the regular addressing, and by then it was clear that 32-bit byte >>addressed machines, e.g. the Vax, would dominate. It isn't clear that the VAX dominance over the DEC-20's was due to any technological reason. DEC tried damn hard for over 5 years to push the VAX over the -20 since everybody was to have a single architecture (VAX) and a single operating system (VMS). What of course happened is that all the DEC-20 people got driven into Unix. >Not much worse than the contortions involved in some of the PDP-11 segment- >ation schemes. And after all, the segments themselves were quite reasonably >sized (18 bits worth of 36-bit words was a fair amount of address space back >in those days). To think there are Unix kernels these days that wouldn't >fit into the memory the -20 I played on had.... I am perhaps the only programmer who wrote a large program using extended addressing in true -20 native mode (= was designed to be that way from the beginning). It was a lot more pleasant to program for than the PC or the Mac, both of which segment in ways that even impact C programmers. Unlike most segmented architectures, the DEC-20 30-bit segmented addressing mode had pointers which would cross segment boundaries so you could have data structures greater than a megabyte without worrying about it being split across segments. Try having a string greater than 64K on a PC sometime! The ultimate DEC-20 lover (who personally owns two), Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020 mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385 Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!! tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita sumomo mo momo, momo mo momo, momo ni mo iroiro aru uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (08/02/89)
In article <20767@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >With regard to the pdp-11 and the -10, I recall a puzzling fact from the >PDP-11 Peripherals Handbook. Out of a large collection of peripheral products >there was one which did not have "11" in its name. This was the DL10 >Unibus window. It was also unusual in that it might not return slave sync >for a ridiculously long time, like 30 seconds. > >I know DEC-20's used 11/40's as front end machines. Did they interface via >a DL10? Could someone briefly describe what services the 11/40 did? >(Or it might have been labelled 11/35 -- same set of CPU cards.) The DECSYSTEM-20 site prep documentation references the DL10, but only as the terminal lines for a KL10. There were really DH11's driven by the 11/40 front end. All KL10's had an 11/40 front end; I suspect that's what most 11/40's ended up being. On the DECsystem-10 the front end was the console processor responsible for booting and controlling the back end. On the DECSYSTEM-20, in addition to its console duties the front end controlled all the unit record devices: terminals (DH11), lineprinters (LP20 - a Unibus peripheral despite its name), and card reader (CD20). I think that, like the ARPAnet interface, the card punch and paper tape peripherals were on an I/O bus driven directly by the back end; only machines with such esoteric devices had back-end I/O busses. The console 11/40 ran a hacked-up version of RSX-11 called RSX-20F. There was elaborate code for each CPU to "keep alive" the other via a watchdog timer that would push the other CPU's boot button if it failed to keep it up to date. The very earliest KL10 systems used the field service diagnostic monitor for the 11/40 called KLDCP. KL10's could have up to three secondary 11/40 front ends called DN20's; generally these were DECnet synchronous line controllers. The KS10 used an 8080 for its console processor and had a Unibus adapter (UBA) to interface to the Unibus. It drove the peripherals directly with no front end help, modulo the KMC11 being a front end for a DUP11 in synchronous DECnet (the DN20's also used KMC11's to drive DUP11's; the combination was called "KDP"). Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020 mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385 Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!! tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita sumomo mo momo, momo mo momo, momo ni mo iroiro aru uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru
pechter@scr1.UUCP (Bill Pechter) (08/03/89)
In article <cYpQ1UW00VoBE9OFsn@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes: >The 11 has its registers in _physical_ memory. I beg to differ -- the addresses are mapped to memory space but they're onboard the cpu. (Otherwise how would the 11/44 and 11/70 with multiple register sets work if they were directly on the memory boards?) Bill -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger bulkier and not much better **
jk3k+@andrew.cmu.edu (Joe Keane) (08/03/89)
I wrote:
>The 11 has its registers in _physical_ memory.
I meant they appear in the physical address space, as opposed to virtual. Of
course are physically with the rest of the processor, which means you can write
(small) programs with no memory. ``Hey, let's see what happens if you pull out
R5.'' Can't do _that_ on a 68000!