Jump to content
Sign in to follow this  
Asmotaku

Boostc16 Erroneous Optimization

Recommended Posts

Bug description: BoostC16 Linker greedy optimizations.

BoostC16 linker makes time-critical

built-in assembly very hard to get, with command-line parameter -O1 !

 

Steps to reproduce:

Compile and Link the following

 

 

 

Statements : "JUMPTABLE_MASK" equals 0x07

Passing the "myindexvar" parameter to the "Time_Critical_Func" routines makes the µC execute an instruction flow, as shown below

myindexvar <= 1 --> process CODECHUNK[1-5]

myindexvar == 2 --> process CODECHUNK[2-5]

myindexvar == 3 --> process CODECHUNK[3-5]

myindexvar == 4 --> process CODECHUNK[4-5]

myindexvar == 5 --> process CODECHUNK[5]

myindexvar > 5 --> process CODECHUNK[1-5] + time-alignment 'NOP's

 

Any value of "myindexvar" exceeding 0x05 must

code for a code jump to "CODECHUNK_01", plus

time-critical NOP's.

 

void Time_Critical_Func()

 

asm{

MOVLW 0x03

MOVWF _pclath

INCF _myindexvar, W

ANDLW JUMPTABLE_MASK

ADDWF _plc, F ; forced jump

GOTO CODECHUNK_1

GOTO CODECHUNK_2

GOTO CODECHUNK_3

GOTO CODECHUNK_4

GOTO CODECHUNK_5

NOP

NOP ; last address accessible by 'forced jump'

NOP ; some time-critical ops

NOP

; Which could have been replaced by the well-known :

GOTO $+1 ; which replace 2 NOPs, saving program memory

; The fact is I use it whenever I can...

CODECHUNK_1:

; do what's needed in first chunk

CODECHUNK_2:

; do what's needed in first chunk

CODECHUNK_3:

; do what's needed in first chunk

CODECHUNK_4:

; do what's needed in first chunk

CODECHUNK_5:

; do what's needed in first chunk

RETLW 0

 

}

}

 

The problem 100% reproduceable.

 

Pending behavior :

BoostC16 linker, with command-line operator [-01] (Optimization On) will

judge the [NOP]s as dead code... which is not...

Those silent instruction may be critical for a real-time application.

Morever : the GOTO $+1 trick, which save program ROM, is said to be invalid by the linker. *sob* *sob* <_<

 

 

Expected behaviour:

How a fixed program should behave :

You can bypass this by using the [-O0] command-line parameter...BUT...your code inherits a buch of BANK selection instruction (BCF STATUS , RPx), which damages the time-critical code aspects.

Users should have the opportunity to tell BoostC when a built-in asm snippet must be optimized wisely, or even left as-is ! Such as the unchecked() pragma of C#.

As a matter of fact, the code I presented above could have been easier to implement if BoostC had offered a

fixed address function declaration : void MyFixedRoutine()@MY_ROM_ADDRESS

 

 

 

 

IDE version: SourceBoost IDE v5.r6.c1

Compiler: BoostC

Compiler version: BoostC16 v1.r4

Target device: Any PIC16 architecture

OS: WinXP

Comments : Didn't spend time to check syntax in this post. :huh:

Edited by Asmotaku

Share this post


Link to post
Share on other sites

We already have this task in out BoostC todo list. Current plans are not to optimize assembly inside the 'asm' operation except adding bank and code page instructions if necessary.

 

Regards,

Pavel

Share this post


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...
Sign in to follow this  

×
×
  • Create New...