Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-05

don't you think it's time to update delphi mode compatibility?

54 messages · 17 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bisma Jayadi

FPC has great amounts of compatibility with Borland Delphi. Unfortunately, according to the FPC docs, it only supports Delphi compatibility until Delphi 4. The object pascal enhancement on the next Delphi release is still not supported by FPC.

Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which has tons of great object pascal enhancement, don't FPC developers think that now is the time to follow up the language enhancements? For example: the for..in syntax, reintroduce keyword, sub class (class field), etc.

Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC development won't go that direction yet. I'm just talking about the language enhancement here, for more code portability. Say, I'll be able to compile my Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the 'real' concept of "write once, compile everywhere". :D

Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :)

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Reply by email

Marco van de Voort
to Bisma Jayadi
Show quoted text 7 lines
FPC has great amounts of compatibility with Borland Delphi. Unfortunately, according to the FPC docs, it only supports Delphi compatibility until Delphi 4. The object pascal enhancement on the next Delphi release is still not supported by FPC. Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which has tons of great object pascal enhancement,

Name one that really enables you to do something that you couldn't do otherwise.

don't FPC developers think that now is the time to follow up the language enhancements? For example: the for..in syntax, reintroduce keyword, sub class (class field), etc.

IMHO No. Stability and usability on D7 level is more important, than the relatively uninteresting extensions. Things like COM support and packages are way more important.

Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC development won't go that direction yet.

Good.

I'm just talking about the language enhancement here, for more code portability.

If you want portability, simply don't use D2005 syntax.

Say, I'll be able to compile my Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the 'real' concept of "write once, compile everywhere". :D

Write it in D7 and compile it everywhere.

Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :)

To my knowledge there are no plans for post-D7 support. The whole point is compability with Delphi.NET, and there is not much interest in that anyway.

Reply by email

Bisma Jayadi
to Marco van de Voort
Name one that really enables you to do something that you couldn't do otherwise.

Actually... none. :)

If you want portability, simply don't use D2005 syntax.

Hmmm... very nice advice. :)

Write it in D7 and compile it everywhere. To my knowledge there are no plans for post-D7 support. The whole point is compability with Delphi.NET, and there is not much interest in that anyway.

So, may I conclude that FPC is targetting D7 language compatibility? That's sound fair enough to me, and -thanks God- I can live with that. :)

Is the D7 compatibility has been reached fully or partially or still under development? How far the compatibility of FPC v.2.0 with D7? Is there any docs explain about this issue? Because I still failed to compile my D7 codes under FPC 2.0. It's an D7 codes utilizing dbExpress components.

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Reply by email

Bisma Jayadi
to L505: | FPC has great amounts of compatibility with Borland Delphi. Unfortunately, | according…
Show quoted text 15 lines
I'm sorry to say but none of these things will make FPC a better compiler by a large part. Since freepascal doesn't have very many contributed units compared to something like Torry.net, I think that's what people need to work on! I don't actually think that it is the compiler team who needs to work more. they already have small bugs to repair, I think developers need to make contributed units and do work. The language is strong but more functions and wrappers need to be written. If you think about it, no one would use Delphi just for the "for if" part about it, but rather they would use delphi because of all the stuff available for it... like on Torry.net.

Totally agree with you! Let the FPC developer team concentrate on the compiler and language enhancement, and let the rest of us do the supported units. If FPC can do all the Delphi can do, then... viola!! all codes on Torry will be compilable on FPC. And the concept of "write once, compile everywhere" will be very much closer to the object pascal language. Isn't that nice? :)

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Reply by email

Danny Milosavljevic
to Bisma Jayadi: Actually... none. :) Hmmm... very nice advice. :) So, may I conclude that FPC is…

Hi,

Bisma Jayadi wrote 19 lines
> Name one that really enables you to do something that you couldn't do > otherwise. Actually... none. :) > If you want portability, simply don't use D2005 syntax. Hmmm... very nice advice. :) > Write it in D7 and compile it everywhere. > > To my knowledge there are no plans for post-D7 support. The whole point is > compability with Delphi.NET, and there is not much interest in that anyway. So, may I conclude that FPC is targetting D7 language compatibility? That's sound fair enough to me, and -thanks God- I can live with that. :) Is the D7 compatibility has been reached fully or partially or still under development? How far the compatibility of FPC v.2.0 with D7? Is there any docs

at least the (com) "implements" keyword and the variant IDispatch compiler support is still missing, whereas someone wanted to tell me the behaviour of the latter, but mysteriously vanished. Someone else started to implement the "implements" keyword, I think.

