Jump to content

Recommended Posts

Can someone tell me what I should expect for the optimization levels in 6.60 unreg? I've gotten identical results with -O1 and -Oa. I can only guess either the aggressive level optimizations have been moved back to -O1 in 6.60 or possibly they are disabled until you register... I also noticed the MPLAB integration doesn't have an option for the aggressive level. I had to add '-Oa' to the 'additional options' field myself.

 

Looking through the generated assembly, I've seen tons of missed opportunities for optimization, so I'd expect 'aggressive' would do something.

Link to post
Share on other sites
Can someone tell me what I should expect for the optimization levels in 6.60 unreg?  I've gotten identical results with -O1 and -Oa.  I can only guess either the aggressive level optimizations have been moved back to -O1 in 6.60 or possibly they are disabled until you register...  I also noticed the MPLAB integration doesn't have an option for the aggressive level.  I had to add '-Oa' to the 'additional options' field myself.

 

Looking through the generated assembly, I've seen tons of missed opportunities for optimization, so I'd expect 'aggressive' would do something.

 

Optimization options did not change in the last few releases and optimization doesn't depend on the current license type. It's probably your code that can not be optimized further by BoostC so you see similar results using -O1 and -Oa.

 

We appreciate if you can send us code fragments where you think compiler misses some optimization opportunities. We'll be happy to add them into the future releases (a small project with code that can be optimized further and explanations what compiler does now and what you expect it do do will be ideal)

 

Regards,

Pavel

Link to post
Share on other sites

Pavel,

 

Here's one that seems an obvious opportunity to use a DECFSZ in place of a DECF, MOVF, and BTFSS. Where one instruction could do the work of three.

 

The target device for this is the PIC16F877A

 

;/////////////////////////////////////////////////////////////////////////////////
;// Code Generator: Unknown! - http://www.sourceboost.com
;// Version       : 6.60
;// License Type  : Pro License
;// Limitations   : PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited
;/////////////////////////////////////////////////////////////////////////////////

#include <system.h>
volatile unsigned char a;

void main()

{
 unsigned char count;
 
 a=0;
0003  1283 	 BCF STATUS, RP0
0004  1303 	 BCF STATUS, RP1
0005  01A1 	 CLRF gbl_a

 count=0;
0006  01A2 	 CLRF main_1_count

 do
0007        label268438731

 {
   a=count+1;
0007  0A22 	 INCF main_1_count, W
0008  00A1 	 MOVWF gbl_a

 } while (--count);
0009  03A2 	 DECF main_1_count, F
000A  08A2 	 MOVF main_1_count, F
000B  1D03 	 BTFSS STATUS,Z
000C  2807 	 GOTO	label268438731

}
000D  0008 	 RETURN


////////////////////////////////////////
// Code with no source :-)
////////////////////////////////////////
0000  280E 	 GOTO	_startup

000E        _startup
000E  1283 	 BCF STATUS, RP0
000F  1303 	 BCF STATUS, RP1
0010  1020 	 BCF CompGblVar12,0
0011  10A0 	 BCF CompGblVar13,1
0012  118A 	 BCF PCLATH,3
0013  120A 	 BCF PCLATH,4
0014  2803 	 GOTO	main

Building...

BoostC++ Optimizing C++ Compiler Version 6.60 Alpha (for PIC16 architecture)

http://www.sourceboost.com

Copyright© 2004-2006 Pavel Baranov

Copyright© 2004-2006 David Hobday

 

Licensed to cac001 under Single user Pro License for 2 node(s)

Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited

 

 

opto1.c

 

success

BoostLink Optimizing Linker Version 6.60

http://www.sourceboost.com

Copyright© 2004-2006 Pavel Baranov

Copyright© 2004-2006 David Hobday

 

 

Optimisation level:1

Building CASM file

 

Memory Usage Report

===================

RAM available:368 bytes, used:3 bytes (0.9%), free:365 bytes (99.1%),

Heap size:365 bytes, Heap max single alloc:111 bytes

ROM available:8192 words, used:21 words (0.3%), free:8171 words (99.7%)

 

 

Successful

"C:\Program Files\SourceBoost\boostc++.pic16.exe" opto1.c -t PIC16F877A -Oa

"C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic16.lib opto1.obj /t PIC16F877A /d C:\Public\SourceBoost\examples /p opto1 -O1

Done

 

Here is the sampe source compiled by HiTech LITE version 9.50:

 

#include <pic.h>

volatile unsigned char a;

void main()
{
 unsigned char count;
 
 a=0;
 count=0;
 do
 {
   a=count+1;
 } while (--count);
}


Line  Address  Opcode Label                Disassembly

    1   0000  01A0           CLRF a
    2   0001  01A1           CLRF count
    3   0002  2FF6           GOTO main
    4   0003  3FFF           ADDLW 0xff
                    <all lines match>
 2038   07F5  3FFF           ADDLW 0xff
 2039   07F6  1283   main    BCF STATUS, 0x5
 2040   07F7  1303           BCF STATUS, 0x6
 2041   07F8  01A0           CLRF a
 2042   07F9  01A1           CLRF count
 2043   07FA  0A21           INCF count, W
 2044   07FB  00A0           MOVWF a
 2045   07FC  0BA1           DECFSZ count, F
 2046   07FD  2FFA           GOTO 0x7fa
 2047   07FE  0183           CLRF STATUS
 2048   07FF  2800           GOTO 0

 

