Oh right! In that case, I can upload the code now... well, after I
finish testing everything! (I'll keep my platform-specific code in a
personal branch though in case it doesn't work).
I have seen once source of inefficiency in the compiled assembly
language and that's something akin to this (the code is to assign the
result of a condition to a Boolean variable - for example, "Result :=
Value is TEnum;")
cmpl $##, %reg
jnbe @Lbl
xorb %al, %al
jmp @Done
@lbl:
movb $1, %al
@Done:
(Presumably the xorb %al,%al line was originally movb $0,%al before the
post-peephole stage converted it) It might be this way because there was
something else in between that was optimised out, but this could be
optimised to:
CMP $##, %reg
SETNBE %al
Note that there is one shortcoming that I've discovered while writing a
test, and that you can't yet use as/is in a generic function - that is,
if you have something akin to this:
generic function<T1, T2>(Value: T1): Boolean;
begin
Result := T1 is T2;
end;
It will fail, saying that a class type is expected where T2 is
specified. I'll open a separate issue for this once the first patches
are accepted and cleaned up.
Gareth aka. Kit
On 07/07/2019 20:07, Jonas Maebe wrote:
On 07/07/2019 07:33, J. Gareth Moreton wrote:
Maybe I'm missing something painfully
obvious here. Can I request an example
where such an invalid value/undefined
behaviour crops up in bitpacked records so
I can see what's going on? Logic dictates
that the number of bits required to store
an enum in that arrangement is equal to
the index of the highest element,
That is correct, but the discussion revolves about storing elements that
are larger than that the highest or smaller than the lowest element. In
that case, bits gets lost when storing them in bitpacked versions.
On 07/07/2019 19:36, J. Gareth Moreton wrote:
Additionally, I'm putting in an implementation specific to x86 because I
can take advantage of its ALU design to do the range check in as few as
2 instructions (a comparison and either a conditional jump or a SETcc
instruction). If the range exceeds the CPU size though, then it falls
back to the node-level, platform-agnostic method.
That is not necessary. The compiler can do that trick itself (in a
CPU-independent way). Before yesterday, it could only do it with
unsigned ranges, but since yesterday it can also do it for signed ranges.
It can't yet inline the fpc_is/as_enum because it calls an
implementation-only procedure of the system unit, but I'm working on
solving that as well.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
