PIC vs ARM assembler (no flamewar please)

I certainly found the PowerPC instruction set very weird when I started with it. AFAIK the ARM is similar, and I could see how one may interpret "damned unfamiliar" as "sucks".

I don't like those 35 easy-to-use instructions, because they're backed by an architecture that I find very limiting -- but I have to admit that I'm a confirmed C programmer, and my biggest reason for not liking the PIC is because it is a very bad fit to C.

My understanding of the dsPIC, however, is that while it is a PIC in name the instruction set and architecture doesn't bear much resemblance to the 8-bit processors.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

If you have worked with an instructions set for some time, and you know it well, then it is going to be easy. However, this does not make it better. Chances are the first instuction set you learn will be the best, until you actually learn the next. After learning half a dozen, they are all the same, they are instruction sets. Each has its good, and each has its bad.

dsPIC is barely a PIC. It's a very nice instruction set to write for in many respects.

ARM is one of the most orthogonal instruction sets I've ever encountered. Stuff "just works" like you think it will.

FWIW, the instruction sets I hate working with are pre-dsPIC PICs, Z80,

8051, x86. PICs mainly because everything is such a shag to do, the others because they're so non-orthogonal.

The ones I find most logical are 680x0, dsPIC, ARM, MIPS, H8, SH2, Alpha, SPARC. Historically the PDP-8 and PDP-11 have a lot of elegance to them, I wote my first PDP-8 simulator over 20 years ago ;)

I quite like baby micros like 68HC08/11/12 - then again I grew up on

6502 and they're really cousins ;)

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

I guess it is pretty close to the "ideal" processors that get described in computer science classes. Noone mentions nasty ass segments or Harvard architectures in these classes.

Pity me - I'm currently converting Z80 to x86 in order to interface with a small PIC! Actually I rather enjoy programming assembly for the PIC - it is a good logical instruction set and I find the skip-one if set/clear tests very useful. However, I'm not a fan of trying to do it in C but then I don't normally use them in applications too big to attempt in assembly. I do wish they could have kept all the registers in the same bank though.

Everyone of a certain age* seems to go gooey with memories of the PDPs. I shall have to have a play with a simulator one day.

• Not to cast nastertiums on anyone's age Pete but one tends to generalise ;-)

There are those that think being handcuffed to a bed and whipped is a "pleasure" - no accounting for taste.

The dsPIC core is totally unrelated to the PIC proper, and is apparently bearable to work with at the assembly level.

The ARM instruction set is not particularly nice for assembler programming. It is hard to write good, tight code unless you are particularly dedicated, and even then it takes a lot of thinking about. The conditional execution instructions and orthogonal architecture are well suited to compiler-generated code.

From my own experience, the 68k (i.e., ColdFire) ISA is the nicest I have used. It has the right mixture between a reasonable number of registers (enough to be useful, but few enough that you can keep track of them in your head), fast orthogonal instructions, and convenient addressing modes - you don't have to use half a dozen instructions just to read data from an array. The msp430 is about as good as it gets for

16-bit cpus, for the same reasons. The AVR is not bad for an eight-bitter, although they made a couple of terrible design decisions regarding C compatibility. The PPC takes a lot of getting used to, and suffers from the problems of any pure RISC architecture. It also makes it clear that the acronym parses as (RI)SC, not R(IS)C.

I'll do most things for money, then again I work to live and not vice-versa -- I've done PIC, Z80 and x86 for filthy lucre in the past.

Well I'm still (just) on the "life's not begun yet" side of 40. ;)

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

Essentially PDP-11 rethought ;)

I swear one compiler vendor was out just to annoy me. 95% of the generated code seemed to be ADDIS and RLWINM, to the point that I think they were just doing it to be clever ;)

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

I would second that, perhaps including the CPU32 addressing modes (all

68020 modes except the memory indirect ones).

Any RISC assembly language I know of is too inconvenient to be used alone. This is why I made up VPA, which includes the CPU32 instruction set (and generates PPC native code). But things can get better than in the 68k assembly. For example, consider move.w to some register. It affects only the lower word; pretty often we have to do a clr first so we have a word operand zero extended, or do a sign extend after the move to have it sign extended. So except having a move.w having a movez.w and movex.w, which do the above in one go, is pretty convenient, I seem to use these no less than the plain "move" nowadays. More than that, a movez.w- or movex.w- translates to a single PPC opcode (lhz or lha etc.). There are more of the kind, when I have to do plain CPU32 now I feel it, well, not like a pain, but I certainly do miss the fullblown VPA. And having some more registers at your disposal is also nice, although not such a huge difference, like you mentioned, 16 is about right for the way our brains work (but having soe more than 16 registers on the target CPU is crucial, e.g. I use r4-r7 to emulate the addressing modes etc). d0-a7 are r8-r23).

Dimiter

