I can't seem to find any CPU that is more powerful than the 68000 and 65816, but less powerful than the ARM. You mean to tell me there was no 16-bit RISC CPUs inbetween?

Well, the 680x0 family was really more 32-bit system, including the 68000, unless you're counting the 8088 as an 8-bit CPU (the 8088 had an 8-bit data bus, and the 68000 had a 16-bit data bus, but internally the registers were twice as wide).

Have you looked at the PA-RISC, MIPS, VAX, and ALPHA architectures yet?

To me, there are several that come to mind: Zilog Z8001/Z8002, Harris RTX2000 (16-bit), Inmos T212 (16-bit) T400/800 (32-bit), TI TMS320C30 (32-bit DSP), Analog Devices SHARC (32-bit DSP), Hitachi SuperH, etc. The hybrid RISC/CISC Intel/AMD architecture is clearly the general purpose processor performance leader.

All across the processor spectrum there are various constraints that determine the suitability of a particular CPU architecture to a specific task or application domain. I like and use various ARMs, but I don't consider them RISC devices in the same vein as the first MIPS processors. They may have been RISCier at one time, but their application domains have grown in scope, and the ARM architecture has evolved to incorporate both RISC and CISC features.


To the best of my recollection, at the time the MIPS/SPARC processors were introduced, formally initiating the transition to RISC architectures, there was not an intermediate 16-bit RISC processor. If the RISC machine could not outperform the Motorola 68020 or the Intel/AMD 386/486 devices, why bother? The performance and price of these processors, compared to previous generations, was substantial. To recover the cost of the development of a RISC processor, the company making a device had to compete against the CISC offerings of Intel, AMD, and Motorola. In my opinion, a 16-bit RISC device targeting a high volume, embedded market would not generate sufficient revenue to justify the expense needed to develop and market it. Furthermore, when the additional cost of high speed RAM and ROM needed to deliver RISC performance is considered, I don't think such a device made financial sense to develop at that time.

_________________
Michael A.

It feels to me that a 16-bit RISC would be a tricky proposition. For performance, you want a fair number of registers, and to have register-to-register operations, but with only 16 bits in an opcode (and no second fetch for an operand, for a true RISC) you don't have enough bits to specify many registers. Also, 16 bits is a bit inadequate for an address space, so you'd want wider registers or a banked or segmented approach. And if you have wider registers you now have trouble with immediate values which are too wide for the instruction.

Of course you could relax all those RISCy constraints, and you might end up with something like ARM's Thumb instructions (from 1997?)
http://infocenter.arm.com/help/index.js ... BCAAE.html
which is a 16-bit encoding for a RISCy instruction stream coupled with a 32-bit register file and address space.
"Thumb code is typically 65% of the size of ARM code, and provides 160% of the performance of ARM code when running from a 16-bit memory system"

I think the best method of having long addressing on a true 16-bit RISC would have an address registers take up 2 general purpose registers. Maybe have a0-a7 be low word registers, and b0-b7 be high word registers, and d0-d7 be the long registers made up from the A and B registers.

I like that!

I have this figured out. There would be 32 16-bit registers. 16 normal registers r0-r15, and 16 corresponding bank registers b0-b15. There would be 16 opcodes, with 2 operands and 8 addressing modes. The source operand can only use registers r0-r15, but the destination operand can use all 32. This adds up perfectly to 16 bits per instruction.

Is that like the "Write-Only" memory someone advertised as an April Fool's joke many years ago?

Mike

I agree with others here that a "16-bit RISC" is probably a contradiction, since an orthodox RISC implies a wide instruction word.

After the 68000 and 80386, to be considered "powerful" as a general purpose processor, a CPU pretty much had to be 32-bit. Still, there were many special-purpose 16-bit MCUs developed. MichaelM mentioned several. I have used the Hitachi/Renesas H8S (arguably a 32-bit machine), TI TMS320C2x (16-bit DSP), Motorola/Freescale 56F80x (16-bit DSP), Motorola/Freescale 68HC16, and TI MSP430. (TI's literature calls the 16-bit MSP430 "RISC", but really it's a re-imagined PDP-11. It has only 16 registers and is not a load/store architecture.)

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

Lol! The "store to memory" move instruction would have the source and destination operands reversed, so there would be a way to store it.

I can think of a few ways the 68000 could've been improved besides jumping to a true 32-bit design. It could have had the clock cycles per instruction reduced, and it could've easily used a PLA with only a few complex instructions being removed.

Hmm, I wonder if we could get it to run RSTS/E?

_________________
Bill

If someone had access to the complete source, I imagine that it would be a very straight-forward translation for re-assembly. The binaries would look quite different, but the source listings would look eerily similar ...

Mike

The biggest problem with the MSP430 in that application is that, as far as I know, none of the devices have an external bus. (On the other hand, TI makes MSP430s with up to 128 KB of FRAM....functionally similar to magnetic core.)

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

I've never had dealings with a PDP-11, but if it's like the MSP430 I expect it would be a pure pleasure!

The fact that PIC processors haven't been swept off the map by MSP430 is a puzzle to me. Both families offer dozens of variants, some extremely low-cost and low-power, with a wide range of on chip peripherals -- my last project used an MSP430 in a 14-pin DIP that cost $2 (single-unit pricing). But, based on what I've read about PIC, it's pretty awful to program unless you insulate yourself by using C. If it's your preference to use assembly language, the MSP430 is immeasurably nicer to program !

I guess that doesn't count for much nowadays.

T.I. isn't your only option. These folks have produced an MSP430 core written in Verilog. So if you wanted an external bus -- or any other wish-list functionality -- it should be doable. http://opencores.org/project,openmsp430

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That's Texas Instruments for you: brilliant engineering, inept marketing.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com