Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

- Original Message - 
From: "Florian Klaempfl" <[EMAIL PROTECTED]>

To: "FPC developers' list" 
Sent: Saturday, May 28, 2005 11:20 PM
Subject: Re: [fpc-devel] don't you think it'stime 
toupdatedelphimodecompatibility? - IDispatch, implements




Besides I find that FPC 2.0 makes the executables just to big.+


C:\fpc>type test1.pp
begin
 writeln('Hello world');
end.
...
28.05.2005  23:1425.600 test1.exe
28.05.2005  23:1411.264 test1.exe
...
IIRC Delphi creates 16 kB something.


And did you try UPX on delphi-created executables? You cannot compare 
something that's not compressed with something that IS compressed - that 
makes no sense.
Other thing is that the Hello, world! app is NOT using anything. As far as I 



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

- Original Message - 
From: "Florian Klaempfl" <[EMAIL PROTECTED]>

To: "FPC developers' list" 
Sent: Saturday, May 28, 2005 11:20 PM
Subject: Re: [fpc-devel] don't you think it'stime
toupdatedelphimodecompatibility? - IDispatch, implements



Besides I find that FPC 2.0 makes the executables just to big.+


C:\fpc>type test1.pp
begin
 writeln('Hello world');
end.
...
28.05.2005  23:1425.600 test1.exe
28.05.2005  23:1411.264 test1.exe
...
IIRC Delphi creates 16 kB something.


And did you try UPX on delphi-created executables? You cannot compare 
something that's not compressed with something that IS compressed - that 
makes no sense.
Other thing is that the Hello, world! app is NOT using anything. AFAIK this 
is not the way the apps are written :). Normally you will link the SysUtils, 
Classes, and under windows the Windows unit what makes the whole thing a lot 
bigger than under Delphi. A simple app that's using SysUtuils under FPC is 
2x the size of the same app compiled with delphi. The other example is the 
Classes unit. I agree, that after using UPX the code differs only 10% (FPC 
is still 10% bigger) but using UPX is not recomended ie. for DLLs. Going on 
with this and compiling the simplies FCL-based application differs really 
strongly from the same done under delphi. I know you can do all of the GUI 
thing using base interface for GUI (Win32 API for example) but this doesn't 
solve prtability issues. I don't like my executables grow beyond some 
certain point and achieving this point after adding 10 controls to my GUI 
app is not acceptable. In addition comparing the sources of VCL and FCL they 
don't differ that much and the source isn't that much bigger so by this kind 
of differences the problem must lie with compiler/linker.


Matthias





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2004, at 12:21, Matthias Hryniszak wrote:

 In addition comparing the sources of VCL and FCL they don't differ  
that much and the source isn't that much bigger so by this kind of  
differences the problem must lie with compiler/linker.


Have you tried using smart linking? (-XX)


Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Daniël Mantione]

Op Sat, 29 May 2004, schreef Matthias Hryniszak:

> In addition comparing the sources of VCL and FCL they
> don't differ that much and the source isn't that much bigger so by this kind
> of differences the problem must lie with compiler/linker.

It *is* the source. The compiler is perfectly capapable of removing unused
code ust as well as the Delphi compiler. So, if you're pointing at the
compiler I assume you either have smartlinking disabled or that there is
debug information in the executable.

However, not much time has been spent to make sysutils, classes etc.
smaller. This effort has been done on the system unit in the past, which
can explain the difference.

But then again, while I don't use the FCL very much, if have not yet seen
examples of unacceptable sizes yet.

Daniël


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stimetoupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

- Original Message - 
From: "Daniël Mantione" <[EMAIL PROTECTED]>

To: "FPC developers' list" 
Sent: Sunday, May 29, 2005 12:30 PM
Subject: Re: [fpc-devel] don't you think 
it'stimetoupdatedelphimodecompatibility? - IDispatch, implements





Op Sat, 29 May 2004, schreef Matthias Hryniszak:


In addition comparing the sources of VCL and FCL they
don't differ that much and the source isn't that much bigger so by this 
kind

of differences the problem must lie with compiler/linker.



But then again, while I don't use the FCL very much, if have not yet seen
examples of unacceptable sizes yet.


Try it and then you'll see what I am talking about.. the 1.5Mb for hello, 
world app is really not acceptable.


Matthias.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] fpc smartlinking

[Mattias Gaertner]