(I have posted before some references to my VPA, still at

)

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Actually is more like old-oil-painting-of-an-apple vs pink-flying-mutant-ninja-elephants-from-the-sun's-chromosphere ...

I studied the early / low end CPUs in the PIC family years ago, and I disliked the architecture so much that I have never looked back, even that I know that current models are very different. I would consider them for cost reasons when applicable. I do like the AVR architecture, would like it more if it wasn't Harvard. (Never used it in a product.)

Back to the assembly question: I do not work in assembler, period. The embedded projects I have been involved with the past few years were based on medium to high end x86 / PowerPC / ARM9 / C2000 / C6000 CPUs, all running mostly C/C++ code. I am not claiming this is the way it should be in any conceivable situation, but I believe it reflects what embedded development is for many, (if not most,) people today.

The few lines of assembly were in initialization code after power up, a few inline statements to enable/disable interrupts, etc. I do not expect this to change in the future. Being "forced to code in assembly" to me means having to write a few more code snippets like those. For this type of usage any assembler is tolerable.

The instruction set of CPUs like the PowerPC and ARM is designed to support efficient compilation of high level languages, it should come as no surprise that hand-coding in assembler is not easy or straightforward.

Roberto Waltman

[ Please reply to the group, return address is invalid ]

Not as an improvement, in my opinion.

Jon

Agreed.

What counts are support by the manufacturer, its peripherals and I/O specs, number of I/O, its price, its power consumption, its voltage range, its general performance, good brown out detection if present, clocking options, packaging and size, software tools, etc. In other words, the instruction sets peculiarities are way down on my list. In fact, I usually will only glance at them in making a decision, just to be sure there is good documentation on it and that the ALU and memory transfer speeds are roughly in the right ballpark -- but not the instruction set's esthetic appeal. I pretty much like them all and feel comfortable with anything from a 2- or 4- bit wide bit-slice,

46-bit 2k word mercury delay line contraption, on up to some 1024-bit VLIW. I like them all and enjoy working with them.

So I agree and enjoy most instruction sets, taking them each on their own terms. The PIC12/PIC16 are beautiful in their way because they expose ALU design in clear fashion -- the bare bones. And that has its appeal. The PDP11 is very attractive from its orthogonal and expansive support for addressing modes and its well tailored instructions. I enjoy getting into the 'mindset' of most any instruction set design.

Jon

The MSP430 instruction set isn't as regular as the PDP-11: the MSP430 gave up a couple important addressing modes presumably as a tradeoff for more registers.

I think they should have tried harder to include destination addressing modes like register-indirect and register-indrect with autoincrement. Not having register indrecect (possibly with auto incrment) available for the destination makes a lot of common C-language-pointer stuff more expensive that it ought to be.

Still, ISA-wise, the MSP430 is miles ahead of things like the

8051, 8086, PIC, AVR, and the like.

--
Grant Edwards                   grante             Yow!  .. my NOSE is NUMB!
                                  at               
                               visi.com

Much of startup and special instructions can nowadays be done in C using intrinsics, so there is rarely an excuse for using assembler.

Yes. Compilers, especially in the ARM world, are nowadays so good that very few assembly programmers can beat them. It's really only useful when you need to get that last 10% of performance in those rare loops where the loop optimizer doesn't do well enough and changing the source code or using intrinsics doesn't help either.

Interestingly ARM was originally designed to be a good *assembler* target and in the first few years everything, including OSes, was written in pure assembler. Some of the features that make ARM assembler powerful make writing compilers more difficult. On balance it is simple enough that good compilers can be written and yet complex enough that you need few instructions to do a particular job (unlike other RISCs).

Wilco

I remember that thread :-)

The msp430 ISA is not perfect - some changes from the PDP-11 were improvements, some were clear tradeoffs for other reasons (smaller, faster or lower power design), and some changes were for the worse. But still, it is the nicest ISA available in a small, low power microcontroller at the moment.

MSP430 also has the 'advantage' that what is included is the stuff that a C compiler tends to generate ;P

It's a very nice 'baby micro'. If you want something even more PDP-11ish there's always the H8.

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

I like the H8.

Jon

I hold my position that the resulting design shows less experience than it should have; from several different perspectives.

Jon

It's a nice family. I did quite a lot of work on H8S, H8/Tiny (which I particularly like) and H8/300 a few years back and apart from Hitachi^H^H^H^H^H^H^H Renesas' tendency to move peripherals and IPRs around incompatibly they "just work" pretty well - good core with reasonable code density and nice interrupt handling, good peripherals, excellent timers, reasonable software tools. Very few big 'gotchas' when working with them.

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

Looking at Renesas's recent advertising they seem to be pushing the R8C processors more than their H8 range - so not sure what will happen to H8. I think I read somewhere that essentially they will combine their two ranges to just one.