Forums

PIC vs ARM assembler (no flamewar please)

Started by Unknown February 14, 2007
Had a discussion with a _hardware_ guy (as in transistors and OP-amps)
about "powerful" micros.

He his a PIC guy and claimed that PIC have a very nice instruction set
and is a pleasure to work with in assembly. He also mentioned the he
would rather use a dsPIC instead of an ARM7 because ARM7 is very hard
to program and has a confusing assembly (we never talked application,
so I assume he meant this holds regardless of application). He also
said that another major advantage of dsPIC is that its a PIC, hence
the know-how and toolchain advantage...

Completely shocked, I told him that my experience was the exact
opposite, and I really enjoy ARM assembler (well, maybe not enjoy...).
Anyway, after that, the discussion turned into a flamewar...


So what do you say? Maybe I have been wrong all the time?

What do you guys think about the instruction set and architecture,
provided that you were forced to code in assembly and we ignored the
fact that these is more of an apples vs pink-flying-elephants
comparison...

(you can also include your background and your other favorite micros
such as AVR and MSP4xx, but_ please_ don't flame. and you must REALLY
HAVE WORKED with all of them, no gusses please :)  )

((yes, I REALLY do want your answers. Because I suspect the answer
will differ very much dependent on your background, and experience and
your application, and I think that information would benefit this
little community))

-shocked

ucadv07@gmail.com wrote:

> Had a discussion with a _hardware_ guy (as in transistors and OP-amps) > about "powerful" micros. > > He his a PIC guy and claimed that PIC have a very nice instruction set > and is a pleasure to work with in assembly. He also mentioned the he > would rather use a dsPIC instead of an ARM7 because ARM7 is very hard > to program and has a confusing assembly (we never talked application, > so I assume he meant this holds regardless of application). He also > said that another major advantage of dsPIC is that its a PIC, hence > the know-how and toolchain advantage... > > Completely shocked, I told him that my experience was the exact > opposite, and I really enjoy ARM assembler (well, maybe not enjoy...). > Anyway, after that, the discussion turned into a flamewar... > > > So what do you say? Maybe I have been wrong all the time? > > What do you guys think about the instruction set and architecture, > provided that you were forced to code in assembly and we ignored the > fact that these is more of an apples vs pink-flying-elephants > comparison... > > (you can also include your background and your other favorite micros > such as AVR and MSP4xx, but_ please_ don't flame. and you must REALLY > HAVE WORKED with all of them, no gusses please :) ) > > ((yes, I REALLY do want your answers. Because I suspect the answer > will differ very much dependent on your background, and experience and > your application, and I think that information would benefit this > little community)) > > -shocked >
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
On 14 Feb 2007 15:18:52 -0800, ucadv07@gmail.com wrote:

<snip>

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.
ucadv07@gmail.com wrote:
> He his a PIC guy and claimed that PIC have a very nice instruction set > and is a pleasure to work with in assembly. He also mentioned the he > would rather use a dsPIC instead of an ARM7 because ARM7 is very hard > to program and has a confusing assembly (we never talked application, > so I assume he meant this holds regardless of application). He also > said that another major advantage of dsPIC is that its a PIC, hence > the know-how and toolchain advantage...
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"
"Pete Fenelon" <pete@fenelon.com> wrote in message 
news:smpda4-tll2.ln1@stratos.fenelon.com...
> ucadv07@gmail.com wrote: >> He his a PIC guy and claimed that PIC have a very nice instruction >> set >> and is a pleasure to work with in assembly. He also mentioned the he >> would rather use a dsPIC instead of an ARM7 because ARM7 is very hard >> to program and has a confusing assembly (we never talked application, >> so I assume he meant this holds regardless of application). He also >> said that another major advantage of dsPIC is that its a PIC, hence >> the know-how and toolchain advantage... > > 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.
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.
> 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.
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.
> 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 ;)
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 ;-)
ucadv07@gmail.com wrote:
> Had a discussion with a _hardware_ guy (as in transistors and OP-amps) > about "powerful" micros. > > He his a PIC guy and claimed that PIC have a very nice instruction set > and is a pleasure to work with in assembly. He also mentioned the he
There are those that think being handcuffed to a bed and whipped is a "pleasure" - no accounting for taste.
> would rather use a dsPIC instead of an ARM7 because ARM7 is very hard
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.
Tom Lucas <news@remove_auto_this_flame_to_reply.clara.co.uk> wrote:
>> 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. > > Pity me - I'm currently converting Z80 to x86 in order to interface with > a small PIC!
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.
> > 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 ;-)
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"
David Brown <david@westcontrol.removethisbit.com> wrote:
> to read data from an array. The msp430 is about as good as it gets for > 16-bit cpus, for the same reasons.
Essentially PDP-11 rethought ;)
> 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 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"
> 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.
I would second that, perhaps including the CPU32 addressing modes (all 68020 modes except the memory indirect ones).
> The PPC takes a lot of getting used to, and > suffers from the problems of any pure RISC architecture.
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 http://tgi-sci.com/vpaex/ ) ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Feb 15, 1:40 pm, David Brown <d...@westcontrol.removethisbit.com> wrote:
> ucad...@gmail.com wrote: > > Had a discussion with a _hardware_ guy (as in transistors and OP-amps) > > about "powerful" micros. > > > He his a PIC guy and claimed that PIC have a very nice instruction set > > and is a pleasure to work with in assembly. He also mentioned the he > > There are those that think being handcuffed to a bed and whipped is a > "pleasure" - no accounting for taste. > > > would rather use a dsPIC instead of an ARM7 because ARM7 is very hard > > 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.
ucadv07@gmail.com wrote:
>Had a discussion with a _hardware_ guy (as in transistors and OP-amps) >about "powerful" micros. > >He his a PIC guy and claimed that PIC have a very nice instruction set >and is a pleasure to work with in assembly. He also mentioned the he >would rather use a dsPIC instead of an ARM7 because ARM7 is very hard >to program and has a confusing assembly (we never talked application, >so I assume he meant this holds regardless of application). He also >said that another major advantage of dsPIC is that its a PIC, hence >the know-how and toolchain advantage... > >Completely shocked, I told him that my experience was the exact >opposite, and I really enjoy ARM assembler (well, maybe not enjoy...). >Anyway, after that, the discussion turned into a flamewar... > >So what do you say? Maybe I have been wrong all the time? > >What do you guys think about the instruction set and architecture, >provided that you were forced to code in assembly and we ignored the >fact that these is more of an apples vs pink-flying-elephants >comparison...
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 ]