On Sun, 29 May 2005 12:30:50 +0200 (CEST)
Daniël Mantione <[EMAIL PROTECTED]> wrote:

> 
> 
> Op Sat, 29 May 2004, schreef Matthias Hryniszak:
> 
> > In addition comparing the sources of VCL and FCL they
> > don't differ that much and the source isn't that much bigger so by this
> > kind of differences the problem must lie with compiler/linker.
> 
> It *is* the source. The compiler is perfectly capapable of removing unused
> code ust as well as the Delphi compiler. So, if you're pointing at the
> compiler I assume you either have smartlinking disabled or that there is
> debug information in the executable.

I'm curious:
I heard that Delphi is capable of removing some unused virtual methods. What
kind of virtual methods can FPC/ld smartlink and what not?


Mattias

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jamie McCracken]

Daniël Mantione wrote:


Op Sat, 29 May 2004, schreef Matthias Hryniszak:



In addition comparing the sources of VCL and FCL they
don't differ that much and the source isn't that much bigger so by this kind
of differences the problem must lie with compiler/linker.



It *is* the source. The compiler is perfectly capapable of removing unused
code ust as well as the Delphi compiler. So, if you're pointing at the
compiler I assume you either have smartlinking disabled or that there is
debug information in the executable.

However, not much time has been spent to make sysutils, classes etc.
smaller. This effort has been done on the system unit in the past, which
can explain the difference.

But then again, while I don't use the FCL very much, if have not yet seen
examples of unacceptable sizes yet.



There are too many variables here to conclude decisively what is causing 
it to be much bigger.


Some things that will affect executable size include:

1) Over zealous use of inlining (I dont see a command option to control 
how much inlining is done)
2) Pascal variables not making efficient use of registers. This causes 
more load/store instructions to be generated than is needed (also 
produces less optimal code!)

3) Delphi includes a fair amount of assembler in its rtl.


You should also compare FPC smartlinking with the equivalent in the Gnu 
linker (dead code elimantion?) to see if there really is a difference.


jamie.




Daniël


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

- Original Message - 
From: "Jamie McCracken" <[EMAIL PROTECTED]>

To: "FPC developers' list" 
Sent: Sunday, May 29, 2005 12:55 PM
Subject: Re: [fpc-devel] don't you thinkit'stime 
toupdatedelphimodecompatibility? - IDispatch, implements




Daniël Mantione wrote:


Op Sat, 29 May 2004, schreef Matthias Hryniszak:

It *is* the source. The compiler is perfectly capapable of removing 
unused

code ust as well as the Delphi compiler. So, if you're pointing at the
compiler I assume you either have smartlinking disabled or that there is
debug information in the executable.


I don't get it. Let's try this example:

program Hello;
{$APPTYPE CONSOLE}
uses
 Classes, SysUtils;
procedure Test1(Param1: String; Param2: Integer; Param3: Char; Param4: 
Word);

var
 I: Integer;
 L: TList;
begin
 L := TList.Create;
 for I := 1 to 1000 do
   L.Add(Pointer(I));
 L.Free;
end;

begin
 Writeln('Hello, world!');
end.

Here you see a test procedure that's NOT called. with FPC 2.0 the executable 
file is 133120 long. Ok, let's turn this into the standard Hello, world! app 
and just leave the two useses be:


program Hello;
{$APPTYPE CONSOLE}
uses
 Classes, SysUtils;
begin
 Writeln('Hello, world!');
end.

And what do we have? 132608 executable. AFAIK 132608 is not the same as 
133120 so there MUST BE a problem with eliminating dead/unused code.


Matthias 



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2004, at 13:05, Matthias Hryniszak wrote:

Here you see a test procedure that's NOT called. with FPC 2.0 the  
executable file is 133120 long. Ok, let's turn this into the  
standard Hello, world! app and just leave the two useses be:


program Hello;
{$APPTYPE CONSOLE}
uses
 Classes, SysUtils;
begin
 Writeln('Hello, world!');
end.

And what do we have? 132608 executable. AFAIK 132608 is not the  
same as 133120 so there MUST BE a problem with eliminating dead/ 
unused code.


If you want dead code to be stripped from your own written code, you  
must turn on the generation of smartlinkable code (-CX), and of  
course also smartlinking (-XX)



Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc smartlinking

[Peter Vreman]

I heard that Delphi is capable of removing some unused virtual methods. What
kind of virtual methods can FPC/ld smartlink and what not?


None

Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Peter Vreman]

At 12:55 29-5-2005, you wrote:

Daniël Mantione wrote:

Op Sat, 29 May 2004, schreef Matthias Hryniszak:


In addition comparing the sources of VCL and FCL they
don't differ that much and the source isn't that much bigger so by this kind
of differences the problem must lie with compiler/linker.


It *is* the source. The compiler is perfectly capapable of removing unused
code ust as well as the Delphi compiler. So, if you're pointing at the
compiler I assume you either have smartlinking disabled or that there is
debug information in the executable.
However, not much time has been spent to make sysutils, classes etc.
smaller. This effort has been done on the system unit in the past, which
can explain the difference.
But then again, while I don't use the FCL very much, if have not yet seen
examples of unacceptable sizes yet.



There are too many variables here to conclude decisively what is causing 
it to be much bigger.


Some things that will affect executable size include:

1) Over zealous use of inlining (I dont see a command option to control 
how much inlining is done)


There is almost none in the rtl.

2) Pascal variables not making efficient use of registers. This causes 
more load/store instructions to be generated than is needed (also produces 
less optimal code!)


Use -Or. But don't think that it always generates less code. Sometimes the 
code is bigger on i386 because you get extra load/store operations for 
registers esi,edi,ebx that need to be preserved between function calls.




3) Delphi includes a fair amount of assembler in its rtl.


You should also compare FPC smartlinking with the equivalent in the Gnu 
linker (dead code elimantion?) to see if there really is a difference.


The only way to get better smartlinking is to build an integrated linker in 
the compiler. That way we can control everything.



Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't youthinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

- Original Message - 
From: "Jonas Maebe" <[EMAIL PROTECTED]>

To: "FPC developers' list" 
Sent: Sunday, May 29, 2005 1:10 PM
Subject: Re: [fpc-devel] don't youthinkit'stime 
toupdatedelphimodecompatibility? - IDispatch, implements





On 29 May 2004, at 13:05, Matthias Hryniszak wrote:

Here you see a test procedure that's NOT called. with FPC 2.0 the 
executable file is 133120 long. Ok, let's turn this into the  standard 
Hello, world! app and just leave the two useses be:


program Hello;
{$APPTYPE CONSOLE}
uses
 Classes, SysUtils;
begin
 Writeln('Hello, world!');
end.

And what do we have? 132608 executable. AFAIK 132608 is not the  same as 
133120 so there MUST BE a problem with eliminating dead/ unused code.


If you want dead code to be stripped from your own written code, you  must 
turn on the generation of smartlinkable code (-CX), and of  course also 
smartlinking (-XX)


Of course I've done that already - it didn't help! That's why I suggest this 
is a bug. Delphi removes my procedure and leaves the executable size like it 
should be (86400b).


Matthias.

PS. Try to compile it yourself and if you'll come to the sitiation when both 
examples compile to the same size I'll be glad to hear how did you do that.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Matthias Hryniszak]

The only way to get better smartlinking is to build an integrated linker 
in the compiler. That way we can control everything.


Might it be possible to keep a recerence counter for procedures/methods 
while compiling them and then not to include them in the objects that are 
passed to the linker? I know it sounds semi-serious, but maby that's the 
easiest way to go around the linker-problem and be linker-independent.


Matthias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jamie McCracken]

Some things that will affect executable size include:

1) Over zealous use of inlining (I dont see a command option to 
control how much inlining is done)



There is almost none in the rtl.


Doesn't the compiler attempt to inline small functions/methods 
automatically as part of its optimisation (even if the inline directive 
is not specified)?





The only way to get better smartlinking is to build an integrated linker 
in the compiler. That way we can control everything.


Or have more static stuff. It should be possible for the compiler to 
unbox some classes (like .Net with its boxing/unboxing optimiser) into 
more static stuff.


jamie.





Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2005, at 13:26, Jamie McCracken wrote:


There is almost none in the rtl.


Doesn't the compiler attempt to inline small functions/methods  
automatically as part of its optimisation (even if the inline  
directive is not specified)?


No.


Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2004, at 13:19, Matthias Hryniszak wrote:

Might it be possible to keep a recerence counter for procedures/ 
methods while compiling them and then not to include them in the  
objects that are passed to the linker? I know it sounds semi- 
serious, but maby that's the easiest way to go around the linker- 
problem and be linker-independent.


With -CX -XX, the linker does all the work for us (at least on  
platforms where the generation of smartlinkable code is supported by  
the compiler, and those definitely include Win32, Dos and Linux/x86  
-- it does not yet work under e.g. Mac OS X).



Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Peter Vreman]

There is almost none in the rtl.


Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisation (even if the inline
directive is not specified)?


No.


The inline directive is only a hint to the compiler. The behaviour is the 
same in D2005.



Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2005, at 13:41, Peter Vreman wrote:


Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisation (even if the inline
directive is not specified)?


No.


The inline directive is only a hint to the compiler. The behaviour  
is the same in D2005.


Yes, but the poster was asking whether the compiler never decided by  
itself to inline something (even if no "inline" directive was  
specified). That's not the case currently.



Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't youthinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Florian Klaempfl]

Matthias Hryniszak wrote:
>> If you want dead code to be stripped from your own written code, you 
>> must turn on the generation of smartlinkable code (-CX), and of 
>> course also smartlinking (-XX)
> 
> 
> Of course I've done that already - it didn't help! That's why I suggest
> this is a bug. Delphi removes my procedure and leaves the executable
> size like it should be (86400b).

Well, 132k agaist 86k. That's the price for the portable rtl and usually
faster code.

> 
> Matthias.
> 
> PS. Try to compile it yourself and if you'll come to the sitiation when
> both examples compile to the same size I'll be glad to hear how did you
> do that.

Nobody said that the same size can be reached, but I don't consider 132k
against 86k as a real problem. If you consider it as a problem, use Delphi.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?- IDispatch, implements

[Matthias Hryniszak]

Nobody said that the same size can be reached, but I don't consider 132k
against 86k as a real problem. If you consider it as a problem, use 
Delphi.


That's not what I ment. I see a problem with a GUI app that's using FCL. 
This apps are really of size that's not acceptable. That's why I started to 
learn win32-api to create GUI apps cause that what comes out of FPC+FCL is 
just to big.


132kb and 86bk is abosutely no problem. In addition, UPX -9 makes the 
difference much smaller (about 4kb) so it's not the problem. Is there 
something that could make the GUI app with FCL also within reasonable size?


Regards,
Matthias. 



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jamie McCracken]

Jonas Maebe wrote:


On 29 May 2005, at 13:41, Peter Vreman wrote:


Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisation (even if the inline
directive is not specified)?



No.



The inline directive is only a hint to the compiler. The behaviour  is 
the same in D2005.



Yes, but the poster was asking whether the compiler never decided by  
itself to inline something (even if no "inline" directive was  
specified). That's not the case currently.


well thats soemthing you should add to your to do list. Automatic 
inlining can deliver a signifcant performance improvement especially as 
delphi uses a lot of one line procedures to set property values. A 
fucntion call adds quite a bit of overhead (around 10+ clock cycles at a 
guess)


jamie.







Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?- IDispatch, implements

[Florian Klaempfl]

Matthias Hryniszak wrote:

>> Nobody said that the same size can be reached, but I don't consider 132k
>> against 86k as a real problem. If you consider it as a problem, use
>> Delphi.
> 
> 
> That's not what I ment. I see a problem with a GUI app that's using FCL.
> This apps are really of size that's not acceptable. That's why I started
> to learn win32-api to create GUI apps cause that what comes out of
> FPC+FCL is just to big.

The FCL is non visual? You mean the LCL? I don't know if you can do much
about it. The OOP design of the LCL makes smartlinking impossible.

> 
> 132kb and 86bk is abosutely no problem. In addition, UPX -9 makes the
> difference much smaller (about 4kb) so it's not the problem. Is there
> something that could make the GUI app with FCL also within reasonable size?
> 
> Regards,
> Matthias.
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jonas Maebe]

On 29 May 2005, at 14:03, Jamie McCracken wrote:


well thats soemthing you should add to your to do list.


There are plenty of things on our todo list already to keep us  
busy :) We've already talked about automatic inlining in the past,  
but nobody has spent time on it yet afaik.



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?-IDispatch, implements

[Matthias Hryniszak]

The FCL is non visual? You mean the LCL? I don't know if you can do much
about it. The OOP design of the LCL makes smartlinking impossible.


Yes, of course I ment LCL.. sorry.

Matthias.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Peter Vreman]

At 14:03 29-5-2005, you wrote:

Jonas Maebe wrote:

On 29 May 2005, at 13:41, Peter Vreman wrote:


Doesn't the compiler attempt to inline small functions/methods
automatically as part of its optimisation (even if the inline
directive is not specified)?



No.



The inline directive is only a hint to the compiler. The behaviour  is 
the same in D2005.


Yes, but the poster was asking whether the compiler never decided by
itself to inline something (even if no "inline" directive was
specified). That's not the case currently.


well thats soemthing you should add to your to do list. Automatic inlining 
can deliver a signifcant performance improvement especially as delphi uses 
a lot of one line procedures to set property values. A fucntion call adds 
quite a bit of overhead (around 10+ clock cycles at a guess)


But inlining doesn't help if the one line procedures are virtual methods. 
So this automatic inlining is a low priority issue.


Note that real world applications also don't benefit from optimizations. 
Therefor effort in creating optimizations can currently better be invested 
in better maintainability and extendability of the compiler and adding new 
features.




Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Jamie McCracken]

well thats soemthing you should add to your to do list. Automatic 
inlining can deliver a signifcant performance improvement especially 
as delphi uses a lot of one line procedures to set property values. A 
fucntion call adds quite a bit of overhead (around 10+ clock cycles at 
a guess)



But inlining doesn't help if the one line procedures are virtual 
methods. 


Well thats not a limitation on other languages. EG for Java the get/set 
property methods were identified as causing one of the biggest 
performance hits and thats why now almost every JIT/AOT inlines them 
automatically (the same also applies to Mono).


jamie.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Florian Klaempfl]

Jamie McCracken wrote:

>>> well thats soemthing you should add to your to do list. Automatic
>>> inlining can deliver a signifcant performance improvement especially
>>> as delphi uses a lot of one line procedures to set property values. A
>>> fucntion call adds quite a bit of overhead (around 10+ clock cycles
>>> at a guess)
>>
>>
>>
>> But inlining doesn't help if the one line procedures are virtual methods. 
> 
> 
> Well thats not a limitation on other languages. EG for Java the get/set
> property methods were identified as causing one of the biggest
> performance hits and thats why now almost every JIT/AOT inlines them

They are basically interpreted languages which suck anyways:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=gcc&lang2=java&sort=fullcpu

> automatically (the same also applies to Mono).

Even against FPC it doesn't help java much:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=java&lang2=fpascal&sort=fullcpu

> 
> jamie.
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Bug in FPC 2.0.0

[Heinz-Werner Drechsel]

Hello,

I want to report a bug I've found just after I had installed
new 2.0.0 compiler. I tried to compile a function, which was
compiled with version 1.9.8 without any errors. The unit uses
the procedure "GetHeapStatus(var status: THeapStatus)". On
compiling the compiler says "Wrong number of parameters
specified".

Greetings

Heinz-Werner Drechsel


Heinz-Werner Drechsel
Berliner Ring 23
D-71522 Backnang
Phone: (+49) 7191 979176
eMail: [EMAIL PROTECTED]


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] PascalScript with FPC

[Matthias Hryniszak]

Hi there,
 
have anyone used PascalScript from RemObjects with 
freepascal? I'm interested in doing something like PSP (Pascal Server Pages i 
think) but to be able to provide pure source code on the server side instead of 
precompiled binaries. Does anyone have some expirience in that 
field?
 
Regards,
Matthias Hryniszak ([EMAIL PROTECTED]).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Cross compilation from Win32 to FreeBSD

[Matthias Hryniszak]

Hello,
 
I've downloaded the packet with as, ld aso. from 
freepascal ftp server, unpacked it and compiled th RTL (without any problems!). 
Now I want to compile a hello, world application for bsd on my Win32 box. I've 
found the compiler switch -Tfreebsd, used it and the content of generated file 
looks like a win32 app! Also, the linker tells me that
 
X:\fpc\bin\i386-win32\ld.exe: warning: cannot find 
entry symbol _mainCRTStartup; defaulting to 00401000
 
AFAICS the problem lies with the bad linker being 
called (it should be i386-freebsd-ld.exe and not ld.exe).
How do I make cross-compilation work?
 
Matthias.
 
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Error..

[Matthias Hryniszak]

Hi,can anyone tell me why most of the messages I send to this list 
end-up with a "host is blacklisted" return 
message?Matthias.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: removed MaxAvail,MemAvail,HeapSize

[DSTRODT]

In a message dated 5/23/2005 5:00:24 A.M. Central Daylight Time, Peter 
Vreman writes:
{$ifdef 
  fpc}const 
memavail=high(ptrint);maxavail=high(ptrint);{$endif}

Peter, you are, indeed, a brilliant man!!! There is true beauty in 
simplicity.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] [Mensagem Automatica] Recebi Seu E-mail

[YURI S .]

Mensagem [[Spam] DUVIDO VOCE ME RECONHER =)] recebida.

Recebi seu e-mail e assim que posível entrarei em contato!

Tks,
Yuri Surzynskyj

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Patch for bug 3774

[Sterling Bates]

In reply to Thomas Schatzl:
 
Another optimization for your patch is to set a var to length(s) at the beginning of the proc, and use the var instead.  It's called often enough that a little time could be shaved off.Post your free ad now! Yahoo! Canada Personals___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] for cycle variable

[Rimgaudas Laucius]

Hi,
 
i found 
that in fpc 1.9.6 assignment to "for cycle" variable is forbidden. Such behavior 
is incompatible with other compilers. Earlier fpc versions also had only 
warning. What do you think about this? 
 
var  i: integer;begin  for 
i:= 1 to 2 do    inc(i);end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Patch for bug 2453

[Sterling Bates]

In response to Tomas Hajny:
 
I wasn't entirely certain about the use of EOF_CTRLZ, but since it's a conditional compile, and the patch is in an include, I felt it better to use it than ignore it :)
 
I agree regarding ReadNumeric.  That one will need some work.
 
Thanks,
 
Sterling
 
 
Your message below:
--
The EOF part looks correctly to me (although I didn't check whether there aren't other places where the check should be added too). The current behaviour when the character is recognized in Eof function (depending on EOF_CTRLZ conditional), but not otherwise, isn't very consistent, IMHO. However, let's wait what other core team members would think about it.
 
Regarding function ReadNumeric, I think there's at least one open issue there, and that's missing handling of 'e' (or 'E') character for exponent. I'm not sure whether there are any other allowed characters, but at least this one should be supported.Post your free ad now! Yahoo! Canada Personals___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for cycle variable

[Florian Klaempfl]

Rimgaudas Laucius wrote:

> Hi,
> 
>  
> 
> i found that in fpc 1.9.6 assignment to "for cycle" variable is
> forbidden. Such behavior is incompatible with other compilers. 

As ...?

> Earlier
> fpc versions also had only warning. What do you think about this?

Well, what we think should be clear ;)

> 
>  
> var
>   i: integer;
> begin
>   for i:= 1 to 2 do
> inc(i);
> end.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Fwd: bug report

[杨哲]

fpc 2.0.0 win32
problem:
  I can't see pi in proceudre pre but I can see it in procedure kmp.
  pre is a procedure belonging to kmp.
  I found that I could only see  vars in this proceudre/function and main program, but I couldn't see vars in the procedure that this procedure belongs to.
 
code:
 
var  t,p:string;procedure kmp(t,p:string);  var    n,m,q,i:integer;    pi,match:array[1..255] of integer;  procedure pre(p:string);    var  k,q:integer;    begin  pi[1]:=0;  k:=0;  for q:=2 to m do begin    while (k>0) and (p[k+1]<>p[q]) do k:=pi[k];    if p[k+1]=p[q] then k:=k+1;    pi[q]:=k;  end;    end;  begin    n:=length(t);    m:=length(p);    q:=0;    pre(p);    fillchar(match,sizeof(match),0);    for i:=1 to n do
 begin  while (q>0) and (p[q+1]<>t[i]) do begin    match[i-q]:=q;    q:=pi[q];  end;  if p[q+1]=t[i] then q:=q+1;  if q=m then begin    match[i-q+1]:=q;    q:=pi[q];  end;    end;    write(match[1]);    for i:=2 to n do write(' ',match[i]);    writeln;  end;begin  readln(t);  readln(p);  kmp(t,p);end.[EMAIL PROTECTED]杨哲Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] updated errord.msg File (140k)

[Florian Klaempfl]

Karl-Michael Schindler wrote:

> Hi,
> 
> I worked on the German error file errord.msg using msgdif and
> errore.msg,v 1.124 as reference.
> The differences should be fixed and a few additional messages have been
> translated.
> Still 138 items to translate.
> 
> Since this is my first go at this, maybe this should be checked
> carefully. :)

Checked and commited.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] system time/date

[rstar]

Hi folks!

Some newsgroup posters have wrong system time/date on their PC's.
Thus the emails are being sorted wrong. This script would help
on Windows PC:

@echo off
net time /setsntp:ptbtime1.ptb.de
w32tm -once



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] system time/date

[Jonas Maebe]

On 29 May 2005, at 15:54, [EMAIL PROTECTED] wrote:


Some newsgroup posters have wrong system time/date on their PC's.


No, a number of posts were held for approval for a long time and were  
only now let through to the mailing list. To avoid this, turn off  
html posting and always post with the address you are subscribed with.



Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Error..

[Tomas Hajny]

From:   "Matthias Hryniszak" <[EMAIL PROTECTED]>
To: "FPC developers' list" 
Date sent:  Sat, 29 May 2004 12:56:44 +0200
Subject:[fpc-devel] Error..
Send reply to:  FPC developers' list 




Hi

> can anyone tell me why most of the messages I send to this list end-up
> with a "host is blacklisted" return message?

The SMTP server you use for sending e-mail is used for sending SPAM 
messages (e.g. because of wrong configuration allowing easy misuse by 
spammers). There should be a URL in that error message - check there 
what to do about that situation (or forward it to the administrator 
of your e-mail server).

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Error..

[Tomas Hajny]

From:   "Matthias Hryniszak" <[EMAIL PROTECTED]>
To: "FPC developers' list" 
Date sent:  Sat, 29 May 2004 12:56:44 +0200
Subject:[fpc-devel] Error..
Send reply to:  FPC developers' list 




Hi

> can anyone tell me why most of the messages I send to this list end-up
> with a "host is blacklisted" return message?

The SMTP server you use for sending e-mail is used for sending SPAM 
messages (e.g. because of wrong configuration allowing easy misuse by 
spammers). There should be a URL in that error message - check there 
what to do about that situation (or forward it to the administrator 
of your e-mail server).

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PascalScript with FPC

[Michael Van Canneyt]

On Sat, 28 May 2005, Matthias Hryniszak wrote:

> Hi there,
> 
> have anyone used PascalScript from RemObjects with freepascal? I'm interested 
> in doing something like PSP (Pascal Server Pages i think) but to be able to 
> provide pure source code on the server side instead of precompiled binaries. 
> Does anyone have some expirience in that field?

The predecessor of PascalScript (Innerfuse Pascal) used to compile with FPC,
so I guess it shouldn't be too hard to make it work, maybe except for some of 
the
assembler routines.

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?- IDispatch, implements

[Marco van de Voort]

yy[ Charset ISO-8859-1 unsupported, converting... ]
> > Nobody said that the same size can be reached, but I don't consider 132k
> > against 86k as a real problem. If you consider it as a problem, use 
> > Delphi.
> 
> That's not what I ment. I see a problem with a GUI app that's using FCL. 
> This apps are really of size that's not acceptable.

1. To who?
2. And why?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements

[peter green]

exe size is significant if you wan't to get your apps good reviews on
freeware sites etc.

thats why people use upx in the first place. its all about perception.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marco van de
> Voort
> Sent: 29 May 2005 20:08
> To: FPC developers' list
> Subject: Re: [fpc-devel]don't
> youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements
>
>
> yy[ Charset ISO-8859-1 unsupported, converting... ]
> > > Nobody said that the same size can be reached, but I don't
> consider 132k
> > > against 86k as a real problem. If you consider it as a problem, use
> > > Delphi.
> >
> > That's not what I ment. I see a problem with a GUI app that's
> using FCL.
> > This apps are really of size that's not acceptable.
>
> 1. To who?
> 2. And why?
>
>
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PascalScript with FPC

[Peter Vreman]

At 18:19 28-5-2005, you wrote:

Hi there,

have anyone used PascalScript from RemObjects with freepascal? I'm 
interested in doing something like PSP (Pascal Server Pages i think) but 
to be able to provide pure source code on the server side instead of 
precompiled binaries. Does anyone have some expirience in that field?


