Re: [fpc-devel] "Blank slate" next version of FPC

2019-02-25 Thread Michael Schnell
> The compiler already supports keeping records in registers under the same > conditions, but only up to a certain size (two native registers) and only > using the > same layout as they would have in memory (so no explicit splitting out fields > into separate registers). Using record fields as

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread J. Gareth Moreton
Well, compiling Lazarus is what I've been doing to test the compiler's speed, and I've got some promising results: https://bugs.freepascal.org/view.php?id=34628#c114453 Though the speed of the runs varies a lot depending on what my system is doing, especially when I switch back and forth

Re: [fpc-devel] Implicit cast from Char/String to array of Char

2019-02-25 Thread Sven Barth via fpc-devel
Am 25.02.2019 um 08:09 schrieb Ondrej Pokorny: Hello! Implicit cast from Char/String to array of Char: is this a wanted behavior or is it a compiler bug? (Btw. MODE DELPHI behaves the same). program Project1; {$mode objfpc}{$H+} procedure A(AC: array of Char); var   C: Char; begin   for C

Re: [fpc-devel] TRegistry and Unicode

2019-02-25 Thread Michael Van Canneyt
On Mon, 25 Feb 2019, Bart wrote: Hi, I'm currently involved in some TRegistry bugs and regressions. Personally I don't use TRegistry in any of my programs. Also I mostly use Lazarus, so most most of the issues don't affect me. However I would like to share som observations and thoughts.

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread Sven Barth via fpc-devel
J. Gareth Moreton schrieb am Mo., 25. Feb. 2019, 19:14: > The compiler isn't a valid case because the input source is different > (because of the very changes made to said compiler). It needs to be a > project that doesn't share anything with the compiler (except the run-time > libraries), so

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread Ondrej Pokorny
On 25.02.2019 19:16, Ondrej Pokorny wrote: On 25.02.2019 18:12, J. Gareth Moreton wrote: The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler).  It needs to be a project that doesn't share anything with the compiler (except

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread Ondrej Pokorny
On 25.02.2019 18:12, J. Gareth Moreton wrote: The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler). It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread J. Gareth Moreton
The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler).  It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is exactly the same so that when it is built, it

Re: [fpc-devel] Good timing metric test program?

2019-02-25 Thread Marco van de Voort
Op 2019-02-25 om 14:52 schreef J. Gareth Moreton: Given my recent work with the peephole optimizer, one thing that sprung to mind is that I don't have a project that tests for performance gains in a 'real world' program, where little optimisations add up over time.  Given that my x86-64

[fpc-devel] TRegistry and Unicode

2019-02-25 Thread Bart
Hi, I'm currently involved in some TRegistry bugs and regressions. Personally I don't use TRegistry in any of my programs. Also I mostly use Lazarus, so most most of the issues don't affect me. However I would like to share som observations and thoughts. TRegistry on Windows now (3.2+) uses

[fpc-devel] Good timing metric test program?

2019-02-25 Thread J. Gareth Moreton
Hi everyone, Given my recent work with the peephole optimizer, one thing that sprung to mind is that I don't have a project that tests for performance gains in a 'real world' program, where little optimisations add up over time.  Given that my x86-64 optimizer overhaul is rather substantial and