[sdcc-devel] [ sdcc-Feature Requests-1483474 ] Efficient constants

[SourceForge.net <no...@so...>]

Feature Requests item #1483474, was opened at 2006-05-07 20:09
Message generated for change (Comment added) made by graham-hanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1483474&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Philipp Krause (spth)
Assigned to: Nobody/Anonymous (nobody)
Summary: Efficient constants

Initial Comment:
I prefer to use constants of correct type instead of
#defines:

static const unsigned int X = 100;

instead of

#define X 100

When only the value of X, never it's address is used,
both should compile to euqivalent code.

sdcc generates rather compact code for the #define
(value "100" is used directly) and horribly inefficient
code for the constant ("100" lives in memory and each
time it is used it is loaded from there as if it wasn't
a constant).

I tried with sdcc -mz80

Philipp


----------------------------------------------------------------------

Comment By: Graham  Hanson (graham-hanson)
Date: 2010-06-08 15:00

Message:
I have just raised this point, specifically for the PIC14/PIC16 ports in
the forums (I didn't find this originally because I filtered on "pic")

I find that all the commercial compilers, and gcc I use in my day job on
large *nix systems apply this optimisation as a matter of course (unless
specifically disabled).  

An advantage of using static const is that the compiler can apply type
checking rules whereas with #define it can't.  It is also generally
acknowledged that #define is evil (although sometimes unavoidable,
especially when building for embedded systems)

So given the above I vote in favour of optimising const statics as compile
time constants.

Graham



----------------------------------------------------------------------

Comment By: David Barnett (merc64)
Date: 2007-01-02 17:10

Message:
Logged In: YES 
user_id=896846
Originator: NO

I noticed one of the commercial compilers (Sourceboost) had the same
issue.  I was surprised to find that gcc doesn't seem to make that
optimization, either (from what I could tell...I haven't used x86 asm
much).  I didn't follow the comments about the C language specification,
but I haven't seen any good reasons not to propagate static consts except,
as Philipp mentioned, when it needs an address.  Is this optimization
feasible/correct?

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2006-05-24 16:08

Message:
Logged In: YES 
user_id=1115835

Well, the trick here is that *static* makes the variable
locally visible within the (.o) file and does *not* produce
a globally visible symbol that could be used to modify X's
value outside of the current file. Thus I would rather agree
with Philipp and propagate the constant through the expressions.
Philipp even mentioned problem I can think of: pointers to X
enforce current behaviour.

Regards,
Raphael


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-05-24 15:46

Message:
Logged In: NO 

Phillip, you misunderstood the C language specification.
'static' is *storage class* specifier and 'const' is
*storage* class* modifier. Either case, you need to spend
some storage on X. 

Why is it useful and why there is difference between
'#define X 100' and 'static const unsigned int X = 100;' ? 

Well, the former is ment as means to ease maintanence and
control over "magic numbers" that may be sprinkled all over
your code, while latter is useful if you need to change some
localisation code in your program even *without
recompilation*, i.e. right before you burn it in device (E,
EE, Flash)PROM or something, provided you kept track of its
address (symbol table). The obvious example is a serial
number or version ID tag.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1483474&group_id=599