Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...
That is... dereference a label, and then do something if it turns into a
dead label (usually remove it). Would it be permissible to change the
decrefs method so it returns a Boolean expression, namely True if the
reference falls to zero and False otherwise? Given the function already
checks to see if the reference count is less than zero (to raise an
internal error), it should have negligable performance loss, and if
anything, the new jump optimisations will help a lot.
In the meantime, I've just taken a quick look at my code, and noticed
something possibly a little risky (compiler/x86/aoptx86.pas, line 3540):
{ Remove label xxx (it will have a ref of zero due to the initial check }
StripLabelFast(hp4);
{ Now we can safely decrement it }
tasmlabel(symbol).decrefs;
There's nothing actually buggy with the code because it's known that the
label has a reference count of 1 at this point, but "StripLabelFast"
removes the label while it's still live, something that I even said in
the procedure's comments that you shouldn't do! i.e. I broke my own
rule! To be safe, these two commands should probably be switched
around, so the label is actually dead when StripLabelFast is called. It
won't affect the output in any way, but will hopefully reduce the risk
of alarming another programmer who stumbles upon it.
Gareth aka. Kit
On 10/11/2019 16:45, Florian Klämpfl wrote:
Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:
Some of the "condition_in" functions need expanding though, and I
don't yet have an answer if it's okay to do operator overloading in
the compiler source (so I can do things like "if (jmp1.cond in
jmp2.cond) then", for example, instead of the more ambiguous "if
condition_in(jmp1.cond, jmp2.cond) then".
I wouldn't do, for somebody without experience with the code, this is
confusing. Operator overloading makes imo only sense if it effects a
lot of code and makes it more readable because it replaces a lot of
nested function calls.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
