[fpc-devel] x86-64: MOVZX peephole optimisations

2019-03-07 Thread J. Gareth Moreton
Hi everyone, I'm a tad confused in regards to the best course of action regarding MOVZX.  Many of the peephole optimisations seek to change them to MOV followed by AND (e.g. "movzbl (mem), %eax" to "mov (mem), %al; and $0xff, %eax").  Does MOVZX have a well-documented performance penalty in moder

Re: [fpc-devel] TRegistry and Unicode

2019-03-07 Thread Bart
On Thu, Mar 7, 2019 at 6:30 PM Yuriy Sydorov wrote: > Of course if "u8" is utf8string, then then first char will be encoded as a > 2-byte pair. But if you change "u8" to be > just "string" or "ansistring", then the first byte would contain "ä" if the > current ansi code page supports it (eg cp1

Re: [fpc-devel] TRegistry and Unicode

2019-03-07 Thread Yuriy Sydorov
On 07.03.2019 18:38, Bart wrote: On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote: If you declare a function result as utf8string instead of string (ansistring) then automatic conversion will be performed when you assign the result of the function to a variable of type string (ansistring)

Re: [fpc-devel] TRegistry and Unicode

2019-03-07 Thread Bart
On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote: > If you declare a function result as utf8string instead of string (ansistring) > then automatic conversion will be > performed when you assign the result of the function to a variable of type > string (ansistring). You will gen a classic > 1