For IDispatch, its something like if there is a variant (containing a ??? IUnknown reference) used in an expression, and then a dot follows, then pass the actual method name of the method called via idispatch to the interface in the variant.

It's like
  i: IUnknown;
  v: Variant;
  i := mooo;
  v := i;
  v.Bla; <--- magical auto-"cast" to IDispatch and passing 'Bla' to be
called to "Invoke"

----
HRESULT Invoke(
DISPID dispIdMember,
REFIID riid,
LCID lcid,
WORD wFlags,
DISPPARAMS FAR* pDispParams,
VARIANT FAR* pVarResult,
EXCEPINFO FAR* pExcepInfo,
unsigned int FAR* puArgErr
);
Use GetIDsOfNames or the object's documentation to obtain the dispatch identifier.
---

Pretty sure I'm missing something (like for example what the dispids and 'dispatch interfaces' are for and such), and it makes no sense if we dont have an user who uses IDispatch (since it then cant be really tested, plus, on linux - where I am -, there are close to no apps that support that IDispatch interface at all). Someone please fill in the gaps.
(Plus, I hated IDispatch when I was using delphi. Very good for variant-based runtime-only errors, hard to track down.)

explain about this issue? Because I still failed to compile my D7 codes under FPC 2.0. It's an D7 codes utilizing dbExpress components.

Hmm, well, more info please :)

Show quoted text 5 lines
-Bee- has Bee.ography at: http://beeography.modblog.com

cheers,
Danny

www.keyserver.net key id A334AEA6

Reply by email

L505
to Bisma Jayadi: FPC has great amounts of compatibility with Borland Delphi. Unfortunately, according to…

| FPC has great amounts of compatibility with Borland Delphi. Unfortunately, | according to the FPC docs, it only supports Delphi compatibility until Delphi 4. | The object pascal enhancement on the next Delphi release is still not supported | by FPC.
|
| Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which | has tons of great object pascal enhancement, don't FPC developers think that now | is the time to follow up the language enhancements? For example: the for..in | syntax, reintroduce keyword, sub class (class field), etc. |
| Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC | development won't go that direction yet. I'm just talking about the language | enhancement here, for more code portability. Say, I'll be able to compile my | Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the | 'real' concept of "write once, compile everywhere". :D |
| Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :) |
| -Bee-

I'm sorry to say but none of these things will make FPC a better compiler by a large part. Since freepascal doesn't have very many contributed units compared to something like Torry.net, I think that's what people need to work on! I don't actually think that it is the compiler team who needs to work more. they already have small bugs to repair, I think developers need to make contributed units and do work. The language is strong but more functions and wrappers need to be written. If you think about it, no one would use Delphi just for the "for if" part about it, but rather they would use delphi because of all the stuff available for it... like on Torry.net.

Lars

Reply by email

Marco van de Voort
to Bisma Jayadi: Actually... none. :) Hmmm... very nice advice. :) So, may I conclude that FPC is…
So, may I conclude that FPC is targetting D7 language compatibility? That's sound fair enough to me, and -thanks God- I can live with that. :)

Roughly yes. That is the goal of the 2.0.x branch, languagewise.

Is the D7 compatibility has been reached fully or partially or still under development? How far the compatibility of FPC v.2.0 with D7? Is there any docs explain about this issue? Because I still failed to compile my D7 codes under FPC 2.0.

_language_ compability.

Some known missing functionality:
1 implements style delegation
2 vararray support is patchy.
3 customvariants are missing in the rtl
4 packages
5 dispinterfaces and dispid.
6 assembler routines have some constructs that are not supported. These are being eliminated at a fairly decent rate the last few months

Libraries are done on a case by case basis (is this part already legacy in D6/D7, is it too OS specific etc).

Reply by email

L505
to Bisma Jayadi: Totally agree with you! Let the FPC developer team concentrate on the compiler and…

| Totally agree with you! Let the FPC developer team concentrate on the compiler | and language enhancement, and let the rest of us do the supported units. If FPC | can do all the Delphi can do, then... viola!! all codes on Torry will be | compilable on FPC. And the concept of "write once, compile everywhere" will be | very much closer to the object pascal language. Isn't that nice? :) |

Well this is somewhat a matter of prioritization I guess. Yes it would be good to prioritize compatibility with Delphi 5 and 6 since lots of code out there for delphi 5 and 6 exists already.

