Hi Przemek,
We currently also use the '()' non-optimization for
HB_SYMBOL_UNUSED().
It is and was optimized. For all expressions like:
(exp) <op> (exp)
our expression optimizer strips parenthesis.
It's also not Clipper compatible and maybe we should disable
this optimization when -kc is used. Now it's always enabled.
We also have some other optimizations not done by Clipper, f.e.
Clipper does not make any optimization for <exp> when message
is sent to <exp>, f.e.:
? (10==10):calsname
Now this optimization can be disabled by -kc.
This is fine. I've also checked HB_SYMBOL_UNUSED(), and it works.
If we can resolve the above, and make it possible to disable
the feature using -k switch, I think we are fine with it.
If this involves any complexities though, I'd leave it for after RC1.
In last commit I've already done it for function parameters and -kc
disable this optimization.
Anyhow I think we should update hbtest and use #pragma -kc / #pragma
-khx
or HB_C52_STRICT macro for some of CHR( ( <num> ) ).
See current hbtest results.
In general there is a problem with compile time optimizations for
CHR( <integer_value> * 256 )
and $ operator in expressions like:
"" $ <exp>
caused by bugs in Clipper compiler. It gives different results then
runtime functions/operations. Keeping strict Clipper compatibility
is hard in complex expressions. Probably we should think about adding
option to set valid results in such situations or we should introduce
flag for expressions to mark them as optimized and in such case do not
replicate wrong Clipper compile time optimizations.
We may guard those with #pragmas for Harbour, to
disable compile time optimization for these cases,
or better yet, add both versions to make the
difference more apparent.
It's not possible to make a perfect decision here,
unless investing extreme energy (like those flags)
to keep bug compatibility, not to mention what an
ugly inconsistency this is. My personal opinion in this
case is to fix this Clipper bug in Harbour, and make it
available using a switch for those few ppl who are relying
on them and haven't yet corrected their code. I suspect
there is not too many such ppl, and even most of this
code is probably macro compiled.
Question: Do we do all these optimization for macro
code too, and do we have a way to disable it? Yes and
yes is the answer AFAIK, so IMO we're covered.
BTW I also thing we should also add INT( <num> ) optimization.
Definitely.
I'd plug these just to not forget about them, but these
will need new pcodes, so it's a slightly different story:
- HB_P_PUSHNIL + HB_P_RETVALUE would become: HB_P_RETNIL
- HB_P_FALSE + HB_P_RETVALUE would become: HB_P_RETFALSE
- HB_P_TRUE + HB_P_RETVALUE would become: HB_P_RETTRUE
- SUBSTR(s,n,1) -> HB_P_SUBSTR1 (or whatever name)
- ASC(SUBSTR(s,n,1)) -> HB_P_SUBSTR1ASC (or whatever name)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
