last night I decided to bite the bullet and coded all of my interrupt in assembly 
which allowed me to rise the interrupt frequency from 60 kHz up to 170 kHz after 
which it it leaves so few cycles for the anything else that the USB stack stops 
working. This is fine, as at my target freq of 120 kHz there is still about 50%
of cycles available for other tasks which should fine.

But that is all beside the point except that it shows that with little bit
of effort I was able to optimise the code a lot and I'm virtually a
PIC assembler virgin and that got me thinking:

Even with the union/struc{} trick that allows the compiler to throw away
many of the BANKSEL a few of them still remained.

Apparently because of the union{} trick the compiler generated
very wasteful code for a lot of the operations, for example:


; .line 126; stepperirq.c MOTOR.steps = MOTOR.next_steps;

; MOVFF (_g + 21), r0x00

; MOVF r0x00, W

; MOVWF (_g + 17), B

; .line 127; stepperirq.c MOTOR.speed = MOTOR.next_speed;

; MOVFF (_g + 19), r0x00

; MOVFF (_g + 20), r0x01

; MOVF r0x00, W

; MOVWF (_g + 15), B

; MOVF r0x01, W

; MOVWF (_g + 16), B

I replaced with this:

;   MOVFF (_g + 21), (_g + 17)

;   MOVFF (_g + 19), (_g + 15)

;   MOVFF (_g + 20), (_g + 16)

So it looks to me that a #pragma or something that

could be used to tell the compiler that certain variables

are on the same bank would pay hi dividends in terms

of code size and execution speed.

Seems like this should not be a big deal for a person

who knows the compiler inner working and really help

with the code quality.

An other #pragma that would tell the compiler not

to overlay registers would simple implement

and but useful when the coding gets though. 

Combine that with a less conservative and more

analytical function prologue/epilogue generation

would go a long way towards smaller and faster code

I think.

Maybe I'm wrong.

Oh, af, in case you missed it, I'm working on PIC18.

Ok, enough of day dreaming, I have a concrete question:

How can I ensure that a variable or number of

variables are all in the same bank?

Because SDCC generates code for struct's as if

they are on the same page I presume that somehow

this is ensured but I could not spot anything in the

generated assembly that tells the linker to place

it all on one page. Nor in the gpasm or MPASM 

manuals, on the contrary I found a warning that

things may span several banks.

So how does the magic happen?

br Kusti

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.