Assembly V.s. Compiler

[Paul Burridge]

W.I.N.D.O.W.S : Will Install Needless Data On Whole System.

If only it was as harmless as that.

 

[Chuck Simmons]

Why is assembly preferred over C++, say, in time critical applications?
Thanx
Tanty

A project I am on is studying this right now. C++ is not at issue in our
case but C is possible.

My chip has 3 AVRs in it and the other team has 1 AVR and an ARM in
their chip. C is already used for the ARM but the AVR software is all
assembler. My use of assembler for my 3 AVRs originated from my doing a
feasibility study for the 3 AVR architecture before joining the project
as a consultant. I could not find a free AVR C compiler at the time. At
the time (and still) I was looking at a 50kHz interrupt rate for all
three AVRs with AVR0 handling interrpts from 6 or more sources. C seemed
a stretch unless functions were never used and context switch was
watched closely.

The thinking now is that the other team can benefit from C because their
interrupt rate for their AVR is much lower than mine. All of the AVRs
have strange data memory maps but the good linkers can handle that. For
my part, AVR1 and AVR2 run substantially the same code which has not
changed in more than two years. There would seem to be no benefit given
the investment and the fact the code does not change.

My AVR0 is different. The code is complex (a mess) and hard to maintain.
I'm looking at repartitioning and using C for some blocks of code.
Linkers understand this so I have this as an attractive option. The fast
interrupt stuff might well stay in assembler but the slower interrupts
might work well in C. The other group is helping me with the evaluation.

Chuck

 

[Bill Sloman]

Because C/C++ (or any such language even though C is the least
offender in this regard) is necessarily bloated for the sake of the
programmer's convenience. That convenience saves the programmer time
at the cost of processor-time. With Assembler, OTOH, you can taylor
your needs precisely to the intended application. User-friendly it
ain't; but it's certainly lean and mean.
But *real* programmers program in machine code...

Nah. Real programmers program in whatever gets the job done right.

The trade-off is mostly driven by the rule that a programmer makes one
mistake per thirty lines of code.

Compiled languages require many fewer lines of code (before compilation)
than does assembler to do the same job.

For processor that are designed to run compiled code efficiently, compiled
code runs almost as fast as assembler code, and compiles to much the same
number of commands.

Programmers who understand what their compiled code is going to look like
after compilation do tend to produce faster and more compact compiled code,
and the main difference in speed between assembled program and compiled
programs is that anybody who can and does write in assembler knows exactly
what the processor is doing.

Writing a loop in assembler really does give you complete control over what
the processor is doing, but it is rarely cost-effective, mainly because you
have to spend a lot more time finding the bugs.

 

[Rich Grise]

ISTR the heap memory handling ability of C is pretty crap though,
isn't it, Kev?

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit
patch
to an eight bit operating system originally coded for a
four bit
microprocessor and produced by a two bit company."

That doesn't care about its customers one bit.

 

[Wouter van Ooijen]

No, it is his EE homework that he doesn't have the clue to research by

himself.

In that case my critique applies to who wrote the question


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Joel Kolstad]

I don't see why you can't just be expected to write a destructor in much
the same way as you write a constructor.

Because it requires extra programmer education and time? For many
applications that don't require particularly high performance, one can argue
it's better to but as much of the 'smarts' in the programming language as
possible so as to allow people to be productive as quickly as possible.

I like languages such as C and C++ where you do all your own memory
allocations, I'm just suggesting that -- rubbish programmer or not --
sometimes you may be perfectly happy with a language-provided memory
manager. After all, plenty of C/C++ programmers end up writing their OWN
garbage collection routines for their own custom memory allocation schemes!
Again depending on the application, garbage collectors can be perfectly
legitimate memory managers.

---Joel Kolstad

 

[Joel Kolstad]

Nah. Real programmers program in whatever gets the job done right.

Well said. While I've been pushing the high level language solution for
many applications (especially those hosted on high speed CPUs), I would
hasten to add that a couple years ago Microsoft was looking to hire x86
assembly languague gurus to code up DirectX routines!

For the guy with the AVRs and assembly vs. C: Why does the C compiler have
to be free? Can't it just be 'reasonably priced?' If the team using the
ARM CPU could afford you, you might be able to as well! I've founded that
mixed 'main code in C, time critical interrupts in assembly' does work quite
well. The only reason the interrupt routine might run a skosh more slowly
would be due to your having to save a few additional registers that the C
compiler considers its own that you would have avoided using had everything
been in assembly.

---Joel Kolstad

 

[Chuck Simmons]

For the guy with the AVRs and assembly vs. C: Why does the C compiler have
to be free? Can't it just be 'reasonably priced?' If the team using the
ARM CPU could afford you, you might be able to as well! I've founded that
mixed 'main code in C, time critical interrupts in assembly' does work quite
well. The only reason the interrupt routine might run a skosh more slowly
would be due to your having to save a few additional registers that the C
compiler considers its own that you would have avoided using had everything
been in assembly.

I could not spend money on the architectural study of the three AVR chip
architecture because the contract was charged on time only.

