Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread Wolf
Why not call them UIntSize instead of FLog2 and BinSearchSize forCLog2? That would give an indication of how to use them, and class them along SizeOf, for finding them easily. After all, you are looking for the size of a variable? Wolf On 13/06/2018 12:13, J. Gareth Moreton wrote: I can see

Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread J. Gareth Moreton
I can see where you're coming from here. If not a logarithm, what would you call these functions that concisely and compactly describes their behaviour and purpose? While "bit scan reverse" is effectively a truncated log2, with a flag set if the input was zero, it's not a name that jumps out

Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread Wolf
On 13/06/2018 11:07, J. Gareth Moreton wrote: Well, I would argue that when computing log(x) of any base, as x tends to 0 from a positive number, log(x) becomes a progressively more negative number to the point that, yes, it's undefined, but that's only going by the definition of limits. Th

Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread J. Gareth Moreton
Well, I would argue that when computing log(x) of any base, as x tends to 0 from a positive number, log(x) becomes a progressively more negative number to the point that, yes, it's undefined, but that's only going by the definition of limits. The issue here is that my proposed logarithm function

Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread Wolf
Hi I object to one component of Gareth's proposal - to make log2(0)=0. The problem lies not with what Gareth wants to do with it, but what other people will use it for once it becomes available.  log2(0) is undefined (and undefinable, as it is not a computable number), the appropriate choice

Re: [fpc-devel] Kit's ambitions!

2018-06-12 Thread J. Gareth Moreton
Ideally yes, but this occurs after peephole optimisations where all of the register allocations have already been made.  Doing the peephole and deep optimisations while the registers are still in a virtual state would be better overall, but may require a huge overhaul of the compiler that might be

Re: [fpc-devel] Kit's ambitions!

2018-06-12 Thread nickysn
On Mon, 2018-06-11 at 21:07 +0100, J. Gareth Moreton wrote: > Thanks David, > > I'm still learning some of the nuances of the Intel and AMD > processors, but most of it is just logical analysis. Admittedly my > main drive has been to shrink down the size of the binary, since > Delphi and Free Pas

Re: [fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread J. Gareth Moreton
That would be nice, but I don't think Free Pascal supports such a concept, at least not yet. It would certainly be much more flexible and allow such functions to be distributed as part of a mathematical package, say. The concept of a pure function is useful to determine for other purposes as

Re: [fpc-devel] Unexpected behaviour with intermediate results

2018-06-12 Thread J. Gareth Moreton
As pointed out in the bug report, it's not a bug.  As listed in the documentation over here: https://www.freepascal.org/docs-html/current/ref/refsu4.html "Every integer smaller than the ”native” size is promoted to a signed version of the ”native” size. Integers equal to the ”native” size keep t

[fpc-devel] Proposal for 2 new compiler functions

2018-06-12 Thread J. Gareth Moreton
Hi everyone, Sorry to flood the mailing list again with more ideas and experiments. I would like to propose introducing a new pair of in-built functions for the compiler. function FLog2(X: Cardinal): Cardinal; function CLog2(X: Cardinal): Cardinal; FLog2 returns the base-2 logarithm of X,

Re: [fpc-devel] Unexpected behaviour with intermediate results

2018-06-12 Thread Stefan Glienke
The real bug imo is that is that it even generates shl and shr instructions. b := (a shl x) shr x should be just compile to b := a for x in 0..24 and a being 8bit (which is what several C++ compilers do afaik) > On 12 June 2018 at 02:07 "J. Gareth Moreton" > wrote: > > > https://bugs.freepasca

Re: [fpc-devel] Unexpected behaviour with intermediate results

2018-06-12 Thread J. Gareth Moreton
Hence why I wish to delegate this to someone more senior to decide if this is a bug or a feature.  Seems that logic has more than one path.  Mathematically, yes, shl 8 and shr 8 should cancel out completely and be a null operation. Gareth On Tue 12/06/18 12:42 , Giuliano Colla giuliano.co...@fa

Re: [fpc-devel] Unexpected behaviour with intermediate results

2018-06-12 Thread Giuliano Colla
Il 12/06/2018 02:07, J. Gareth Moreton ha scritto: Someone pointed out that if you perform "(x shl 8) shr 8", where x is of type Word, the result is always x, even though logic dictates that the upper 8 bits should be shifted out and hence the result actually be equal to "x and $FF". IMHO log

Re: [fpc-devel] Unexpected behaviour with intermediate results

2018-06-12 Thread J. Gareth Moreton
I will add though that Delphi apparently does the same thing, so if any changes are made so precision is lost as expected (even though loss of precision is usually not a desired trait), it shouldn't occur under -mDelphi. Personally I'm under the opinion that precision should be lost because that