On Tue, Mar 17, 2009 at 8:08 AM, <[email protected]> wrote:
> #define DAY(d) (( __DATE__[4] == ' ' ? 0 : __DATE__[4] - '0') * 10 +
> (__DATE__[5] - '0'))
> and MONTH being a much more complicated define i will omit here.
>
> But he resulting compiler output (lst-file) consists
> of several complicated shift and add operations that
> tell me the precompiler did not completely evaluated
> the expression - which should be a const for the moment
> of compilation.
That is because __DATE__ is a string e.g. "Mar 17 2009", and you're
indexing it,
and computing on strings, which is not a preprocessor operation---CPP
only does
simple integer and boolean arithmetic. So, the preprocessor just
passes the expression
(( "Mar 17 2009"[4] == ' ' ? 0 : "Mar 17 2009"[4] - '0') * 10 + (
"Mar 17 2009"[5] - '0'))
to the compiler, which generates executable code, as you report. You
can see what
the preprocessor does with your stuff by running 'gcc -E'.
If avoiding the runtime calculation is important, I think your only
option is to use a different
preprocessor that has date functions, i.e. can extract elements of
date as numbers and do
calculations on them. I would suggest Perl. One way to do what you
want would be to write
your program to use something like
display_COMPILATION__DAY(xx);
and run the following Perl code as part of your make process:
perl -i -pe '$day=((localtime)[3]);
s/COMPILATION__DAY\(../COMPILATION_DAY\($day/' myprogram.c
where the routine display_COMPILATION__DAY() puts the number on the
display in whatever format
you already have (hex/BCD/whatever), and can even be a macro that
calls asm() that directly puts out
the number out to your display registers.
By the way, if you have a numerical display, you probably already have
routines to display numbers
on it, no? If not, then you could treat the PERL localtime string like
a hex character, which in a horrible
hacky way you can write as:
perl -i -pe '$day=eval('0x'.(localtime)[3]);
s/COMPILATION__DAY\(../COMPILATION_DAY\($day/' myprogram.c