On Dec 26, 1:43=A0am, upsided...@downunder.com wrote: [snip]> If performance is not an issue, why limit the selection between 4 bit > or 8 bit parallel CPUs ? On a serial (1-bit) hardware, the word length > can easily be extended to match the requirements of the application by > adding bits into (dynamic) shift registers functioning as > accumulators.The performance of serial hardware could be adequate, but wider registers give some ease of programming (or code generation by a compiler) and code density advantages. With respect to size and power consumption, the instruction handling hardware would dwarf the contribution by the computation hardware, I would guess. Power can also be saved in some cases by running faster and being off/in lower power mode for longer (it is also conceivable that the power supply may have some burst-friendly aspects in terms of availability and/or efficiency; this might be more common for capacitor-based energy storage and some forms of energy harvesting). There is also some volume manufacturing advantage to have a single product (or even design component) that can fit a range of uses (an overprovisioned processing element can be underclocked or use run-halt-run techniques). Note: this is just weakly informed speculation. Paul A. Clayton just a technophile
Pipelined 6502/z80 with cache and 16x clock multiplier
Started by ●December 19, 2010
Reply by ●December 31, 20102010-12-31
Reply by ●December 31, 20102010-12-31
On Dec 30, 7:56=A0am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:> Morten Reistad wrote: > > I keep thinking what could be done if a classic machine > > like a PDP11 or a PDP10 was made with a modern process, no > > microcode in core instructions, and we substiute L2 cache > > for main memory, and ram for disk. And hyperchannel for > > I/O. > > Afair, both of them had memory indirect addressing?The PDP-10 had infinite indirect memory addressing--the addressed word from memory contained a bit to indicate if another level of indirection was to be performed.> > How high could we have driven the clock for such a system? > > Given that you'll need some form of microcode statemachine to handle > complicated addressing modes, the rest should be relatively easy.VAX style address modes need microcode, PDP-11 style do not. Single level indirect addressing can be easily accomodated in pipeline design and is orthogonal to inOrder versus OutofOrder issues. One could build and clock a PDP-11 at at least 2 GHz in low power process technology, 3-3.6 GHz in Intel/AMD/IBM process technologies (and that is assuming one increased to wordlength to 64-bits from 16- bits). Similarly, one could build a 64-bit CDC 6600 (or 7600) and cycle it at 4-5 GHz in Intel/AMD/IBM process technology. {Depending on what kind of dataflow one wants to maintain through the memory system.} Mitch
Reply by ●December 31, 20102010-12-31
In comp.arch MitchAlsup <MitchAlsup@aol.com> wrote: ...> The PDP-10 had infinite indirect memory addressing--the addressed word > from memory contained a bit to indicate if another level of > indirection was to be performed.... Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang because of this little h/w feature? Was there a light on the KI console (or maybe above it) that essentially indicated an indirect loop? -->My sig lines fall into 2 broad categories: either wise or silly. >I rely on the reader understanding which is which.Congratulations. You must be a very special boy or girl. -- tg <tgdenning@earthlink.net>, 1 Dec 2010 12:35:45 PST
Reply by ●December 31, 20102010-12-31
On Fri, 31 Dec 2010 10:55:30 -0800 (PST), "Paul A. Clayton" <paaronclayton@gmail.com> wrote:>On Dec 26, 1:43�am, upsided...@downunder.com wrote: >[snip] >> If performance is not an issue, why limit the selection between 4 bit >> or 8 bit parallel CPUs ? On a serial (1-bit) hardware, the word length >> can easily be extended to match the requirements of the application by >> adding bits into (dynamic) shift registers functioning as >> accumulators. > >The performance of serial hardware could be adequate, but wider >registers give some ease of programming (or code generation by a >compiler) and code density advantages.In the 1970's there was an interesting tradeoff between the HP35 scientific calculator (1 bit serial) and the Sinclair Cambridge calculator (essentially a reprogrammed 4 bit BCD calculator). Anyway, if I had to design a computer using tubes, I would go for a serial design and trying to use as much transmission line theory as possible to use as high clock speeds as possible.
Reply by ●January 1, 20112011-01-01
<kym@kymhorsell.com> wrote: +--------------- | MitchAlsup <MitchAlsup@aol.com> wrote: | > The PDP-10 had infinite indirect memory addressing--the addressed | > word from memory contained a bit to indicate if another level of | > indirection was to be performed. | | Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang | because of this little h/w feature? +--------------- Your memory is faulty. (Sorry.) ;-} ;-} The PDP-10 could take an interrupt at *each* step of effective address calculation: a "step" consisted of a fetch of the address field (Y), the addition of the value of the indicated index register (if the X field was non-zero), and the checking of the indirect bit (I) to see if the effective address calculation was done or not. So while a user program that did "JRST @." would certainly burn a *lot* of CPU time, if would *not* lock up the system! Clock interrupts would continue to schedule other processes [the CPU hog would get bumped down to lower and lower priority], and the JRST itself could be interrupted by simply typing Cntl-C at the user's terminal. By the way, complex index+indirect chains were used to great effect in the ALGOL-10 compiler for addressing multidimensional arrays using Iliffe vectors <http://en.wikipedia.org/wiki/Iliffe_vector>, where every level except the last had the indirect bit on [and every level specified a different index register, of course]. That meant that the ALGOL code "FOO[I,J,K] := FOO[I,J,K] + 1;" could be done in *one* instruction if I, J, & K were already in index registers: AOSM @FOO(I) [FOO here is not the address of the array data per se, but of the first level Iliffe vector.] +--------------- | Was there a light on the KI console (or maybe above it) | that essentially indicated an indirect loop? +--------------- Hmmm... You might be thinking of the phenomenon of "pink scheduling", which occurred when the scheduler & VM system were thrashing over which process to run. There were 7 lights that told you if code was executing at one of the 7 interrupt levels, with level 7 [the lowest priority] being researved for the scheduler. When the VM system got clogged up and thrashing started, the scheduler would burn so much CPU time that the level 7 light would burn dimly more or less steadily, which looked "pink" both with the incandescent bulbs used in the KA-10 and the red LEDs used in the KI-10. -Rob p.s. "Indirect loops" *could* be seen on the lights, but not on or over the console. The CPU bay to the left of the console also had a large number of lights near its top, and one row of them contained the instruction register (IR) of the current instruction being executed -- or indirect address being calculated. So if the I bit in the IR was on, you knew that the current process was doing a lot of indirect addressing. But, again, "indirect loops" didn't stop scheduling, so that was really only meaningful on an otherwise-idle system. ----- Rob Warnock <rpw3@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
Reply by ●January 1, 20112011-01-01
Rob Warnock wrote:> <kym@kymhorsell.com> wrote: > +--------------- > | MitchAlsup <MitchAlsup@aol.com> wrote: > | > The PDP-10 had infinite indirect memory addressing--the addressed > | > word from memory contained a bit to indicate if another level of > | > indirection was to be performed. > | > | Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang > | because of this little h/w feature? > +--------------- > > Your memory is faulty. (Sorry.) ;-} ;-} > > The PDP-10 could take an interrupt at *each* step of effective address > calculation:General Electric mainframes had a similar 'indefinite indirection' feature. On batch-oriented GE-400s an indirection loop would (IIRC) hang the processor, and the operator would have to hit the reset button. On larger and later GE-600s the processor had a watchdog Operation Not Complete fault that would interrupt after any instruction had gone on for too long. ISTR the timesharing version of GE-400 included some kind of watchdog feature. I never saw long indefinite indirection chains used -- it always seemed as though software could collapse the sequence -- but the flexible address modes that supported it could every once in a while save a lot of work. Mel.
Reply by ●January 1, 20112011-01-01
In comp.arch Rob Warnock <rpw3@rpw3.org> wrote:> <kym@kymhorsell.com> wrote: > +--------------- > | MitchAlsup <MitchAlsup@aol.com> wrote: > | > The PDP-10 had infinite indirect memory addressing--the addressed > | > word from memory contained a bit to indicate if another level of > | > indirection was to be performed. > | Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang > | because of this little h/w feature? > +--------------- > Your memory is faulty. (Sorry.) ;-} ;-} > The PDP-10 could take an interrupt at *each* step of effective address > calculation: a "step" consisted of a fetch of the address field (Y), > the addition of the value of the indicated index register (if the X... Yes, I realise a user process with an indirect loop would just waste its user time, not anyone elses, and the tick would still trap to SCHED and COMCON would still live. But a "buggy TOPS-10" was intended to indicate we're taking into account interrupt-level code that is not completely working. It's certainly logically possible to have a fault-handling routine throw up a fault and make no progress. Hence the concept of "hang" rather than a "stop". I notice even now that Unix/Linux page fault routines sometimes fault because they trip an unexpected page fault, for instance. What with the formal difficulty of guaranteeing general concurrent code doesn't have live locks, that has to be expected. When the h/w has a "no progress" mode built-in we'd imagine very special care needs to be taken to ensure that doesn't happen at vulnerable points. And *that* should be pretty difficult to guarantee. I tried looking through the online DEC10 manuals, but they were either about KL's (not KI's, which I worked on c1973--1983) and didn't even have the same STOPCD's I remember (e.g. the old "POP" seemed to come up on our machine quite a bit and not even mentioned in the man I was reading), or didn't cover anything interesting in the way of hangs. Beside seeing the big blue boxes apparently frozen, with one of the then-snr system guys or one of the DEC guys (do we remember when a couple of DEC guys used to sit in a little room on-site waiting for the h/w to screw up? :) point to some console light saying "hey -- it's stuck in an indirect loop in kernel mode!", I also think one of those funny paper manuals -- that looked (and smelled) a bit like they'd been roneoed off at the local college print shop rather than "printed" -- had some explicit warnings about certain practices regarding indirect bits and certain instructions executed in interrupt-level code. Unfortunately all my own copies of manuals got tossed about 5 years back when I thought "hey, this has been sitting here for the past 30 years and I haven't looked at it; it's taking up valuable space I could put a couple pen drives in and it's bound to be on the web somewhere anyway...". -- nice try, but wikipedia is not a credible source. -- Animal06 ["10,000 lakes"] <WherewasI@Friday.com>, 03 Dec 2010 13:05:47 -0500
Reply by ●January 1, 20112011-01-01
On Dec 31 2010, 2:34=A0pm, k...@kymhorsell.com wrote:> In comp.arch MitchAlsup <MitchAl...@aol.com> wrote: > ...> The PDP-10 had infinite indirect memory addressing--the addressed wo=rd> > from memory contained a bit to indicate if another level of > > indirection was to be performed. > > ... > > Is my memory faulty or was it possible for the (buggy) TOPS-10 to hang > because of this little h/w feature? Was there a light on the > KI console (or maybe above it) that essentially indicated an indirect loo=p? There was a rev of TOP-10 that would timeout when accessing a particular memory (OS) structure on the KIs. Either DEC added another level of indirection, or rearranged the memory footprint so that the timer timeout was exposed. I was going to mention this, but though "just let it go". Mitch
Reply by ●January 1, 20112011-01-01
In comp.arch MitchAlsup <MitchAlsup@aol.com> wrote: ...> There was a rev of TOP-10 that would timeout when accessing a > particular memory (OS) structure on the KIs. Either DEC added another > level of indirection, or rearranged the memory footprint so that the > timer timeout was exposed. I was going to mention this, but though > "just let it go".I'm not sure what you mean. "A particular memory (OS) structure" -- does that mean some specific O/S table had a timeout on it, or does it mean that if an indirect was stuck in self ref it would get timed out? No matter. With this nasty @x feature you could easily hook 1000s of locations together and have a long loop from one to the next and back to the first again. I don't think anyone ever did *that*. But you never know who might use such a trick to (e.g.) implement a free list for a LISP interpreter. I was just talking to another guy that worked at the same location in the 70s and he reminded me how fragile the system was. Maybe it was an improvement on the PDP-15 OS that this particular college had before their KI, but TOPS-10 crashed about once a day according to the logbook. Of course, we did have a few users for the poor thing -- maybe 60 at a time. The hardware ran around .6 MIPS. (It was rumoured the local Stock Ex ran a DEC10 with 200+ users *very* slowly). Robustness wasn't improved by DEC quality control that wasn't always what it could have been. I remember one time some kid wrote a Pascal program (must have been PASREL because it was during daylight hrs when we enforced a memory limit that prevented PASCAL from running) with a recursion prob. Essentially proc p called proc p. Guess what -- caused a STOPCD. The kid came to me and told me he'd caused the crash. And I didn't believe it. How could userland code with a common error crash the system? Didn't anyone check stuff before they shipped it? They must, surely. But I sat next to him as he logged in and ran the program again. And the STOPCD happened again. -- nice try, but wikipedia is not a credible source. -- Animal06 ["10,000 lakes"] <WherewasI@Friday.com>, 03 Dec 2010 13:05:47 -0500
Reply by ●January 2, 20112011-01-02
In article <e073c9bf-50f4-45e1-97e2-11a5354c980b@g25g2000yqn.googlegroups.com>, MitchAlsup <MitchAlsup@aol.com> wrote:>On Dec 30, 7:56�am, Terje Mathisen <"terje.mathisen at tmsw.no"> >wrote: >> Morten Reistad wrote: >> > I keep thinking what could be done if a classic machine >> > like a PDP11 or a PDP10 was made with a modern process, no >> > microcode in core instructions, and we substiute L2 cache >> > for main memory, and ram for disk. And hyperchannel for >> > I/O. >> >> Afair, both of them had memory indirect addressing? > >The PDP-10 had infinite indirect memory addressing--the addressed word >from memory contained a bit to indicate if another level of >indirection was to be performed.For the ones who do not know the PDP10 instruction set: The address calculation and the instruction execution are totally separate on this machine. You could do stuff like MOVEI A,10(B), which would add 10 to the the value in register B, placing the result in register A.>> > How high could we have driven the clock for such a system? >> >> Given that you'll need some form of microcode statemachine to handle >> complicated addressing modes, the rest should be relatively easy.With the PDP10 it would make sense to have a hardware engine that does all the straightforward stuff that can be done in one or two cycles, and fault to microcode on all the rest. Address evaluations from straight values or register indexed should be doable "on the fly", and microcode could do the memory indexed and the indirect references.>VAX style address modes need microcode, PDP-11 style do not. Single >level indirect addressing can be easily accomodated in pipeline design >and is orthogonal to inOrder versus OutofOrder issues. > >One could build and clock a PDP-11 at at least 2 GHz in low power >process technology, 3-3.6 GHz in Intel/AMD/IBM process technologies >(and that is assuming one increased to wordlength to 64-bits from 16- >bits).And a re-implemented PDP11/75 with 64k segments of small pages should be doable with registers and a few dozen pages in L1 cache memory, and 2-16M L2 cache memory as "main core", and then add lots of processors. And have the memory interface as "disk". Change a few drivers, and such a machine should run V7 unix blazingly fast.>Similarly, one could build a 64-bit CDC 6600 (or 7600) and cycle it at >4-5 GHz in Intel/AMD/IBM process technology. {Depending on what kind >of dataflow one wants to maintain through the memory system.}-- mrr