PIC vs ARM assembler (no flamewar please)

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 ]