AVR Freaks

Cliff,

You saw yourself here

https://www.avrfreaks.net/index.p...

That in the C-Structure being read from flash part alone that ASM was more than 2x faster than C. So thats more than a 10% saving.

Maybe it was sub optimal way of doing it, but I did ASK if there was a better way and no one offered more optimal C (that is still readable).

Sparrow2,

Yes on the "get layout" part of the scene draw routine (the on simplified in that other thread) I could get C to within 30% of the ASM by making it ugly and un-readable.

I think if it is going to be ugly and unreadable you may as well use ASM.

One of the biggest savings in that respect was 16 vs 8 bit.

The X and Y variables are 16 bit as they come in. In clean readable C they get treated as 16 bits the whole way through.

In the ASM version after the very first CP instruction of the first quadrant comparison I can branch off to two separate paths one 8 bit and one 16 bit. >90% of all calls are doable 8 bit.

The other big saving as you suggested was layout/structure related. By carefully placing sturctures in memory I was able to nix the use of MUL and also reduce register usage.

I live close to him and am helping with code on that project.

Cunning is very much hardcore ASM and hardware hacking. Although he was taught C at uni he doesn't actually think it is "fun".

I convinced him to use C for the asteroids game so it would be easy for other people to hop on board.

I myself don't get involved in my own projects these days as health issues may cause me to pull out with no notice.

The measurement of speed was done with a tek scope looking at a spare GPIO pin. At the start of a screen-draw I would send the GPIO high. Then at the end of screen-draw I would send it low.

I wrote the complex parts of the code for AVR-Type on the desktop in C long before cunning had built the hardware. The desktop version could save the state of the screen objects to a text file.

I played the game on the desktop to get to a typical but "busy" screen and hit save.

I then used this as the "test scene".

The "test scene" is not just a BMP or SVG like file. It is actually the state of game objects to get passed to the renderer.

Each change/optimization I made along the way I took note of how much time the test scene took to draw.

The original GCC 3.4.1 version was 26.47mS

My most recent ASM version is 5.13mS

The biggest improvements where

1, Dropping 16 bit maths when I could

2, In-line-ing 8 versions of the inner bresemham loop

3, Aligning the main array of objects (a 16byte structure) to a boundary.

4, Accessing sequential structures with LPM Z+

5, Using "register" variables for X0, Y0

6, Throwing away "register call conventions" for a specialized version of drawline that can't be called by C. I have two drawline routines now drawline() and drawline_asm_only:

The first two could have been done in ugly looking C and they alone where responsible for about a 3x improvement.

Ugly looking C or normal looking ASM are about on par for readability. Most end users will never have to look at the ASM though.

The LCD screen is 320x240 16 bit colour. I am only plotting single colour lines per objects.

As Koschi said - Asteroids (or AVR-Type) are sparse screens that only have a few lines on them. This draw screen routine is not calculating the clear screen time which is

320x240 = 76800 pixels
9.8uS to clear
8 million pixels / second (or very close too)

The nice thing about clear screen though is that it is "pseudo DMA". Where TOC1 does the clearing for me and the CPU is free to X-sort the objects so I can draw them most optimally

The Scene itself is 1641 plotted pixels in total (some pixels over-plotted for fewer than that visable on screen). 1641 Pixels in 5.13mS is 320 pixels per mS or ~50 clock ticks per pixel.

#3, Was implemented in C (with "section") but the C compiler would not take advantage of the easy maths it affords. Human can now swap/shift/AND pointers rather than using MUL.

#1, and #2 could be done in C. #2 would look a little bit ugly but #1 would look horrible.

I have 16 bit X and 8 bit Y values. If either X0 or X1 are greater than 256 then all the maths has to be done 16bit. (dX, dY, err), In ASM the first thing I do is calculate dX and if I can use 8bit maths I keep going with an 8bit only routine. If I need 16bits I branch off to a fully 16bit routine (8bits is most common so I branch to 16bit)

#3, #5 are both anti-C optimizations. I am doing things in ASM which the high priests say

"you should never do that - the compiler is smart and can figure it out better than you can"

#4 was just a classic case of a human spotting an elegant optimization the compiler is trying to brute force better. (see other thread for explanation)

#6 is Human using all 32 register fully.

The "scene" has 390 lines. There are 10 constants that have to be LDI to registers to output them to the data port at least once per line. These are "commands" to the LCD screen

SET UPDATE DIRECTION
SET X
SET Y
SET DATA

and so on.

The ASM only version pre-loads these into spare registers at the start of scene draw and never has to do an LDI again for all of its 1641 pixels.

The code is more than a BIT crazy. It should all be available to download on the instructables project page as far as I know.

I can post the vanilla C bresenham routine here if you like, but it is such a common thing (it's on wikipedia) that hardly seems needed.