Faster DIP14 chip

[macboy]

The original post mentions a 8MIPS 8bit microcontroller, thus a 16MIPS one is surely faster in most (if not all) scenarios.

Oh, Right. PIC is not RISC, I forgot that. At 32MHz it is slower than 16MHz msp430. Anyway I do not agree suggesting just 2x faster MCU when it is not known - it will be enough for the task or not. Better learn some ARM chip where you have virtually unlimited performance upgrade path, if we ignore PDIP14 requirement for a moment. I doubt OP will live in the "DIP through-hole camp" for a long time..

PIC Micros are absolutely RISC. With only 35 instructions (midrange line) how could you call it anything else? It's also a Harvard architecture. But yes, it is exactly 4 clocks per instruction and no pipelining. That is a performance killer. Long ago a company called Ubicom (then Scenix, then Paralax) created a direct clone of a PIC called SX. Same instruction set, but pipelined, so 1 clock per instruction. And up to 100 MHz... In late 90's/early 2000's. But I digress.

TLDR: PIC is the very definition of RISC with 35 instructions.

[ogden]

PIC Micros are absolutely RISC. With only 35 instructions (midrange line) how could you call it anything else?

Crap? 

[edit] BTW msp430 is more "RISC" than pic because those have only 27 instructions

[rsjsouza]

No i "upgraded" my DSPIC also with max finetuning, wouldnt reccomend, getting weird noises on the audio, dont know why.

It seems you may need a microcontroller with DMA for the audio transfers - the CPU is freed. Not DIP, but the MSP430FR5959 has reasonable specs (TSSOP 38 pins is not hard to solder). An example on a bigger part is shown here (I think there may be others in their software package).

Or, if you want to ditch the DMA but have ADC/DAC and some signal conditioning in a (relatively) small package (LQFP 48 or TSSOP 38 pins are not hard to solder), check the MSP430FR2355.

[westfw]

