PIC vs ARM assembler (no flamewar please)

David Brown <david@westcontrol.removethisbit.com> writes:
> Ulf Samuelsson wrote:
> > <ucadv07@gmail.com> skrev
> >> 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
> > 
> > The Series 32000 instruction set is way superior to anything mentioned so 
> > far.
> > The MC68000 instructon set is a murky wannabee in comparision.
> > 
> >     Try doing this in a single instruction on another architecture...
> > 
> >     pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2];
> > 
> >     maps to:
> > 
> >     movzbd     field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d]
> > 
> > 
> > Elegance is Everything!
> 
> Elegance is not quite everything - and that instruction is not elegant. 
>   I don't have a problem with a processor taking three or four 
> instructions to code an operation like that - on most cpus where you can 
> have complex addressing modes, the instructions take many clock cycles 
> and many instruction words, and could therefore be easily split into 
> several instructions.  I dislike architectures where you need several 
> instructions to do the simplest of things, like loading a register with 
> a constant, but I see no benefit in trying to do everything possible 
> within a single instruction.

The ARM design is unusual for a RISC in being three-address
and having conditional execution of nearly all its instruc-
tions.  This tends to waste 8 bits of every 32-bit instruc-
tion.  Surely, they could have found better uses for those
bits [and don't call me Shirley, "Airplane", ca. 1970].

"Everett M. Greene" <mojaveg@mojaveg.lsan.mdsg-pacwest.com> wrote in message 
news:20070217.7A4D700.B32B@mojaveg.lsan.mdsg-pacwest.com...
> David Brown <david@westcontrol.removethisbit.com> writes:

>>   I don't have a problem with a processor taking three or four
>> instructions to code an operation like that - on most cpus where you can
>> have complex addressing modes, the instructions take many clock cycles
>> and many instruction words, and could therefore be easily split into
>> several instructions.

Also these instructions could be scheduled out of a loop, or interleaved
with other instructions so that they execute faster than any complex
instruction.

>> I dislike architectures where you need several
>> instructions to do the simplest of things, like loading a register with
>> a constant, but I see no benefit in trying to do everything possible
>> within a single instruction.

Some of this can be alleviated with smart assemblers. There is no
hard and fast rule that says an assembler must produce a single
instruction for each mnemonic. Simple instruction selection and
expansion are commonly featured in assemblers.

> The ARM design is unusual for a RISC in being three-address
> and having conditional execution of nearly all its instruc-
> tions.  This tends to waste 8 bits of every 32-bit instruc-
> tion.  Surely, they could have found better uses for those
> bits [and don't call me Shirley, "Airplane", ca. 1970].

I'm curious what better use you have for those 8 bits? Another 8 bits
are "wasted" on the shifter for example, so you could save 16 bits
per instruction. The result is... Thumb.

But since 16-bit instructions do less (3 operands, shifts and conditional
execution are quite common), Thumb needs around 30% more
instructions to do the same amount of work as ARM.

Thumb-2 introduces the IT instruction which makes the following 1-4
instructions conditional. This form of conditional execution wastes fewer
bits overall eventhough it uses more bits per conditional instruction
(it is still smaller and faster than using branches of course).

Wilco 

On 14 Feb 2007 15:18:52 -0800, ucadv07@gmail.com wrote:
/cut

ARM has excellent IS. Right now I'm doing a AVR project in assembly and I
miss conditional instruction execution :'(

 Its about index registers and ease of

  branching and the creating Primatives

 that allow you to code , w/o an assembler .

  When i need to do low level , i dont

 need an ISa that forces me to push/pop

 every time i want to repeat the thread

 on new data as the mighty Pentium

 must do , for it has only 2 index registers !!

  The mo index registers , the less pushing

 and poping !

  Also there is a way to nix CALL/RETURN

 that i invented .

 Its simply indirect branch thru a register

 that you dedicate .  It allows you to do

 sub routines , but no need to RETURN .

 Instead , you go directly to the next

 subroutine .  FAST .

  ALL ARM cpu can do

 [ Load  PC (Rx) ]

  The mighty Pentium struggles , with

  JMP ( AX )  .

  ARM is the fastest ISA , and its so

 easy to use .

  Ill be giving a free O.S. for ARM .

 It is layered . 8 KB , 200KB , 5 MB .

 It uses NO text , its a true GUI .

> 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.

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

 Fit it to C ?

 The objective is to create a way to assemble

 code without text  ,

 but think you are at high level GUI  .

   You wont understand this , since you
 are C programmer .

 Thus the nuemonics dont matter ,

 but the regsiter set DOES matter .

  The SUCK pentium has SI , DI .

 The $2 ARM7 has 14 ,

 32bit Index Registers , to save you from

 pushing/poping  half your code away !!

  I can systems  program , faster than

 the worlds fastest C programmer ,

 using a new 100% structured , modular

 method , that uses NO text , but GUI .

  It is NO secret ,its just tossing , til it

 works .

 It uses a layer above the OpCodes that

 is so general , that each of these primatives

 totally conceils the ISA !  It decides which

 and how many Reg's to use for all low level

 applications . It has a user stack that goes

 away at run time . And worse ! Run time

 disables INT's !

  The kernel threads with a perfect , unargueable
  path , thru all threads , at all levels .

  ARM ........2 billion and growing ..

> Regardless, one instruction does not make or break any CPU.  In this
> case I think marketing broke this CPU so that the instruction set is
> moop.- Hide quoted text -

_________________________________

 I guess the Pentium has 600 ?

  and has only  SI , DI ......

   The worlds worst ISA and 18% wafer

 ylds ....INTEL !!


  ARM .....2 Billion , and growing....

  I dislike architectures where you need several
> instructions to do the simplest of things, like loading a register with
> a constant, but I see no benefit in trying to do everything possible
> within a single instruction.- Hide quoted text -
>
> - Show quoted text -

___________________________________

  Well you will love TI430 for loading constants
 You can put the constants in ur code as
 instructions , instead of storing them in
 Data Space .

 But seriously , its not constants , its about
 loading addresses .

   ----------------------
  Loading pointers indirectly .
   and  decreasing PUSH/POP .

  Long ago TI had its registers in RAM !
 ( 64 pin  "99000" ) , context switch was
 fast ! and you could have hundreds !


  But ARM is as good as it gets .
 It will devastate MicroChip , Zilog ,
 Atmel Intel , AMD , Micron , .......

  Hey ! ATMEL do ARM ...

  But it can't compete with Japan/Korea
  wafer fab ...


  Stay tuned for my free O.S. , fits in 8KB
 and it grows to 200K then 5 MB .

werty wrote:

>   I dislike architectures where you need several
> 
>>instructions to do the simplest of things, like loading a register with
>>a constant, but I see no benefit in trying to do everything possible
>>within a single instruction.- Hide quoted text -
>>
>>- Show quoted text -
> 
> 
> ___________________________________
> 
>   Well you will love TI430 for loading constants
>  You can put the constants in ur code as
>  instructions , instead of storing them in
>  Data Space .
> 
>  But seriously , its not constants , its about
>  loading addresses .
> 
>    ----------------------
>   Loading pointers indirectly .
>    and  decreasing PUSH/POP .
> 
>   Long ago TI had its registers in RAM !
>  ( 64 pin  "99000" ) , context switch was
>  fast ! and you could have hundreds !

  Zilog have this in their current uC.
It's also something Atmel could/should have done with their AVR,
and it is a common shortcoming of RISC devices in Microcontrollers.
RISC cores are historically pitched by die area, and memory is 'NIH',
and so we see pointer/stack thrashing.
  -jg

>>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.
---------
> Agreed.

> What counts are support by the manufacturer, its peripherals and I/O

_______________________________________

 Its terrible to hunt for jobs like that !

  I simply choose the one that is the

 best for 'use" , not for making money .

  Do you know what use is ?

  It means , i want lots of RAM and an

 instruction set that is fast to create s/w .

  Because stuff is on batteries , it must

 not make heat ,   ARM does same job

 in half the watts , as PIC , 8051 , and

 all of the Philips super-8051's and

 Zilogs and Rabbits .....

 It is so good , its destroying market

 share of all others . It has sold

 2 billion mcu's .  No one is close .

  So if you are confused , about which

 mcu to program , you will pay a much

 higher price for that mcu , and thus there

 will be no jobs ,programming it in the

 future .

   Thats competition , it kills the 2nd place

 finisher .  In 3 mo years , only ARM

 will exist , and it will come with a 32KB

 opsys and cost $2 .  Anything you hook

 to it will run , because all the "protocols"

 will be simpler and "open" .


  Its progress .....

On 18 Feb 2007 17:37:08 -0800, "werty" <werty@swissinfo.org> wrote:

>>>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.
>---------
>> Agreed.
>
>> What counts are support by the manufacturer, its peripherals and I/O
>
>_______________________________________
>
> Its terrible to hunt for jobs like that !

I actually enjoy learning from challenge.  I wrote, "I like them all
and enjoy working with them."  I had two points -- one is that the
instruction set simply isn't on my radar when selecting a part and two
is that "I enjoy getting into the 'mindset' of most any instruction
set design."

I don't find any of that terrible, at all.

But to each their own, sir.

>  I simply choose the one that is the
> best for 'use" , not for making money .

Best for use is a complex set of tradeoffs in my world.  It's not a
simple decision.  Best for money I didn't even discuss.  That is a
strawman you bring up.

>  Do you know what use is ?

If I couldn't, I'd find some other work.

>  It means , i want lots of RAM and an
> instruction set that is fast to create s/w .

Great.  If that works for you, more power to you.

>  Because stuff is on batteries ,

Ah.  Well, I've no business telling you your business, but you have
none telling me mine, either.  I also care about battery use.  But in
my case, that often argues _against_ excessive RAM.  Only you know for
sure what you mean by "fast to create s/w," since you didn't describe
that in detail here.  So I'll just leave that comment alone.

>it must
> not make heat ,

ARM has low power as a goal, of course, but ARM is NOT the best
processor for all uses.  Not even close, yet.

>ARM does same job
> in half the watts , as PIC , 8051 , and
> all of the Philips super-8051's and
> Zilogs and Rabbits .....

It almost always comes in huge packaging, often has an external memory
interface (which I rarely ever need), sometimes requires a separate
supply for core and for I/O, etc.  Not to mention that it is NOT the
lower power selection.  MSP430 comes to mind.

Your position seems to be the very extreme one of believing you know
everything about everyone else's problems and that therefore you know
a panacea to all problems.  The problem with that is that everything
is a matter of tradeoffs.  And the ARM is not the best combination of
tradeoffs for all problems.  And you don't know everything.

It's as simple as that.

That said, I don't use Rabbits or Zilogs, either.  They just haven't
been what I needed.

> It is so good , its destroying market
> share of all others . It has sold
> 2 billion mcu's .  No one is close .

I like ARMs and I am very glad they exist in so much variety.  They
still aren't a panacea.

>  So if you are confused , about which
> mcu to program , you will pay a much
> higher price for that mcu , and thus there
> will be no jobs ,programming it in the
> future .

I'm not confused.  But you seem to be, imagining that you know
everything about everything.  I try to know my problems well and I
just have to disagree with your premise that the ARM would always be a
viable option in every case, let alone the better choice.

>   Thats competition , it kills the 2nd place
> finisher .  In 3 mo years , only ARM
> will exist , and it will come with a 32KB
> opsys and cost $2 .  Anything you hook
> to it will run , because all the "protocols"
> will be simpler and "open" .

Glad to hear it.

Of course, I don't believe you.

Jon