Searching \ for '[PIC]: How efficient Asm vs PB etc.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=asm
Search entire site for: 'How efficient Asm vs PB etc.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: How efficient Asm vs PB etc.'
2002\09\26@151010 by Walter Banks

picon face
The C vs ASM arguments.

- C can be as tight as asm
- Good asm will beat bad C
- Good C programmers will beat bad asm programmers
- C optimizers will not change bubble sorts into quick sorts but
  they can make a very good bubble sort.
- Computers are accounting machines, local variables and goto/call
  and paging are better handled by compilers than programmers in
  the middle of debugging an application.
- C compilers know about silicon bugs and can program around them
- C is easier to move between processors (or same propcessor
  different memory map)
- C compilers remember all the programming "tricks" taught to them
  and use them when appropriate
- There is no magic good C compilers take a lot of work to write
- Embedded C still requires the programmer to understand the
  application.
- Floating point is rare in embedded C applications.


email me your additions and we post the list to Byte Craft's WEB
site.

Walter..

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\26@173911 by Bill Westfield

face picon face
>    The C vs ASM arguments.
>
>    - C can be as tight as asm
>    - Good asm will beat bad C
>    - Good C programmers will beat bad asm programmers
>    - C optimizers will not change bubble sorts into quick sorts but
>       they can make a very good bubble sort.
>    - Computers are accounting machines, local variables and goto/call
>       and paging are better handled by compilers than programmers in
>       the middle of debugging an application.
>    - C compilers know about silicon bugs and can program around them

I think this is a dangerous assumption.  C compilers CAN know about silicon
bugs, but they don't necessarilly do so.  (And how up-to-date is the
compiler you're using with respect to the chips you're using?)  The flip
side of this is that a compiler can introduce a whole new layer of bugs into
the software development process.  At a certain level of company complexity,
tool (compiler, etc) management becomes a signficant issue...


>    - C is easier to move between processors (or same propcessor
>       different memory map)

Amen to that!


>    - C compilers remember all the programming "tricks" taught to them
>       and use them when appropriate
>    - There is no magic good C compilers take a lot of work to write
>    - Embedded C still requires the programmer to understand the
>       application.

"Good programming requires that the programmer understand the application.
Good embedded programming generally requires that the programmer understand
the hardware archiectures involved as well.  Regardless of language."

>    - Floating point is rare in embedded C applications.
>    email me your additions and we post the list to Byte Craft's WEB site.

How about "You can easilly write assembler style programs in C, but writing
C style programs in assembler is a lot harder."

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\26@181233 by Russell McMahon

face
flavicon
face
And .... :-)

It is POSSIBLE in very special circumstance for a compiler to produce code
which is so efficient that, if an assembler programmer ever produced the
same code,  you should immediately fire them for writing it. eg a relative
jump that jumps into the middle of a multibyte instuction that uses PART of
that instruction as a different instruction. I have seen that done (code was
probably written in assembler). Such techniques are entirely acceptable for
a machine based system as the assumptions and circumstances which allow them
to be made are tracked at compile time. For a human assembler to produce the
same result would require a level of documentation which nobody would ever
write and nobody else would ever read or understand and the conditional
assembly required to support it would be "interesting".

From a hypothetical machine & highly contrived program

....

26 02            bne    *+2                    ; branch if not equal to zero
4c                 enable interupts (say)
b6 86 04       ld        fred                   ; load acc from location
$8604

Here IF 86 04 is an immediate load of 04 to accumulator, then IF the
original bne fails the accumulator will load from fred (at $8604) and
interupts will be enabled, while if the bne branches the accumulator will
contain 04 and and interupts will not be enabled.

Changing the location of fred will cause this code to fail.
A compiler, albeit a VERY clever one, could do this.
A person never should.


       RM

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\26@210837 by Jinx

face picon face
> eg a relative jump that jumps into the middle of a multibyte instuction
> that uses PART of that instruction as a different instruction. I have
> seen that done (code was probably written in assembler)

It's quite common to use this technique in 65xx code with the non-
destructive BIT test instruction, for example when loading the
accumulator for tables or strings etc

BIT = 2C, LDA = A9

BIT $00A9   2C A9 00
BIT $01A9   2C A9 01
BIT $02A9   2C A9 02

etc

Using a computed GOTO or branch it's easy to jump to an A9 and so
perform an LDA, (which is then followed by irrelevant BIT instructions,
then you hit the exit to the function routine), eg

LDA #01
BIT $02A9
JMP xxxxx      ; JUMP to xxxx with 01 in A

I don't believe this is possible with PICs though

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\27@033255 by Wouter van Ooijen

face picon face
My summary:

A good assembler programmer will do better than an equally good C
programmer (on code size, code speed, etc), provided that the assambler
programmer has enough time. When was the last time you were given enough
time?

If you can still remember the last time you were given enough time to
write a good assembler application you are probably working in a field
where units produced is measure in k or M, not in single units.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\09\27@034953 by Bill Westfield

face picon face
Heh.

"I was taught assembeler in my second year at school.
It's kind of like construction work, with a toothpick for a tool."

http://artists.mp3s.com/artist_song/234/234762.html

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\09\27@042053 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,
Wouter van Ooijen wrote:
>My summary:
>
>A good assembler programmer will do better than an equally good C
>programmer (on code size, code speed, etc), provided that the assambler
>programmer has enough time. When was the last time you were given
enough
>time?
>
>If you can still remember the last time you were given enough time to
>write a good assembler application you are probably working in a field
>where units produced is measure in k or M, not in single units.
>
All good points, and I agree although I am that person who get's
'enough' time
(or perhaps write fast :) ) to actually code entirely in asm.
And yes most unit is in the range 100's to 1k's /year. So that will bias
my
opinion.
As I said I really like c, but the way to write effective code for the
pic's
in c does not suit my particular programming style The pic c-code (to be
effective) looks like an halfbaked mess with assembler bit's sprinkled
in for
fun. But perhaps thats me not understanding the particular tools.

I do not want this the become an c vs. asm vs. whatever argument, all
languages have
thier uses. That's why they exists in the first place. Likewise most
programers
have thier own 'style' of programming, some suits an particular language
better than others.

Summary:

C       - is best for X
Asm     - is best for Y
PB      - is best for Z
an mix is best for  {

:)

/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\09\27@043754 by Jinx

face picon face
> If you can still remember the last time you were given enough time
> to write a good assembler application you are probably working in
> a field where units produced is measure in k or M, not in single units.
>
> Wouter van Ooijen

Thanks for making me feel better about rush jobs Wouter ;-)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\09\27@050350 by Wouter van Ooijen

face picon face
> I do not want this the become an c vs. asm vs. whatever argument, all
> languages have thier uses. That's why they exists in the first place.

And the same line of reasoning applies to Operating Systems,
Microcontrollers, Project (Coding) Standards, Programmers, Developemnt
Systems and what not.

Bottom line: before jumping a conclusion, first find out what the
circumstances are. When you have those clear most of a consultancy job
is done...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...