Jump to content

Interesting SDCC Keywords Switches and Pragmas


stryd_one
 Share

Recommended Posts

Just a few nuggets I thought worth sharing... Some useful, some maybe useful later ;) But I'll spare you visiting the manual in 5 different places to get all the relevant stuff. My comments in italics.

Command line switches:

--optimize-goto Try to use (conditional) BRA instead of GOTO (already in use by us)

--optimize-cmp Try to optimize some compares. (already in use by us)

--optimize-df Analyze the dataflow of the generated code and improve it. (some interesting results here. shrunk one of my asm files by 33%. Did nothing to others. Worth a try?)

--obanksel=nn Set optimization level for inserting BANKSELs. (already in use by us, 2. 1 fixes some issues with variables >256B)

0 no optimization

1 checks previous used register and if it is the same then does not emit BANKSEL, accounts only for labels.

2 tries to check the location of (even different) symbols and removes BANKSELs if they are in the same bank.

Important: There might be problems if the linker script has data sections across bankborders!

--opt-code-speed The compiler will optimize code generation towards fast code, possibly at the expense of code size. (sometimes works)

--opt-code-size The compiler will optimize code generation towards compact code, possibly at the expense of code speed. (sometimes works)

--funsigned-char The default signedness for every type is signed. In some embedded environments the default signedness of char is unsigned. To set the signess for characters to unsigned, use the option –funsigned-char. If this option is set and no signedness keyword (unsigned/signed) is given, a char will

be signed. All other types are unaffected.

--verbose Shows the various actions the compiler is performing.

-V Shows the actual commands the compiler is executing.

--no-c-code-in-asm Hides your ugly and inefficient c-code from the asm file, so you can always blame the compiler :) (LOL)

--cyclomatic This option will cause the compiler to generate an information message for each function in the source file. The message contains some important information about the function. The number of edges and nodes the compiler detected in the control flow graph of the function, and most importantly the cyclomatic complexity (Try this!)

More info for those who haven't heard the term:

Cyclomatic complexity of a function is defined as the number of independent paths the program can take during

execution of the function. This is an important number since it defines the number test cases you have to generate

to validate the function. The accepted industry standard for complexity number is 10, if the cyclomatic complexity

reported by SDCC exceeds 10 you should think about simplification of the function logic. Note that the complexity

level is not related to the number of lines of code in a function. Large functions can have low complexity, and small

functions can have large complexity levels.

SDCC uses the following formula to compute the complexity:

complexity = (number of edges in control flow graph) - (number of nodes in control flow graph) + 2;

Having said that the industry standard is 10, you should be aware that in some cases it be may unavoidable

to have a complexity level of less than 10. For example if you have switch statement with more than 10 case labels,

each case label adds one to the complexity level. The complexity level is by no means an absolute measure of

the algorithmic complexity of the function, it does however provide a good starting point for which functions you

might look at for further optimization.

Pragmas

opt_code_speed - The compiler will optimize code generation towards fast code, possibly at the expense of code size. Currently this has little effect.

opt_code_size - The compiler will optimize code generation towards compact code, possibly at the expense of code speed. Currently this has little effect.

opt_code_balanced - The compiler will attempt to generate code that is both compact and fast, as long as meeting one goal is not a detriment to the other (this is the default).

nogcse - will stop global common subexpression elimination.

noinduction - will stop loop induction optimizations.

noinvariant - will not do loop invariant optimizations. For more details see Loop Invariants in section 8.1.4.

nojtbound - will not generate code for boundary value checking, when switch statements are turned into jump-tables (dangerous). For more details see section 8.1.7.

noloopreverse - Will not do loop reversal optimization

Keywords

__at - Use this to force a variable into a certain memory space. (Handy for using Access RAM eg; unsigned char __at 0x020 MyVar; ... Be CAREFUL! )

__wparam - Passes the first argument of a function in W. (TK uses this but most of the time we don't... For some reason. I have found it very useful, it saves a bank selection for the first 8 bits passed to it, if you only have one char as a function's parameter, it saves about 4 instructions :) )

Hope these are interesting and save you diving through that very informative and confusing manual :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...
 Share

×
×
  • Create New...