Msp430 is unabashedly CISC, and I don’t think it does most of its instructions in a single cycle...  (well, perhaps not “unabashedly.”  The datasheet says “risc.”  But it has direct to memory operations with complex addressing modes!  Humph.


It’s sufficiently different from a PIC that speed comparisons would need to be really careful.
(“Single cycle REGISTER operations”)


(Edited w corrections)

[wnorcott]

Msp430 is unabashedly CISC, and I don’t think it does most of its instructions in a single cycle...  (well, perhaps not “unabashedly.”  The datasheet says “risc.”  But it has direct to memory operations with complex addressing modes!  Humph.


It’s sufficiently different from a PIC that speed comparisons would need to be really careful.
(“Single cycle REGISTER operations”)


(Edited w corrections)

MSP430 the 16-bit low end one is CISC because it has some complex instructions, but has only 27 instructions. Anything you see beyond 27 is an emulated instruction i.e. an assembler macro not a machine instruction.  That is certainly reduced instruction count. It uses the venerable Digital PDP-11 instruction set.  I agree with you it is hard to compare by looking at MIPS, MIPS does not tell the story

For a 16 bit architecture with reduced address space PDP-11/MSP430 is a fantastic instruction set very usable in assembly language.   The indirect addressing with increment is for managing tables in memory.    The PIC16 has the trappings of a RISC instruction set but none of the performance benefits because the hardware has no pipelining.  Neither does MSP430 but the TI chip does not need it.   You get much more done per instruction cycle in the MSP30 even though its instructions take differing number of clock cycles. Sure it is easy to calculate a PIC16, 32 MHz clock @ 4 clocks per instruction is 8 MIPS.   A MSP instruction is doing a whole lot more than a PIC instruction once you get past the easy load/store and set/clear bits instructions they both have.   Memory to memory with all the addressing modes makes some instructions quite powerful and useful. The C Programming Language echoes PDP-11 concepts in many aspects.   Many MSP430 instructions  do more take more than one clock cycle, yes, but all of the PIC instructions even the dumb ones ( and most of them are quite dumb ) take 4 cycles. 

[NorthGuy]

Msp430 is unabashedly CISC, and I don’t think it does most of its instructions in a single cycle...  (well, perhaps not “unabashedly.”  The datasheet says “risc.”  But it has direct to memory operations with complex addressing modes! 

When people sell something, they use buzz-words. PIC16 datasheets also say it's RISC (at least they used to).

RISC is a bad thing actually. RISC eliminates many useful commands to make pipelining easier. The price they pay is that you need more RISC instructions where you could get away with a single CISC instruction. This may (or may not) be of benefit if you have long pipelines and caches, but since small MCUs do not use (and do not need) long pipelines and caches, RISC would only increase the size of the program and decrease speed.

But RISC works well as a buzz-word.

[NorthGuy]

Memory to memory with all the addressing modes makes some instructions quite powerful and useful.

If instruction takes n slots to encode and executes in n cycles, it is practically the same as n instructions. How's that more powerful than n separate instructions?

[rsjsouza]

Memory to memory with all the addressing modes makes some instructions quite powerful and useful.

If instruction takes n slots to encode and executes in n cycles, it is practically the same as n instructions. How's that more powerful than n separate instructions?

It surely would have a comparable execution speed, but since the word "powerful" is a very wide umbrella, to me the readability and maintainability are worth the increased complexity in a single opcode. Obviously others will disagree.

RISC and CISC are in fact buzzwords that try to fit the complexities of every processing task in the world into only two buckets. I couldn't refrain from laughing when, many years ago, someone from a Si manufacturer was arguing with me how their DSP was a RISC machine, despite its assembly was massively complex.

[jhpadjustable]

RISC is a bad thing actually. RISC eliminates many useful commands to make pipelining easier. The price they pay is that you need more RISC instructions where you could get away with a single CISC instruction. This may (or may not) be of benefit if you have long pipelines and caches, but since small MCUs do not use (and do not need) long pipelines and caches, RISC would only increase the size of the program and decrease speed.

Processor cores do not exist as theoretical constructs in an isolated vacuum. Transistors are very cheap but not free. Are you suggesting that maximum clock rate, cycles per instruction (these first two taken together constituting throughput), die size, power consumption, etc. would remain exactly the same for a CISC processor as for a RISC processor?

I submit to the contrary, that the solution of offloading the grunt work of writing RISC instruction streams to a compiler has been so wildly successful on all counts that very few new "CISC" machines actually execute CISC opcodes natively anymore.

But RISC works well as a buzz-word.

Not that it can't be easily abused, but it has shifted a bit in meaning from the acronym's literal expansion.

It surely would have a comparable execution speed, but since the word "powerful" is a very wide umbrella, to me the readability and maintainability are worth the increased complexity in a single opcode. Obviously others will disagree.

And that's why I use C.

[NorthGuy]

RISC is a bad thing actually. RISC eliminates many useful commands to make pipelining easier. The price they pay is that you need more RISC instructions where you could get away with a single CISC instruction. This may (or may not) be of benefit if you have long pipelines and caches, but since small MCUs do not use (and do not need) long pipelines and caches, RISC would only increase the size of the program and decrease speed.

Processor cores do not exist as theoretical constructs in an isolated vacuum. Transistors are very cheap but not free. Are you suggesting that maximum clock rate, cycles per instruction (these first two taken together constituting throughput), die size, power consumption, etc. would remain exactly the same for a CISC processor as for a RISC processor?

I don't know why you think I suggested this, but, of course, on the high end encoding isn't very critical. CISC will give you better code density, RISC will give you better pipelining. At any rate, the CPU shuffles everything, changes execution order, makes its own decisions, so the command encoding is unlikely to change anything. By the time ARM gets to the level as x64, it'll be approximately the same in most respects.

The small MCUs are dramatically different - you need it real-time, optimized for the worst case (not for average throughput), you also want short interrupt latency. In addition the commands are fetched from the flash and there's a hard limit how fast this can be done. In such environment, CISC (big instructions and short pipelines) is much better than RISC (small instructions and long pipelines).

[ogden]

MSP430 seemingly fail to classify as RISC due to direct memory access instructions (thus no load/store architecture). PIC16 fail to classify as RISC because 1) have direct memory access instructions as well 2) do not meet "single instruction per cycle" RISC property. PIC also lacks multiple equal use registers. ARM cores supporting both 32-bit and 16-bit (Thumb) instructions also do not strictly qualify as RISC anymore In short: take each CPU as it is and do not waste time classifying them because lines became blurred over time.