Clean: Deleting intermediary and output files.

Clean: Deleted file "C:\Public\TestC\HITECH\Test\test.cce".

Clean: Done.

Executing: "C:\Program Files\HI-TECH Software\PICC-Lite\9.50\BIN\PICL.EXE" -C -E"test.cce" "test.c" -O"test.obj" -Zg9 -O -ASMLIST -Q -MPLAB -16F877A

Advisory[1207] : some of the command line options you are using are now obsolete

Advisory[1208] : use --help option or refer to the user manual for option details

Executing: "C:\Program Files\HI-TECH Software\PICC-Lite\9.50\BIN\PICL.EXE" -E"test.lde" "C:\Public\TestC\HITECH\Test\test.obj" -M"test.map" -O"test.cof" -O"test.hex" -Q -MPLAB -16F877A

Advisory[1207] : some of the command line options you are using are now obsolete

Advisory[1208] : use --help option or refer to the user manual for option details

 

Memory Usage Map:

 

Program space:

CODE used Dh ( 13) of 800h words ( 0.6%)

CONST used 0h ( 0) of 800h words ( 0.0%)

ENTRY used 0h ( 0) of 800h words ( 0.0%)

STRING used 0h ( 0) of 800h words ( 0.0%)

 

Data space:

BANK0 used 2h ( 2) of 60h bytes ( 2.1%)

BANK1 used 0h ( 0) of 50h bytes ( 0.0%)

COMBANK used 0h ( 0) of 10h bytes ( 0.0%)

 

EEPROM space:

EEDATA used 0h ( 0) of 100h bytes ( 0.0%)

 

ID Location space:

IDLOC used 0h ( 0) of 4h bytes ( 0.0%)

 

Configuration bits:

CONFIG used 0h ( 0) of 1h word ( 0.0%)

 

Summary:

Program space used Dh ( 13) of 800h words ( 0.6%)

Data space used 2h ( 2) of B0h bytes ( 1.1%)

EEPROM space used 0h ( 0) of 100h bytes ( 0.0%)

ID Location space used 0h ( 0) of 4h bytes ( 0.0%)

Configuration bits used 0h ( 0) of 1h word ( 0.0%)

 

Loaded C:\Public\TestC\HITECH\Test\test.cof.

BUILD SUCCEEDED: Thu Dec 21 18:47:52 2006

Edited by cac001
Link to post
Share on other sites

BoostC18 seems to use only FSR0 and INDF0 for indirect accesses.

 

Copying indirect source to indirect destination would be greatly optimised by using FSR0 as the source and FSR1 as the destination.

 

whilst on the subject.

FSR2, INDF2 could be used during the interrupt thread so that FSR0 and INDF0 would not need saving and restoring during interrupt.

If you don't use FSR1 for indirect destination operations it could be used for the low level interrupt.

Link to post
Share on other sites
It's probably your code that can not be optimized further by BoostC so you see similar results using -O1 and -Oa.

I compared the RAM and ROM usage for both and they were identical (121 and 625, respectively). There's probably just nothing else it can optimize, but I wanted to make sure I was seeing it at its best.

 

This is the least optimized code I've seen so far:

35:               	 var1 = var2 = var3 = var4 = 0;
 008E    01EA     CLRF 0x6a
 008F    11E3     BCF 0x63, 0x3
 0090    01EB     CLRF 0x6b
 0091    1163     BCF 0x63, 0x2
 0092    186A     BTFSC 0x6a, 0
 0093    1563     BSF 0x63, 0x2
 0094    186A     BTFSC 0x6a, 0
 0095    0AEB     INCF 0x6b, F
 0096    01EC     CLRF 0x6c
 0097    10E3     BCF 0x63, 0x1
 0098    186B     BTFSC 0x6b, 0
 0099    14E3     BSF 0x63, 0x1
 009A    186B     BTFSC 0x6b, 0
 009B    0AEC     INCF 0x6c, F
 009C    1063     BCF 0x63, 0
 009D    186C     BTFSC 0x6c, 0
 009E    1463     BSF 0x63, 0

Variable liveness analysis would save the 0x6b and 0x6c regs (reusing 0x6a). Copy propagation would get it down to 4 instructions. For bonus points, the compiler could recognize that each assignment is independent (after copy propagation) and optimize to:

MOVLW 0xF0
ANDWF 0x63, 1

I actually put the assignments all on one line like that in the hopes it would help the compiler recognize that last optimization.

 

Liveness analysis and copy propagation would help in lots of other scenarios, too.

Link to post
Share on other sites
BoostC18 seems to use only FSR0 and INDF0 for indirect accesses.

 

Copying indirect source to indirect destination would be greatly optimised by using FSR0 as the source and FSR1 as the destination.

 

whilst on the subject.

FSR2, INDF2 could be used during the interrupt thread so that FSR0 and INDF0 would not need saving and restoring during interrupt.

If you don't use FSR1 for indirect destination operations it could be used for the low level interrupt.

 

 

Without setting up priority interrupts does it make sense that the compiler would use the

secondary indirect registers? i am curious since you have to use the hardware workaround

to enable priority interrupts for most of the 18F devices as the hardware is flawed.

Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...