[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Jonas Maebe]

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