Most of the code on torry is for delphi 3 4 5 that' I've used, though. Do you actually use any code that's for .net .. and if so, has it been rewritten for .Net or is it something that is special and totally unique?

I think smaller compatibility issues are important, but nothing as far as the "for..in" stuff. If For In was classes, or object oriented programming, or dynamic arrays (big things.. that help someone significantly) then I could see it as something to prioritize.

The sad thing is, people do not fork out 2000 dollars for Delphi 9 or whatever.. they just use their old delphi 3-4-5-6 compilers. Maybe the big corporations who love buzzwords.. but even applications like TotalCommander are still compiled in Delphi-3-4 as far as Stud_Pe tells me.

I haven't even come across .Net myself: out of about 600 applications I have here and maybe about 50 I use often, none of them use .Net. I'm always wondering what in the world .Net is.. I think TCP/IP is important today in our applications and .Net is trying to make TCP/IP into something called .Net. The sad thing is, delphi components that do TCP/IP are out there for Delphi 3 or so. Internet ready applications...

We just need to build TCP/IP wrappers for FPC, and forget the .Net fad. If TCP/Wrappers were out there that were extremely easy to use, FPC would be .Net.. i.e. it would compile everywhere and connect your apps to the internet.

That, and we need to push freepascal as a dream for CGI developers. A lot of people still use PHP, who are delphi developers. What's up with that? Rewriting code for PHP that you've already written 5 years ago in delphi in Dos. And they need to come see the PSP project. I suppose someone could port PSP to kylix but PHP is free and PSP wouldn't be free on kylix.

Lars

Reply by email

Bisma Jayadi
to Danny Milosavljevic: at least the (com) "implements" keyword and the variant IDispatch compiler support is…
Marco van de Voort wrote 7 lines
Some known missing functionality: 1 implements style delegation 2 vararray support is patchy. 3 customvariants are missing in the rtl 4 packages 5 dispinterfaces and dispid. 6 assembler routines have some constructs that are not supported.
Danny Milosavljevic wrote
> Because I still failed to compile my D7 codes under FPC 2.0. > It's an D7 codes utilizing dbExpress components. Hmm, well, more info please :)

-----

Well... from Marco's latest reply I think I know why FPC still unable to compile D7 dbExpress components. Almost all compilation errors are caused by what Marco's said. :)

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Reply by email

Micha Nelissen
to Bisma Jayadi
Show quoted text 13 lines
Marco van de Voort wrote: > Some known missing functionality: > 1 implements style delegation > 2 vararray support is patchy. > 3 customvariants are missing in the rtl > 4 packages > 5 dispinterfaces and dispid. > 6 assembler routines have some constructs that are not supported. Well... from Marco's latest reply I think I know why FPC still unable to compile D7 dbExpress components. Almost all compilation errors are caused by what Marco's said. :)

Can you tell which one(s) are missing then ?

Micha

Reply by email

Bisma Jayadi
to Micha Nelissen
Show quoted text 9 lines
> Some known missing functionality: > 1 implements style delegation > 2 vararray support is patchy. > 3 customvariants are missing in the rtl > 4 packages > 5 dispinterfaces and dispid. > 6 assembler routines have some constructs that are not supported. Can you tell which one(s) are missing then ?

Mostly caused by number 2, 3, and 6.

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Reply by email

Tomas Hajny
to Bisma Jayadi

Bisma Jayadi said:

Show quoted text 11 lines
>> Some known missing functionality: >> 1 implements style delegation >> 2 vararray support is patchy. >> 3 customvariants are missing in the rtl >> 4 packages >> 5 dispinterfaces and dispid. >> 6 assembler routines have some constructs that are not supported. > > Can you tell which one(s) are missing then ? Mostly caused by number 2, 3, and 6.

I'd then suggest to put the particular issues (short examples compilable with Delphi 7 and not working with FPC) to our bug repository (unless they are already there, of course - please, check first). Alternatively, you can directly help with implementation of the missing pieces - especially the RTL part shouldn't probably be extremely difficult.

Tomas

Reply by email

Matthias Hryniszak
to Tomas Hajny

----- Original Message -----

