four lines of code - 152++ instruct cycles of ouch ?

[asmboy]

oh - would anybody care to thrash me ?

i have these four lines of code ( for an f887 v4.085 )
that generate 152 instructions and sucks up even more clock cycles to execute

fadd is an unsigned int8 used as an offset into EEPROM space,
and myid and myidck are both unsigned int16's

IS THERE A BETTER WAY TO DO THIS - instruction count wise ?
i do several similar uses of EEPROM and the code space burden is the worst thing in the program

[PCM programmer]

http://www.ccsinfo.com/forum/viewtopic.php?t=23844

[asmboy]

after profiling the change that gets down to 115 instrux total
and is very worthwhile since the program is crafted to never have an issue with exec time , when EEPROM is being written to -
that gets it down 25% - which is better than before

i keep wondering if there is a more efficient way to access the bytes of the long ints as well - better than make8 - but looking at the ASM code for THAT does not give me much hope

[n-squared]

asmboy,
Since CCS C duplicates code freely, it is sometimes better to create a one-line function and call it repeatedly.

[asmboy]

So here is a link to what compiled for me - the LST file.

After making assignment changes and merging it with a live bit of code
see for yourself at

http://64.128.110.53/eep.txt

Am I and n-sq using different number bases when we count ?

I get way over a hundred instructs in the LST - but especially
the block of 28 instrux - the "wrapper" - that is executed 4 times
in runtime.

How am I misreading to LST file to get such a large number of
1- code space instructs
2- wicked big number of executed instructs ?

WAY more that N-sq counted or saw.

[n-squared]

Asmboy,
I included the complete listing below, for your review.
It seems to me that in your program the variables are located in different banks, which causes the compiler to switch back and forth between them.

Best regards
Noam

[asmboy]

Bank switching happens when you have non trivial programs
that use a lot of variables and buffers.

I need enough large char buffers in the code this was appended to ( 87% Ram used - 91% code space F887) - that many small vars get stuck in whatever space the compiler can stash them.

I should have noticed the bank switch overhead.

[n-squared]

asmb,

You're welcome.

Sometimes we make TWO misteaks at a thyme.

N-sq
_________________
Every solution has a problem.

[ckielstra]

As a general optimization trick in the PIC16, try to keep the memory hungry variables out of the first bank. This will create the most effective use of the access bank feature in the instruction set.
The CCS compiler assigns memory locations to the variables in the order they appear in the source code. Check the symbol file (*.sym) to see which large buffers are located in low memory and try to move these to other memory banks.

Furthermore the compiler is doing a poor job:

[asmboy]

DUH I shoulda thought of that.
THANK you ckielstra - that is a BIG help for more than just this one instance.

Brilliant and I can use the same sort of thing in several other places where I am messing with make8() and make16 from a int32
for no better reason than it was EZ and the compiler manual pages && doc kinda pointed in that direction.

I OWE U 1

[n-squared]

ckielstra,
Thanks for the tips.
I didn't get this far in optimizing the code.

Best regards
Noam
_________________
Every solution has a problem.

[n-squared]

As a further exercise, if we make the fadd variable a global and let the store_to_eeprom() increment it after each write, we save further.
For each sequence of writes, we set fadd to the first address and then start calling the function: