Re: [fpc-devel] Class field reordering

2012-07-16 Thread michael . vancanneyt
On Sun, 15 Jul 2012, Martin Schreiber wrote: On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote: On Sun, 15 Jul 2012, Martin Schreiber wrote: Currently I need access to the following private FCL class fields because of MSEide+MSEgui extensions: I have looked at your list. (I sent

[fpc-devel] About tests/tbf/tb0002.pp

2012-07-16 Thread Sergei Gorelkin
Hello, tests/tbf/tb0002.pp is intended to fail, but currently it fails because the VMT symbol (VMT_$P$PROGRAM_$$_TA) is unresolved while linking. Shouldn't compiler detect usage of typeof() on an object type without VMT and report error at compile stage instead? Sergei

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Skybuck Flying
-Original Message- From: Jonas Maebe Sent: Sunday, July 15, 2012 15:49 To: FPC developers' list Subject: Re: [fpc-devel] Class field reordering On 14 Jul 2012, at 14:16, Skybuck Flying wrote: I don't think this is a good idea. For example while debugging and looking at the memory

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Sven Barth
Am 14.07.2012 01:45 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: Hi, I've implemented an optimization that reorders the instance fields of Delphi-style classes (and only of Delphi-style classes) to minimise memory gaps caused by alignment differences and odd sizes. The effect is the same as

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Jonas Maebe
On 16 Jul 2012, at 09:22, Skybuck Flying wrote: -Original Message- From: Jonas Maebe Sent: Sunday, July 15, 2012 15:49 To: FPC developers' list Subject: Re: [fpc-devel] Class field reordering On 14 Jul 2012, at 14:16, Skybuck Flying wrote: I don't think this is a good idea.

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Jonas Maebe
On 16 Jul 2012, at 13:14, Sven Barth wrote: does this optimization also apply on systems that require proper alignment for memory accesses? Well, yes, otherwise the optimization would simply consist of removing all alignment padding and there would be no need to reorder the fields.

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Mattias Gaertner
On Mon, 16 Jul 2012 09:35:16 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] TComponent, TWriter, TReader for example because in MSEide+MSEgui one can place additional components in an inserted tframe and combination of inherited frames and inherited forms need special handling.

Re: [fpc-devel] Class field reordering

2012-07-16 Thread michael . vancanneyt
On Mon, 16 Jul 2012, Mattias Gaertner wrote: On Mon, 16 Jul 2012 09:35:16 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] TComponent, TWriter, TReader for example because in MSEide+MSEgui one can place additional components in an inserted tframe and combination of inherited frames and

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Nico Erfurth
On 16.07.12 09:22, Skybuck Flying wrote: I also wonder how much of an optimization it actually is ? Maybe 0.01% more performance ? Cache related optimizations are VERY hard to measure and depend on overall context and used architecture. But as the L1-cache is one of the most performance

Re: [fpc-devel] About tests/tbf/tb0002.pp

2012-07-16 Thread Jonas Maebe
On 16 Jul 2012, at 11:58, Sergei Gorelkin wrote: tests/tbf/tb0002.pp is intended to fail, but currently it fails because the VMT symbol (VMT_$P$PROGRAM_$$_TA) is unresolved while linking. Shouldn't compiler detect usage of typeof() on an object type without VMT and report error at compile

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Martin Schreiber
On Monday 16 July 2012 14:08:23 Mattias Gaertner wrote: On Mon, 16 Jul 2012 09:35:16 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] TComponent, TWriter, TReader for example because in MSEide+MSEgui one can place additional components in an inserted tframe and combination of

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Martin Schreiber
On Monday 16 July 2012 09:35:16 michael.vancann...@wisa.be wrote: The DB components mainly because MSEgui stores string fields as UnicodeString in datasets and because of the direct data access by index without scrolling. So you take away the concept of cursor. That is a radical change.

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Mattias Gaertner
On Mon, 16 Jul 2012 16:18:49 +0200 Martin Schreiber mse00...@gmail.com wrote: On Monday 16 July 2012 14:08:23 Mattias Gaertner wrote: On Mon, 16 Jul 2012 09:35:16 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] TComponent, TWriter, TReader for example because in

Re: [fpc-devel] Class field reordering

2012-07-16 Thread michael . vancanneyt
On Mon, 16 Jul 2012, Martin Schreiber wrote: On Monday 16 July 2012 09:35:16 michael.vancann...@wisa.be wrote: The DB components mainly because MSEgui stores string fields as UnicodeString in datasets and because of the direct data access by index without scrolling. So you take away the

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Martin Schreiber
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote: Well, from your code adding the following to the protected section: Property ValueBuffer : Pointer Read FValueBuffer; Property Validating : Boolean Read FValidating ; Should be enough to remove the need for the

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Martin Schreiber
On Monday 16 July 2012 16:49:24 Mattias Gaertner wrote: AFAIK inheriting forms with nested frame with nested frame works in Lazarus. Some years ago I fixed a bug which only appeared at 5 level depth. TReader/Writer does not know about forms/frames/datamodules, so I guess it should work for

Re: [fpc-devel] Class field reordering

2012-07-16 Thread michael . vancanneyt
On Mon, 16 Jul 2012, Martin Schreiber wrote: On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote: Well, from your code adding the following to the protected section: Property ValueBuffer : Pointer Read FValueBuffer; Property Validating : Boolean Read FValidating ;

Re: [fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

2012-07-16 Thread Konstantin
Sven Barth schrieb: Am 11.07.2012 16:36, schrieb Konstantin: Hello! Free Pascal has been designed to run on several platforms on many architectures which is a neat feature. The executable name is chosen accordingly - ppc386, ppcx64 etc. to be able to have many at the same time on the same

Re: [fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

2012-07-16 Thread Jonas Maebe
On 17 Jul 2012, at 00:36, Konstantin wrote: The bad thing is that these paths are determined by the FPC function librarysearchpath.FindFile and as this function does not honor the target architecture. It always returns /usr/lib/. as the default architecture version of these files is

Re: [fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

2012-07-16 Thread Sergei Gorelkin
17.07.2012 2:51, Jonas Maebe пишет: On 17 Jul 2012, at 00:36, Konstantin wrote: The bad thing is that these paths are determined by the FPC function librarysearchpath.FindFile and as this function does not honor the target architecture. It always returns /usr/lib/. as the default

Re: [fpc-devel] Class field reordering

2012-07-16 Thread Martin Schreiber
On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote: On Mon, 16 Jul 2012, Martin Schreiber wrote: On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote: Well, from your code adding the following to the protected section: Property ValueBuffer : Pointer Read