avr: asm vs. c - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: avr: asm vs. c

[...]
Quoted text here. Click to load it

Kind of hard to argue.  Not very profound...

Quoted text here. Click to load it

Non sequitur?  There are indeed prominent compilers that offer float
at a much lower price (at least in terms of code space).  But float is
very often the wrong solution.  Especially if you're talking about
"scaling."

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: avr: asm vs. c
Quoted text here. Click to load it

There is nothing else supported in C. There is such a strong tendency
to stick to the standard that nothing else is thinkable.
I tend to use my own implementation of fractional, in ASM of course.
Another datatype I miss in C is 'non-wrapping integer'. Easily
doable in ASM, but unthinkable in C.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Re: avr: asm vs. c
42Bastian Schick writes:
[snip]
Quoted text here. Click to load it

Couldn't agree more.

Quoted text here. Click to load it

Couldn't DISagree more.  A respectable ASM programmer can
produce better code than most compilers.  A 4:1 improvement
is often easy enough to attain.

Re: avr: asm vs. c
Quoted text here. Click to load it

This depends on platforms.... Some platforms have some extremely good
compilers where the first comment holds true. They also have some
downright appalling compilers where the second comment holds.

There are probably some architectures where there are no really good C
compilers and the second comment will be proved and the first comment
will fail.

No, I am not going to make any suggestions as to which is in which
category :-)


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: avr: asm vs. c
Quoted text here. Click to load it

You did notice that I wasn't very specific either.

I do know of one specific compiler that is reasonably good but
insists on converting all intermediate computational values to
int precision IAW the C standard.  This leads to /much/
extraneous code as when char values are extended to 32 bits and
then truncated to a byte value on assignment.

I once asked PJPlauger to cite one example of a C compiler that
generates better-than-ASM-programmer code.  He didn't reply.

Re: avr: asm vs. c
Quoted text here. Click to load it

It depends on project size...
Given big enough project most ASM programmers won't even finish in time :-)

And while waiting for the ASM programmer you can:
* Global optimize the code - all code treated as in line if it helps.
* Use profile optimized compilation.
* Find out your hotspots with profiling - and optimize those (in ASM).
* Go fishing :-)

But suppose the ASM programmer uses strict call conventions and other
programming rules not to end up in a mess - then he looses some of the 4:1
advantage.

IMHO

Have anyone seen hand assembled SPEC results?
(They are close since most uses some strange compilation options...)

/RogerL

--
Roger Larsson
Skellefteċ
We've slightly trimmed the long signature. Click to see the full one.
Re: avr: asm vs. c
Quoted text here. Click to load it

Better at what? Generating assembly code from high level statements? Generating
object code for user programs that occupy fewer bytes? Generating object code
for user programs that execute in fewer cycles? What about library routines?
Gonna redo all those by hand too?

Anyway, compiler wins in the 1st case (speed). You just cant type as fast as
the compiler. In the second case (size), you might save a few bytes by hand
eliminating some extra register loads and saves, but why? The days of counting
bytes in a 4k rom are fading fast. In the 3rd case, (speed), if you are only a
few percent too slow, I'd say optimizing the algorithm in c will squeeze out a
few percent sppedup as well as hand assembly optimization. If you are off by
50% or 100% too slow, you picked the wrong speed processor up front and now you
are professionally embarrassed. If you are lucky, there is a faster processor
that will run the c program (oops... your program was in assembler for the old
slow processor... too bad)


Re: avr: asm vs. c

Quoted text here. Click to load it

Most of them are !

Quoted text here. Click to load it

No point against.

Quoted text here. Click to load it

We have a C source as reference for our RTOS, but the real kernel is
handcoded (not translated !) in assembly.
Depending on the CPU the assembly code is 30% to 10% shorter !

Quoted text here. Click to load it

I hear this argument now for 4 years, and still often size matters.
Of course, there are more and more embedded systems with megabytes of
RAM and ROM/Flash.

Quoted text here. Click to load it
Agree, first check the algorithm, even before you start with funny C
optimizing tricks.

But having the best (for a given time T) in C, than having a good
assembly programmer squeezes another 20% out of it !

Quoted text here. Click to load it

If the new CPU does not have the same assembly, than it most likely
has also not the same electrical parameters and your lost anyway.

But, to make it clear, I would not write an 100k line C/C++ program in
assembly. I am crazy but not that crazy :-)

It is like always, you have to counter balance effort against what you
gain.

(Hehe, re-writing winXXXX or linux in assembly would allow you to run
it nicely on a 486 I guess :-)

---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: asm vs. c



Quoted text here. Click to load it

You want C for sure.
There is a free C compiler on www.avrfreaks.net.
You will also need the AVR Studio.

There will be AVR Seminars in Denmark early November, if you are interested.
http://www.atmel.com/seminar/Mcu/default.asp
Attend the seminar, and get a development board.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
We've slightly trimmed the long signature. Click to see the full one.
Re: asm vs. c
Quoted text here. Click to load it

Would love to attend.  Free transportation from U.S.?

Site Timeline