Optimization?

[Dale Botkin]

Using PCW 3.124, with a 12F629...

Here are the first few words from my .LST file:

This sets PCLATH to 0... but why? It's cleared on any reset.
0000: MOVLW 00
0001: MOVWF 0A

Here's two wasted words, as far as I can tell. I am not using any interrupts whatsoever, so I don't know why the compiler is doing this.
0002: GOTO 004
0003: NOP

Now we get the OSCCAL value and store it...
0004: CALL 3FF
0005: BSF 03.5
0006: MOVWF 10

And set PCLATH again? Why? It's already done, in addition to being unnecessary in the first place.
0007: MOVLW 00
0008: MOVWF 0A

Then jump to the start of main().

So it looks to me like we've wasted six words of program memory right off the bat. Am I wrong on this? It wouldn't be a big issue, but the compiler also steadfastly refuses to use any program memory past 0x3FB, meaning I'm about six words short of being able to squeeze one more feature in, but the compiler isn't cooperating. I've already had to resort to #asm for some places where the compiler was doing some really inefficient code. Anyone have any further suggestions? Unfortunately there is no other chip with more memory that will work for this application.

Thanks,
Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515700

[PCM programmer]

:=Using PCW 3.124, with a 12F629...
but the compiler also steadfastly refuses to use any program memory past 0x3FB.
---------------------------------------------------------------

I made the following sample program, and it used ROM in
that region. I compiled this with PCM vs. 3.124.

<PRE>
#include <12F629.h>
#fuses INTRC, NOWDT, NOPROTECT, NOMCLR
#use delay(clock = 4000000)
<BR>
#separate
void func(void);
<BR>
//==========================
void main()
{
func2();
<BR>
while(1);
}
<BR>
//--------------------------
#org 0x3F0, 0x3FE
void func(void)
{
char c;
c = 0x12;
c = 0x34;
c = 0x56;
c = 0x78;
c = 0xAB;
c = 0xCD;
c = 0xEF;
}
</PRE>

Here is part of the .LST file:

<PRE>
.................... //--------------------------
.................... #org 0x3F0, 0x3FE
.................... void func2(void)
.................... {
.................... char c;
.................... c = 0x12;
*
03F0: MOVLW 12
03F1: MOVWF 23
.................... c = 0x34;
03F2: MOVLW 34
03F3: MOVWF 23
.................... c = 0x56;
03F4: MOVLW 56
03F5: MOVWF 23
.................... c = 0x78;
03F6: MOVLW 78
03F7: MOVWF 23
.................... c = 0xAB;
03F8: MOVLW AB
03F9: MOVWF 23
.................... c = 0xCD;
03FA: MOVLW CD
03FB: MOVWF 23
.................... c = 0xEF;
03FC: MOVLW EF
03FD: MOVWF 23
03FE: RETLW 00
....................
.................... }
</PRE>


___________________________
This message was ported from CCS's old forum
Original Post ID: 144515703

[Dale Botkin]

:=:=Using PCW 3.124, with a 12F629...
:= but the compiler also steadfastly refuses to use any program memory past 0x3FB.
:=---------------------------------------------------------------
:=
:=I made the following sample program, and it used ROM in
:=that region. I compiled this with PCM vs. 3.124.
:=
Thanks for your reply. I have also had the compiler use those locations, but it seems there are situations where it will not. The explanation I got from CCS was that I have a switch statement in main(). The compiler doesn't know if it will need to cross a page boundary with a jump table, so it reserves space for setting PCLATH. If it turns out it doesn't need the space to manage PCLATH it doesn't free it up and use it. They say they have no plans to fix this. So in some cases, yes, it will use all available memory, but when things get *really tight* you may run into this. I'm having to resort more and more to blocks of #asm to overcome little quirks like this, which bothers me some.

Did your compiled example also do the PCLATH and jump-past-nop thing between address 0 and 9? I can't figure out why it would do that at all.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515706

[PCM programmer]

:=Did your compiled example also do the PCLATH and jump-past-nop thing between address 0 and 9?
-----------------------------------------------------------

Yes, it does that too.

I think the only thing you can do is to hand optimize
your code, which you've already been doing.
<a href="http://www.pic-c.com/forum/old/messages/1777.html" TARGET="_blank">http://www.pic-c.com/forum/old/messages/1777.html</a>

___________________________
This message was ported from CCS's old forum
Original Post ID: 144515707

[Dale Botkin]

:=:=Did your compiled example also do the PCLATH and jump-past-nop thing between address 0 and 9?
:=-----------------------------------------------------------
:=
:=Yes, it does that too.
:=
:=I think the only thing you can do is to hand optimize
:=your code, which you've already been doing.
:= <a href="http://www.pic-c.com/forum/old/messages/1777.html" TARGET="_blank"> <a href="http://www.pic-c.com/forum/old/messages/1777.html" TARGET="_blank">http://www.pic-c.com/forum/old/messages/1777.html</a></a>
:=

Yeah, I think I have just run up against the limits of how well the optimizer works. That loss of space above 1020 bytes irks me, though, it's just silly, as is the fact that there is apprently no way to fix the apparently senseless startup code. Oh well... maybe I'll let CCS know and if they ever fix it, maybe I'll upgrade.

Thanks - Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515711

[Pete Smith]

<font face="Courier New" size=-1>:=Using PCW 3.124, with a 12F629...
:=
:=So it looks to me like we've wasted six words of program memory right off the bat. Am I wrong on this? It wouldn't be a big issue, but the compiler also steadfastly refuses to use any program memory past 0x3FB, meaning I'm about six words short of being able to squeeze one more feature in, but the compiler isn't cooperating.

Could it be that internally, the compiler works on 4 byte "chunks" of memory. Location 3FF will be off-limits on the device you're using, because it's the location of the OSCCAL default value. When that's masked out for use, maybe the 3 previous words are also masked out automatically.

Pete.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515714

[Dale Botkin]

:=Could it be that internally, the compiler works on 4 byte "chunks" of memory. Location 3FF will be off-limits on the device you're using, because it's the location of the OSCCAL default value. When that's masked out for use, maybe the 3 previous words are also masked out automatically.
:=

Nope, I've had it use up to 3FE on other projects without any trouble. It's an oddball kind of thing, just irritating.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515716

[PCM programmer]

:= That loss of space above 1020 bytes irks me.
------------------------------------------------
What if you take one of your functions, and #org it so that
the last ROM address is 0x3FE ? You could pick a small
function, and look at the .LST file to see how long it is.
Then set the #org limits like I did in my previous post.
The compiler is then forced to use it. The remaining ROM
addresses will be filled with the other functions, presumably
without the compiler "reserving" some other block of 5 bytes.
I think it's worth trying.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515724

[Dale Botkin]

:=:= That loss of space above 1020 bytes irks me.
:=------------------------------------------------
:=What if you take one of your functions, and #org it so that
:=the last ROM address is 0x3FE ? You could pick a small
:=function, and look at the .LST file to see how long it is.
:=Then set the #org limits like I did in my previous post.
:=The compiler is then forced to use it. The remaining ROM
:=addresses will be filled with the other functions, presumably
:=without the compiler "reserving" some other block of 5 bytes.
:=I think it's worth trying.

Tried it with nothing more than a NOP... no go. Out of memory errors no matter what I try, played with #org in various combinations for a while with no success.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515732