Scenix uControllers

[Byron G. Jacquot]

>> AVRASM,
>> though Ive not seen to go the other way ;-)
>> The problem with assembler programming is that each time you pick up a new
>> processor
>> you have to learn the instruction set again.
>
>Yep.. This is what has deterred me from getting into the avrs and such..

Actually, it gets easier with each new processor you learn.  Eventually, you
know the approximate building blocks, and it's just a matter of stringing
them together...like knowing the differences between what registers do what,
the addressing modes, and what they decided to call the
logical-vs-arithmetic shifting, etc, etc.  It's a matter of nuance, really.

I find the AVR architecture to be flexible, due to all of the registers, but
other people might find it a little restrictive, due to the lack of explicit
address registers and some of the fancier addressing modes (where's my
page-zero indirect?).

Simple C programming can be a way of formalizing a lot of the things that
are just plain time consuming in assembly.  Like preparing stack frames for
function calls (really ugly and error prone on a larger machine), or having
a handy "for" or "while" loop when you really need it.  Again, a matter of
knowing the building blocks.

>> Ive done a little with C, and what Ive found is its great to get complex
>> stuff done but when I need
>> the speed I go into the asembler file it generates and tinker with it to
>> make it faster.

That's a classic trick.  With a really good optimizing compiler, you can
learn some tricks of your own ("what...wait-a-minnit...why is it popping
something off the stack in the middle of that block of code?  Oh...wow...now
I get it.").

And some compilers, like the GNU tools, let you drop assembly statemets in
the C code wherever you feel the need.  You can build the necessary
framework out of C-language constructs, and do the dirty work in
assembly...though it also helps to really know your architecture, and how C
and ASM interrelate (so is it an array?  or a pointer?  Really, deep down
inside...).

There are some fairly simple things that you can keep in mind when coding in
C if you know the instruction set.  Like using rotates sometimes does
wonders (if you've got a barrel shift instruction), while other times a
bitwise and/or will be faster.  Also, knowing which post/pre operations are
done using instructions, and which aren't.  For instance, i++ and --i are
both good in the AVR assembly, but i-- and ++i aren't so good, due to the
lack of the corresponding instructions.  The Exclusive-or instruction is
sorely lacking on some machines!!!

Even better, write it in C first, compile and run the code.  Then see how
efficient it really is.  You might find that some of it isn't terribly
efficient, and it doesn't really matter because it's not critical.  If it is
critical, you can then use the compiler output to arrange your own speed
up...bypass it's translation of the language and tell the machine directly
what you really meant for it to do.  But you've got to know the architecture
to do that very well!

As is often the case, I find it's really a matter of picking the tool that
best fits the job...although it might mean that you have to have a lot more
tools on your workbench in the end!

Byron Jacquot