FPC can compile it for a large part. In the past the author has added 
support to be able to compile with FPC. But with later changes it wasn't 
done anymore. It shouldn't be hard to fix that also.



Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] updated errord.msg File (140k)

[Florian Klaempfl]

Karl-Michael Schindler wrote:

> Hi,
> 
> I worked on the German error file errord.msg using msgdif and
> errore.msg,v 1.124 as reference.
> The differences should be fixed and a few additional messages have been
> translated.
> Still 138 items to translate.
> 
> Since this is my first go at this, maybe this should be checked
> carefully. :)
> 
> Michael, aka mischi

Applied.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements

[L505]

| yy[ Charset ISO-8859-1 unsupported, converting... ]
| > > Nobody said that the same size can be reached, but I don't consider 132k
| > > against 86k as a real problem. If you consider it as a problem, use 
| > > Delphi.
| > 
| > That's not what I ment. I see a problem with a GUI app that's using FCL. 
| > This apps are really of size that's not acceptable.
| 
| 1. To who?
| 2. And why?
| 


I think the guy is mixing up LCL with FCL.


Lars aka L505
http://z505.com

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Cant link - "memory exhausted"

[Michael Preslar]

Jonas Maebe wrote:
If you want dead code to be stripped from your own written code, you  
must turn on the generation of smartlinkable code (-CX), and of  course 
also smartlinking (-XX)


First off, Im a newbie to FPC, so when I see something on the list, I 
give it a try to see how it affects my code. (And when I run into 
something I dont understand, I ask about it) Seeing the bit about -CX 
and -XX, I gave it a shot.


My command line:

fpc -va -XS -CX -XX -O3 -So -Fu~/manndoor/units 
-Fu~/manndoor/units/elecom -Fu~/manndoor/units/unix lord.pas


Everything compiles .. but then it cant link.

Searching file /bin/LD... not found
Searching file /usr/bin/ld... found
Using util /usr/bin/ld
lord.pas(1841,1) Error: Can't call the linker, switching to external linking
Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you 
did not specifiy a source file to be compiled)


(This is something thats been discussed on the list before, but no 
conclusion was achieved). ppas.sh is created, so I run that.


Without -CX, the program wont link the first time I run ppas.sh, but 
will when I run ppas.sh a second time.


With -CX, the program compiles, but wont link, ppas.sh is created. I run 
ppas.sh and it still wont link. "libpvol1.a: could not read symbols: 
Memory exhausted" ..


Whats this mean? Not enough memory available to the linker? 'top' shows 
about 44 megs free.. ("Mem:  1031620k av,  987652k used,   43968k free, 
  0k shrd,  147196k buff")


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Cant link - 'memory exhausted'

[Peter Vreman]

> Jonas Maebe wrote:
>> If you want dead code to be stripped from your own written code, you
>> must turn on the generation of smartlinkable code (-CX), and of  course
>> also smartlinking (-XX)
>
> First off, Im a newbie to FPC, so when I see something on the list, I
> give it a try to see how it affects my code. (And when I run into
> something I dont understand, I ask about it) Seeing the bit about -CX
> and -XX, I gave it a shot.
>
> My command line:
>
> fpc -va -XS -CX -XX -O3 -So -Fu~/manndoor/units
> -Fu~/manndoor/units/elecom -Fu~/manndoor/units/unix lord.pas
>
> Everything compiles .. but then it cant link.
>
> Searching file /bin/LD... not found
> Searching file /usr/bin/ld... found
> Using util /usr/bin/ld
> lord.pas(1841,1) Error: Can't call the linker, switching to external
> linking
> Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you
> did not specifiy a source file to be compiled)
>
> (This is something thats been discussed on the list before, but no
> conclusion was achieved). ppas.sh is created, so I run that.
>
> Without -CX, the program wont link the first time I run ppas.sh, but
> will when I run ppas.sh a second time.
>
> With -CX, the program compiles, but wont link, ppas.sh is created. I run
> ppas.sh and it still wont link. "libpvol1.a: could not read symbols:
> Memory exhausted" ..
>
> Whats this mean? Not enough memory available to the linker? 'top' shows
> about 44 megs free.. ("Mem:  1031620k av,  987652k used,   43968k free,
>0k shrd,  147196k buff")

ld needs a lot of memory when using smartlinking. IIRC smartlinking
lazarus requires 1Gb of memory.




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel