View previous topic :: View next topic |
Author |
Message |
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
Compiler precalculations |
Posted: Thu Aug 06, 2015 2:01 am |
|
|
Can the compiler make some calculations of fixed values related to other fixed values so I don’t these calculation in the program?
Example 1:
Code: |
#define version 0b0000000111110101
#define value_1 ((version & 448)/64)
|
Example 2:
Code: |
#define version 128
#define value_1
{
if (version == 128) value_1=7;
if (version == 64) value_1=6;
}
|
It seems to that example 1 is OK when I test this, but example 2 is not accepted by the compiler. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Thu Aug 06, 2015 2:35 am |
|
|
This is a C textbook job...
'if' is a runtime statement. Doesn't get executed till the code runs....
The pre-processor statement, is #if
The compiler can make decisions based on a define, using this. So:
Code: |
#define VERSION 128
#if VERSION == 128
#define VALUE 7
#else
#define VALUE 6
#endif
|
Now realise that 'VALUE' (or value_1 in your example), is a define (a text substitution macro), so you can't set it '=' to something, you can only #define it to something.
There is also #elif (with a second test), and #ifdef, which returns 'TRUE' if a value is #defined.
There is a 'C' 'semi-standard', to use 'ALL_CAPITALS' for things that are #defined. It's quite a sensible thing, since there are points in the code, where it can make a difference. Being not able to set it = to something, is an example!.... |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Thu Aug 06, 2015 3:54 am |
|
|
Many thanks Ttelmah.
That was just what I need.
However I'm a little in doubt whether all math operations can be used in my define lines. In my example 1, the bitwise AND and division seems to work. So is there any math which should not work or any restrictions of how complicated this math can be in the define line? |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Aug 06, 2015 4:00 am |
|
|
Mortenc wrote: | However I'm a little in doubt whether all math operations can be used in my define lines. ... So is there any math which should not work or any restrictions of how complicated this math can be in the define line? |
This "pre-calculation" is known as "constant collapse". Its a compiler thing, not a preprocessor thing. So, it doesn't happen in the #define, it happens when the compiler actually compiles the code, i.e. after all the text substitutions. It can only work with expressions that evaluate to a constant at compile time. It doesn't work with expressions with C maths functions, such as log(), sin() and so on, even if the parameters are constant. So things like ln(10.0) cannot be collapsed/pre-computed. |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Thu Aug 06, 2015 7:05 am |
|
|
Thanks it's a great forum.
I have a lot of pre-calculations to be done.
I must test every line a think, to be sure that all math I working. |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Fri Aug 07, 2015 1:19 am |
|
|
Now I have made a lot of pre-calculation that the compiler shall do.
First the compiling suddenly going slow and when I add more calculations to do, the compiler freeze and don't get finish.
Does anyone get an idea why?
It's just simple #if with define like:
Code: |
#if dataBit4Or == 16
#define dataBit4 4;
#else
#if dataBit4Or == 8
#define dataBit4 3;
#else
#if dataBit4Or == 4
#define dataBit4 2;
#else
# define dataBit4 1
#endif
#endif
#endif |
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Fri Aug 07, 2015 1:33 am |
|
|
First, lay them out as they are used:
Code: |
#if dataBit4Or == 16
#define dataBit4 4;
#else
#if dataBit4Or == 8
#define dataBit4 3;
#else
#if dataBit4Or == 4
#define dataBit4 2;
#else
#define dataBit4 1
#endif
#endif
#endif
|
Then if this is what you actually want, use #elif
So:
Code: |
#if dataBit4Or == 16
#define dataBit4 4;
#elif dataBit4Or == 8
#define dataBit4 3;
#elif dataBit4Or == 4
#define dataBit4 2;
#else
#define dataBit4 1
#endif
|
You are creating a triple deep stack of if conditions, when the whole thing can be done in one. The compiler has to work out all the possibilities in all possible states, so it takes work!... |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Fri Aug 07, 2015 2:56 am |
|
|
I have tried to make it like you said, using #elif and place text like your example, but the same happen.
I have more of these "if" defining and the compiling go fine, but it seems too, that there is a limit how many there can be. |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Fri Aug 07, 2015 4:27 am |
|
|
Could it be my large amount of #defines?
I have about 100 defines.
My compiler version is: PCM compiler 4.067 |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Mon Aug 10, 2015 2:02 am |
|
|
Does any have an idea what can be done to come over the limit?
My #defines look like these.
Nothing seems to be wrong with the #defines, but when I get to about 60 defines of these, the compiler freeze and don't get finish with the building.
Code: |
#define protocol 278 //
#define resolution 16 //
#define x_delay 1 //
#define y_delay 10 //
#define alarm_level 6 //
//***********************************************************
#define firstBit ((protocol & 448)/64)
#define secondBit ((protocol & 56)/8)
#define thirdBit (protocol & 7)
#define firstBitOr (1<<firstBit)
#define secondBitOr (1<<secondBit)
#define thirdBitOr (1<<thirdBit)
#define available (((255^firstBitOr)^secondBitOr)^thirdBitOr)
#define G22 (128 & available)
#define H22 (G22>>1)
#define I22 (64^H22)
#define G23 ((64 & available) & I22)
#define H23 ((G23^H22)>>1)
#define I23 (32^H23)
#define G24 ((32 & available) & I23)
#define H24 ((G24^H23)>>1)
#define I24 (16^H24)
#define G25 ((16 & available) & I24)
#define dataBit1Or (((G24^G25)^G23)^G22)
//
#if dataBit1Or == 128
#define dataBit1 7;
#elif dataBit1Or == 64
#define dataBit1 6;
#elif dataBit1Or == 32
#define dataBit1 5;
#else
#define dataBit1 4
#endif |
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Mon Aug 10, 2015 5:03 am |
|
|
Seriously, number of defines is not the problem. There are several hundred in the include file for the processor.
Odds are you have something 'recursive'. A define that depends on another define, that depends on another define, that depend in some way on the first define. So the compiler works round the loop trying to calculate the value, and gets stuck....
I'd say rethink the logic of what you are doing. The defines you list really are a mess. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Mon Aug 10, 2015 5:15 am |
|
|
I have to second Mr. t on this ! Just trying to 'play compute' to figure out what 'datbit10r' is hurt my head.
If you give us an example of what you're trying to do others can show you a simpler, faster, cleaner way of doing it.
Jay |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Mon Aug 10, 2015 6:29 am |
|
|
Thanks for your responds.
All the pre-calculations is taken from an excel-document which is made with microprocessor friendly math like shift, AND, OR and some IF decisions.
These calculations shall be used in a special encoding based of the protocol number. Then the idea is that you only have to change the protocol number, and then get the new encoding.
Of course I could take all pre-calculated values from the Excel document so the compiler not should make these, but it will be more easy if the compiler could make these calculation when I want to make a new protocol encoding.
So maybe if I could control the compiler to finish some #define first before it go to further #defines. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Mon Aug 10, 2015 8:23 am |
|
|
Defines are not 'dealt with'. They are a simple text macro substitution. Nothing else.
What happens is each one is effectively typed 'in' where it is used to build the final statement. So dataBit1Or expands to a sequence that it something over several hundred characters long.
So in fact splitting the maths up into dozens of little sub bits, just makes the expansion more bulky. Put the actual formula in directly. It'll be shorter.
The sequence that results, is then treated from the inside out (inner bracket), and solved as far as possible to generate the final value. This is the constant collapse. |
|
|
Mortenc
Joined: 22 Feb 2007 Posts: 55
|
|
Posted: Mon Aug 10, 2015 1:19 pm |
|
|
Thanks for your explanation of the problem Ttelmah.
I have just made the same calculations as were made in the excel document by another person. In the excel these calculation are tested and worked as it should.
Whether I can make the same special encoding by another way I need to study.
Thanks for your good explanations. I learn more every time. |
|
|
|