Pipelined 6502/z80 with cache and 16x clock multiplier

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.

There are a number of second sources for 6502's, but they aren't all the same chip ... several manufacturers (incompatibly) extended the original instruction set to add unconditional branching and a variety of bit manipulation instructions. Some of the extended variants have instruction sets that conflict with the official 65c02 instruction set.

I hadn't heard about variants missing an index register ... that would effectively cripple the chip regardless of which register was missing. The "indexed indirect" (pointer table) address mode depends on X and "indirect indexed" (pointer+offset) mode depends on Y. You can work around lacking either of these, but the code would be both larger and slower.

AFAIK, Western Design Center is the only source for 65816.

There are freely available native and cross development tools targeting both the 6502 and 65816: C and Pascal compilers, Forths, and a whole selection of assemblers and disassemblers.

Freely available from Apple are the APW 65816 assembler and C compiler (you needs a //gs to run these) and the corresponding MPW 65816 cross development tools for the Macintosh.

There is a proprietary MPW Pascal compiler for the 65816 but, AFAIK, it isn't available free. TML Pascal (//gs) is available free.

George

As a matter of known fact, the "SNES on a chip" and other similar devices from Sunplus (inter alia) have a 65C816 within. Of course, that might be no more legally licensed than the SNES cartridge images that are typically on the ROM array right next to the CPU ;)

Some of Winbond's more recentish chips also had a c816 core. Don't recall the details, it has been a while since I cared about that field.

Sure, but I was talking about internally-developed proprietary SDKs for toy chips. These typically use a sort of macro language, and are very primitive. They're developed to the bare minimum required to get people to buy the chips, and in many cases they are the ONLY way to write programs for the chips (short of writing completely from-scratch asm, which loses you the libraries that make the chip possible to work with while retaining your sanity).

The head guy from Winbond's toy chip division once said to us when we were complaining about the crappy tools "I have three engineers on these chips. I can have them work on tools, or on the next version of the chip. What do you think I'm going to ask them to do?"

I think Rockwell made an enhanced version of the 6502 for the later BBC micros (the BBC Master).

There were a range of programming languages available for the BBC Masters, including Pascal, C, Forth and Logo, running native on the

Of course, native BBC Micro software is perhaps not the most useful starting point for cross development...

I have written some code for sampler chips that contain dual 6502s at opposite clocks. AFAIK they are still used in sonars because they now have such a low price and small footprint; pulling in 14 bit a/d samples, compress them to 8 and shift them out as a bit stream.

I don't think these will benefit from faster speeds. Perhaps a 2x or 4x speedup, but they perform such a lowly task that more oomph is wasted on them.

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.

How high could we have driven the clock for such a system?

NO classic memory accesses. Just L1/L2 cache systems, and a FAST "disk".

-- mrr

Actually, this might be a good sort of use! E.g., I often throw two or three "extra" MCU's into a design in place of an FPGA+software (in the "main" CPU). With more MIPS, you could address a wider range of "subsystems".

But, you need rigidly defined, small-ish algorithms to avoid having to lose any economies that the small/fast CPU gives you (since you want the memory complement to be entirely in the MCU). E.g., I like using MCUs for sound subsystems -- tasks that are easy to offload from the main CPU (very little interaction and very terse data formats) that can also be coded in very small memory footprints.

While the 10 and 11 were "pigs" in their day, I think they would be considered "lightweight" when compared to i64 devices today. I.e., why couldn't you clock them just as fast? And, assuming you resist the temptation to add all the cruft that is now part of ISA offerings, you could probably get great performance from them

VAX SOC! :>

Afair, both of them had memory indirect addressing?

Given that you'll need some form of microcode statemachine to handle complicated addressing modes, the rest should be relatively easy.

Terje

I don't doubt they exist ... WDC does license an embeddable 65816 core. But a core based product does not count as a "second source". GTE and Sanyo used to make 65816s as second sources for WDC ... but they no longer do so. AFAIK, WDC currently is the only source to get an actual 65816 chip.

George

It would be very fast on old applications and operating systems, but not so much on newer ones.

On Dec 26, 1:43=A0am, snipped-for-privacy@downunder.com wrote: [snip]

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

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.

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

Mitch

In comp.arch MitchAlsup wrote: ...

...

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?

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.

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 , 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

AOSM @FOO(I)

+--------------- | 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

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.

...

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...".

rd

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

In comp.arch MitchAlsup wrote: ...

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.

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.

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.

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

And have the memory interface as "disk". Change a few drivers, and such a machine should run V7 unix blazingly fast.

-- mrr