Earlier message 36 lines
From: "Tomas Hajny" To: "FPC developers' list" Sent: Saturday, May 28, 2005 11:10 AM Subject: Re: [fpc-devel] don't you think it's time toupdatedelphimodecompatibility? - IDispatch, implements > Bisma Jayadi said: >>>> Some known missing functionality: >>>> 1 implements style delegation >>>> 2 vararray support is patchy. >>>> 3 customvariants are missing in the rtl >>>> 4 packages >>>> 5 dispinterfaces and dispid. >>>> 6 assembler routines have some constructs that are not supported. >>> >>> Can you tell which one(s) are missing then ? >> >> Mostly caused by number 2, 3, and 6. I don't get it. Variant support (after "using" variants unit) works good, custom variants is a mistery for me right now and assembler routines are not to be used in end-classes/methods/functions because of portability issues. Other thing is with the dispinterfaces and DO WORK perfectly in delphi but they are more than tricky in FPC (even though the support for interfaces has been greatly improved in 2.0). So in my opinion interfaces (which are the one-and-only) possibility for exporting "classes" from DLLs should be the most important thing to fix. Besides I find that FPC 2.0 makes the executables just to big. Even though I compressed them with UPX -9 they are still bigger than the one compiled with delphi. This is the one thing I really dislike in freepascal. Besides the lack of real working interfaces I find FPC my favourite pascal compiler. Regards, Matthias.

Reply by email

Florian Klaempfl
to Matthias Hryniszak
Matthias Hryniszak wrote 36 lines
----- Original Message ----- From: "Tomas Hajny" To: "FPC developers' list" Sent: Saturday, May 28, 2005 11:10 AM Subject: Re: [fpc-devel] don't you think it's time toupdatedelphimodecompatibility? - IDispatch, implements > Bisma Jayadi said: > >>>> Some known missing functionality: >>>> 1 implements style delegation >>>> 2 vararray support is patchy. >>>> 3 customvariants are missing in the rtl >>>> 4 packages >>>> 5 dispinterfaces and dispid. >>>> 6 assembler routines have some constructs that are not supported. >>> >>> >>> Can you tell which one(s) are missing then ? >> >> >> Mostly caused by number 2, 3, and 6. I don't get it. Variant support (after "using" variants unit) works good, custom variants is a mistery for me right now and assembler routines are not to be used in end-classes/methods/functions because of portability issues. Other thing is with the dispinterfaces and DO WORK perfectly in delphi but they are more than tricky in FPC (even though the support for interfaces has been greatly improved in 2.0). So in my opinion interfaces (which are the one-and-only) possibility for exporting "classes" from DLLs should be the most important thing to fix. Besides I find that FPC 2.0 makes the executables just to big.+

The rtl is slightly bigger because of the portability layers and an optimizer aligning code for modern CPUs but upx makes them definitily smaller than D. ones:

C:\fpc>type test1.pp
begin
  writeln('Hello world');
end.

C:\fpc>fpc -Xs test1.pp
Free Pascal Compiler version 2.0.0 [2005/05/08] for i386 Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test1.pp
Linking test1.exe
3 Lines compiled, 0.0 sec

C:\fpc>dir test1.exe
Datenträger in Laufwerk C: ist 6Y120PO PRI
Volumeseriennummer: 12E3-1449

Verzeichnis von C:\fpc

28.05.2005 23:14 25.600 test1.exe
1 Datei(en) 25.600 Bytes
0 Verzeichnis(se), 3.637.313.536 Bytes frei

C:\fpc>upx test1.exe
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 UPX 1.25w Markus F.X.J. Oberhumer & Laszlo Molnar Jun 29th 2004

File size Ratio Format Name
-------------------- ------ ----------- ----------- 25600 -> 11264 44.00% win32/pe test1.exe

Packed 1 file.

C:\fpc>dir test1.exe
Datenträger in Laufwerk C: ist 6Y120PO PRI
Volumeseriennummer: 12E3-1449

Verzeichnis von C:\fpc

28.05.2005 23:14 11.264 test1.exe
1 Datei(en) 11.264 Bytes
0 Verzeichnis(se), 3.637.313.536 Bytes frei

C:\fpc>

IIRC Delphi creates 16 kB something.

Show quoted text 13 lines
Even though I compressed them with UPX -9 they are still bigger than the one compiled with delphi. This is the one thing I really dislike in freepascal. Besides the lack of real working interfaces I find FPC my favourite pascal compiler. Regards, Matthias. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Matthias Hryniszak
to Florian Klaempfl

----- Original Message -----

Earlier message 23 lines
From: "Florian Klaempfl" 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:14 25.600 test1.exe > 28.05.2005 23:14 11.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

Reply by email

Matthias Hryniszak
to Florian Klaempfl: The rtl is slightly bigger because of the portability layers and an optimizer aligning…

----- Original Message -----

Earlier message 39 lines
From: "Florian Klaempfl" 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:14 25.600 test1.exe > 28.05.2005 23:14 11.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

Reply by email

Jonas Maebe
to Matthias Hryniszak
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

Reply by email

Daniël Mantione
to Matthias Hryniszak: ----- Original Message ----- From: "Florian Klaempfl" To: "FPC developers' list" Sent:…

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

Reply by email

Matthias Hryniszak
to Daniël Mantione

----- Original Message -----

Earlier message 24 lines
From: "Daniël Mantione" 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.

Reply by email

Mattias Gaertner
to Daniël Mantione: Op Sat, 29 May 2004, schreef Matthias Hryniszak: It *is* the source. The compiler is…
Show quoted text 12 lines
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

Reply by email

Jamie McCracken
to Daniël Mantione: Op Sat, 29 May 2004, schreef Matthias Hryniszak: It *is* the source. The compiler is…
Daniël Mantione wrote 20 lines
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.

Show quoted text 9 lines
Daniël _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Matthias Hryniszak
to Jamie McCracken

----- Original Message -----

Earlier message 55 lines
From: "Jamie McCracken" 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

Reply by email

Jonas Maebe
to Matthias Hryniszak
Matthias Hryniszak wrote 15 lines
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

Reply by email

Peter Vreman
to Jamie McCracken: There are too many variables here to conclude decisively what is causing it to be much…
you wrote 25 lines
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.

Show quoted text 5 lines
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

Reply by email

Matthias Hryniszak
to Jonas Maebe: If you want dead code to be stripped from your own written code, you must turn on the…

----- Original Message -----

Earlier message 37 lines
From: "Jonas Maebe" 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.

Reply by email

Matthias Hryniszak
to Peter Vreman: There is almost none in the rtl. Use -Or. But don't think that it always generates less…
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

Reply by email

Jamie McCracken
to Peter Vreman: There is almost none in the rtl. Use -Or. But don't think that it always generates less…
Show quoted text 8 lines
> > 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.

Show quoted text 10 lines
Peter _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jonas Maebe
to Matthias Hryniszak: Might it be possible to keep a recerence counter for procedures/methods while compiling…
Matthias Hryniszak wrote 5 lines
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

Reply by email

Peter Vreman
to Jonas Maebe
Show quoted text 7 lines
>>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

Reply by email

Jonas Maebe
to Peter Vreman
Peter Vreman wrote 8 lines
>> 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

Reply by email

Florian Klaempfl
to Matthias Hryniszak: ----- Original Message ----- From: "Jonas Maebe" To: "FPC developers' list" Sent: Sunday,…
Matthias Hryniszak wrote 8 lines
> 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.

Show quoted text 6 lines
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.

Reply by email

Jamie McCracken
to Jonas Maebe: Yes, but the poster was asking whether the compiler never decided by itself to inline…
Jonas Maebe wrote 18 lines
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.

Show quoted text 10 lines
Jonas _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Matthias Hryniszak
to Florian Klaempfl: Well, 132k agaist 86k. That's the price for the portable rtl and usually faster code.…
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.

Reply by email

Florian Klaempfl
to Matthias Hryniszak
Matthias Hryniszak wrote 9 lines
> 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.

Show quoted text 11 lines
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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Peter Vreman
to Jamie McCracken: well thats soemthing you should add to your to do list. Automatic inlining can deliver a…
you wrote 22 lines
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

Reply by email

Jamie McCracken
to Peter Vreman
Show quoted text 9 lines
> 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.

Reply by email

Florian Klaempfl
to Jamie McCracken
Jamie McCracken wrote 14 lines
>> 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

Show quoted text 6 lines
jamie. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jonas Maebe
to Unknown author
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

Reply by email

Marco van de Voort
to Matthias Hryniszak: That's not what I ment. I see a problem with a GUI app that's using FCL. This apps are…

yy[ Charset ISO-8859-1 unsupported, converting... ]

Show quoted text 6 lines
> 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?

Reply by email

peter green
to Marco van de Voort

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.

Show quoted text 27 lines
-----Original Message----- From: 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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

L505
to Marco van de Voort: yy[ Charset ISO-8859-1 unsupported, converting... ] 1. To who? 2. And why?

| 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

Reply by email

Michael Preslar
to Jonas Maebe: If you want dead code to be stripped from your own written code, you must turn on the…
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")

Reply by email

Peter Vreman
to Michael Preslar
Show quoted text 38 lines
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.

Reply by email