We are evaluating 3 AVR C compilers. A problem we are having is that our
memory models are weird. This is especially true of the three AVR chip
in which all memory (including program memory) is dual port RAM. The
question in my mind is does using C in my case work at all given that
over 80% of the code has not changed in more than three years.

Chuck

 

[Active8]

W.I.N.D.O.W.S : Will Install Needless Data On Whole System.

If only it was as harmless as that.
--

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit patch
to an eight bit operating system originally coded for a four bit
microprocessor and produced by a two bit company."

add this:

"but worth less than one bit."

Would anyone care to extend this into IEEE floating point to
reflect the collective IQ of the folks at Redmond? Can IEEE
floating point represent such a miniscule number?

brs,
mike

 

[Active8]

On Fri, 24 Oct 2003 22:26:49 +0100, "Kevin Aylward"



No. The amount of memory allocated in c++ is quite determistic.



ISTR the heap memory handling ability of C is pretty crap though,
isn't it, Kev?

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit
patch
to an eight bit operating system originally coded for a
four bit
microprocessor and produced by a two bit company."

That doesn't care about its customers one bit.[/QUOTE]

ok. i like that. i'll change my addition to "and it's products are
less than a half-bit.

brs,
mike

 

[Active8]

Paul Burridge wrote:

On Fri, 24 Oct 2003 22:26:49 +0100, "Kevin Aylward"



No. The amount of memory allocated in c++ is quite determistic.



ISTR the heap memory handling ability of C is pretty crap though,
isn't it, Kev?

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit
patch
to an eight bit operating system originally coded for a
four bit
microprocessor and produced by a two bit company."

That doesn't care about its customers one bit.

ok. i like that. i'll change my addition to "and it's products are
worth

less than a half-bit.

brs,
mike[/QUOTE]

 

[Ben Pope]

Because it requires extra programmer education and time? For many
applications that don't require particularly high performance, one can
argue it's better to but as much of the 'smarts' in the programming
language as possible so as to allow people to be productive as quickly as
possible.

I like languages such as C and C++ where you do all your own memory
allocations, I'm just suggesting that -- rubbish programmer or not --
sometimes you may be perfectly happy with a language-provided memory
manager. After all, plenty of C/C++ programmers end up writing their OWN
garbage collection routines for their own custom memory allocation
schemes! Again depending on the application, garbage collectors can be
perfectly legitimate memory managers.

I totally agree in environments such as Windows which is primarily where
Java programs are aimed... this thread has my mindset on embedded, low
memory, time critical environments.

I've not taken much of a look at J2ME, can you do your own memory management
stuff, or are you still stuck with garbage collection?

Ben

 

[Keith R. Williams]

W.I.N.D.O.W.S : Will Install Needless Data On Whole System.

If only it was as harmless as that.
--

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit patch
to an eight bit operating system originally coded for a four bit
microprocessor and produced by a two bit company."

add this:

"but worth less than one bit."

And cannot stand one bit of competition.

Would anyone care to extend this into IEEE floating point to
reflect the collective IQ of the folks at Redmond? Can IEEE
floating point represent such a miniscule number?

They're called "denormals". (both the numbers and the folks ;-)

 

[Paul Hovnanian P.E.]

On Fri, 24 Oct 2003 22:26:49 +0100, "Kevin Aylward"



No. The amount of memory allocated in c++ is quite determistic.



ISTR the heap memory handling ability of C is pretty crap though,
isn't it, Kev?

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit
patch
to an eight bit operating system originally coded for a
four bit
microprocessor and produced by a two bit company."

That doesn't care about its customers one bit.

From http://www.theonion.com/onion3311/microsoftpatents.html

"Think of this as a partnership," Gates said. "Like the ones and zeroes
of the binary code itself, we must all work together to make the promise
of the computer revolution a reality. As the world's richest, most
powerful software company, Microsoft is number one. And you, the
millions of consumers who use our products, are the zeroes."

 

[Russell Shaw]

A project I am on is studying this right now. C++ is not at issue in our
case but C is possible.

My chip has 3 AVRs in it and the other team has 1 AVR and an ARM in
their chip. C is already used for the ARM but the AVR software is all
assembler. My use of assembler for my 3 AVRs originated from my doing a
feasibility study for the 3 AVR architecture before joining the project
as a consultant. I could not find a free AVR C compiler at the time. At
the time (and still) I was looking at a 50kHz interrupt rate for all
three AVRs with AVR0 handling interrpts from 6 or more sources. C seemed
a stretch unless functions were never used and context switch was
watched closely.

The thinking now is that the other team can benefit from C because their
interrupt rate for their AVR is much lower than mine. All of the AVRs
have strange data memory maps but the good linkers can handle that. For
my part, AVR1 and AVR2 run substantially the same code which has not
changed in more than two years. There would seem to be no benefit given
the investment and the fact the code does not change.

My AVR0 is different. The code is complex (a mess) and hard to maintain.
I'm looking at repartitioning and using C for some blocks of code.
Linkers understand this so I have this as an attractive option. The fast
interrupt stuff might well stay in assembler but the slower interrupts
might work well in C. The other group is helping me with the evaluation.

Fast interrupts are easy with avr-gcc avr-libc. You can leave out the
prolog/epilog code in C and save/restore your own regs, or just link
a complete asm file.

http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/