AlexJH

The more stuff you can squeeze into a chip, the better. I'm hoping to make this post into a reference for some tips on how to shrink your code down when you can.

I'm home sick on a Saturday night , so forgive me if I make any mistakes, my head is a bit fuzzy.

My first tip is to pay attention to what the assembler generates with certain instructions, because when you're writing in assembly you tend to forget what bytes are being output.

Use this page for reference:
http://home.earthlink.net/~tdickens/...tructions.html

Let's say you're making a routine that uses Indirect Addressing and you want to decide which index register to use, X or Y.

Well, have a look in the Pink Book or the page I listed above for the ADCA instruction, Add with Carry to register A.

You'll see that to use register X, it will generate an opcode that has 2 bytes, the opcode (E9) and then a single data byte.

To use register Y for the index, you'll see that it uses 2 bytes for the opcode (18E9), then another data byte, for a total of 3 bytes. It also takes 5 clock cycles, which is 1 more than using X.

So, as a general rule, use index register X if you can, and only use Y if the X register is already being used for something else.

91blackgta

I love this assembly basics series, maybe cause I am in a Mototrola HC12 class right now. Another good prctice to use is indexed addressing. Althought it might not make your code much smaller it does makes it easier to write your code and understand.


Here is the simulator we use.

http://www.hc11.demon.nl/thrsim11/thrsim11.htm

Chuck!

I just got done writing an assembler for a class and you had to go make this post. Painful memories ...

dimented24x7

iTrader: (2)

I love assembly. Its the most efficient way to program. There is so many little tricks you can do to cut down on execution time and software size.

derf

That's the truth. But for projects of significant size, assembler is horribly cumbersome. As your projects get more and more complex, you start adding so many macros and making them so generic and general purpose, you may as well be writing your code in C.

Still, it's fun to rewrite the bootstrap loader and device drivers when you switch to a 32 bit version of a processor from an older 16 bit version. That is, until you realise you're the first (and only) customer to use this chip and they haven't really qual-tested the assembler and you have all sorts of problems with op codes getting truncated or overlapping each other, etc. Then you add the C compiler that generates assembler files incorrectly for a number of reasons.

Some days, I wish I was working on PC code...

junkcltr

iTrader: (1)

If you are having assembler / compiler problems I recommend GCC. It has been around a long time and the source is available which allows you to make quick fixes if you find a problem.

Give MINGW and GTK+ a try on the PC with GCC. GCC will compile atmel AVR, Freescale 68HC_stuff & DSPs, Analog Devices DSP.

Some say that assembly is the most efficient.......well, that assumes you write efficient assebly to begin with. C might compile to something more efficient. You don't know until you try. Writing C to compile well (efficient) is a matter of coding style. It takes time to learn how to make the compiler happy by looking at the assembly it creates.

derf

That's the problem. The processor vendor hacked together an extension to the GCC compiler for their proprietary extended instruction set. And when I say hacked, I mean it was hacked. Butchered even. It only puts out assembler code and only their proprietary assembler will recognize the mnemonics.

dimented24x7

iTrader: (2)

With these old motorola based ecms, assembly is the way to go IMO. On later complex cpu's, assembly would be a bitch, but with an 8 bit ecm running a car, all your really doing is math and boolian operations. Motorola assembly is very pleasant to program in for me. Its very orthogonal and logically laid out. I like it even better than C, but unlike C, all I can really easily do with it is math.

With my old C3, the proc is slow as hell so the only way to get more advanced features in without overwhelming it is to have elegant, efficient coding. I dont doubt that C compilers can be efficient, but now and then there will be little time saving things that only a human eye could spot.

Of course, there are limits. I could make code thats optimized for min instruction time, but interacting with the code when tuning would be far too cumbersome. Good example is the MAF I added in. Using scalars, mutiple tables and such would make for the most efficient code. But, all these seperate tables make calibrating the maf a pain. Instead I opted to add an improved lookup routine so I could have one large 16 bit table to store the airflow in. Same thing with the AFR. Having one consolidated table uses more instructions code wise, but makes changing the AFR as easy as typing in a value. I do like efficiency, but at the same time, I also want to see a clean, user friendly interface (like, no biases, scalars, multipliers, modifiers, tweakers, etc.) when Im tuning.