Hans-Peter Diettrich
to Jamie McCracken: well thats soemthing you should add to your to do list. Automatic inlining can deliver a…
Jamie McCracken wrote 9 lines
> 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)

Yes, inlining property getters/setters can speed up some code. I often have methods that do nothing but an type cast.

I don't know what efforts were required to implement something like {$AUTO_INLINE ON}. When the compiler already decides, which of the explicitly marked "inline" procedures really to inline, such an option might require not much additional code. The automatic checks could be restricted to procedures up to a certain code size, e.g. 10 bytes excluding subroutine enter/exit code. An -AutoInline <size> command line option also could help to eliminate all those {$IFDEF fpc} inline {$ENDIF} inserts in portable source code.

Else I feel no urgent need for such an automatism.

DoDi

Reply by email

Marco van de Voort
to L505: | yy[ Charset ISO-8859-1 unsupported, converting... ] | > > Nobody said that the same…
Show quoted text 12 lines
| 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.

The questions still stand. Not acceptable to who? And why does that person consider it not acceptable?

0. Failing to smartlink or not strip debug info. This is not a FPC problem, but an user problem. There is some confusion about this lately, but we can short about this; On win32, if you do a release build of your product run strip <.exe file> before UPX, in case the linker didn't strip all debuginfo.
1. not having an internal linker and thus not being able to further improve smart linking
2. Having generic parts of the RTL portable.
3. (compared to TP/BP), simply being 32-bit.
4. (Lazarus compared to Delphi VCL) having a OS independant widgetset.

All these are known. 2 and 3 won't ever change.

Not having an internal linker (1) is a known problem too, but can't be changed short term (and LD might improve in the future too)

I don't think (4) is particularly bad. Lazarus apps smaller than 2 MB (1 mb even with UPX) are doable, and that is a nice size nowadays.

Reply by email

Jamie McCracken
to Hans-Peter Diettrich: Yes, inlining property getters/setters can speed up some code. I often have methods that…
Hans-Peter Diettrich wrote 20 lines
> >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) Yes, inlining property getters/setters can speed up some code. I often have methods that do nothing but an type cast. I don't know what efforts were required to implement something like {$AUTO_INLINE ON}. When the compiler already decides, which of the explicitly marked "inline" procedures really to inline, such an option might require not much additional code. The automatic checks could be restricted to procedures up to a certain code size, e.g. 10 bytes excluding subroutine enter/exit code. An -AutoInline <size> command line option also could help to eliminate all those {$IFDEF fpc} inline {$ENDIF} inserts in portable source code.

What would be nice is to have a compiler switch which takes say an 8bit value to indicate how many bytes a function must contain in order to be inlined automatically. That way it is scaleable and so wont exacerbate the executable file size problem too much.

jamie.

Reply by email

Jonas Maebe
to Jamie McCracken
Jamie McCracken wrote
What would be nice is to have a compiler switch which takes say an 8bit value to indicate how many bytes a function must contain in order to be inlined automatically. That way it is scaleable and so wont exacerbate the executable file size problem too much.

At the point the inlining is performed, the compiler does not have the slightest idea how large the function will be in terms of bytes. There is already a an extremely crude "complexity calculation" function, but it does not have any relation to size (only to speed -- to a certain extent).

Jonas

Reply by email

Jamie McCracken
to Jonas Maebe
Jonas Maebe wrote 14 lines
On 30 May 2005, at 18:29, Jamie McCracken wrote: > What would be nice is to have a compiler switch which takes say an > 8bit value to indicate how many bytes a function must contain in > order to be inlined automatically. That way it is scaleable and so > wont exacerbate the executable file size problem too much. At the point the inlining is performed, the compiler does not have the slightest idea how large the function will be in terms of bytes. There is already a an extremely crude "complexity calculation" function, but it does not have any relation to size (only to speed -- to a certain extent).

It doesn't have to be bytes - Would you now how many opcodes are in the function at that point?

jamie.

Show quoted text 10 lines
Jonas _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jonas Maebe
to Jamie McCracken
Jamie McCracken wrote 8 lines
> At the point the inlining is performed, the compiler does not > have the slightest idea how large the function will be in terms > of bytes. There is already a an extremely crude "complexity > calculation" function, but it does not have any relation to size > (only to speed -- to a certain extent). It doesn't have to be bytes - Would you now how many opcodes are in the function at that point?

No. The inlining happens at the parse tree level. All we know is the number and type of nodes (at that point, it could still be reduced/ optimized later).

Jonas

Reply by email