Re: [fpc-devel] -Oodfa
Am 30.12.2011 02:00, schrieb Martin: Florian wrote at http://bugs.freepascal.org/view.php?id=20907 FPC has a good enough dfa, however it is only activated when compiling with -Oodfa: c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? Beta. I'am not aware of any missing stuff, but it's mainly untested. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
Florian Klämpfl wrote: Am 30.12.2011 02:00, schrieb Martin: Florian wrote at http://bugs.freepascal.org/view.php?id=20907 c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? Beta. I'am not aware of any missing stuff, but it's mainly untested. Maybe add a nightly testsuite run for it? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
In our previous episode, Florian Kl?mpfl said: c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? Beta. I'am not aware of any missing stuff, but it's mainly untested. I tried yesterday, and couldn't cycle with it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
On 30 Dec 2011, at 10:26, Florian Klämpfl wrote: Beta. I'am not aware of any missing stuff, but it's mainly untested. I tried to activate by default it during the development of the JVM port (since the JVM will abort if it detects an uninitialized read), but it caused compiler crashes. I'll see if I can create isolated test cases. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
30.12.2011 14:42, Jonas Maebe пишет: On 30 Dec 2011, at 10:26, Florian Klämpfl wrote: Beta. I'am not aware of any missing stuff, but it's mainly untested. I tried to activate by default it during the development of the JVM port (since the JVM will abort if it detects an uninitialized read), but it caused compiler crashes. I'll see if I can create isolated test cases. The present DFA doesn't work for code which uses exceptions, including implicit exception handling (read: a good 50% of all codebase). In the meantime I tried adapting DFA, or more precisely, definite assignment analyzer, from Mono compiler (Mantis #15523). It uses a different approach, which works fine with exceptions, but is not suited well (if at all) for determining live range of variables. See notes on Mantis #15523 for details. With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days. In particular, we have to solve the FillChar() issue before any DFA is enabled by default. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
Am 30.12.2011 12:13, schrieb Sergei Gorelkin: 30.12.2011 14:42, Jonas Maebe пишет: On 30 Dec 2011, at 10:26, Florian Klämpfl wrote: Beta. I'am not aware of any missing stuff, but it's mainly untested. I tried to activate by default it during the development of the JVM port (since the JVM will abort if it detects an uninitialized read), but it caused compiler crashes. I'll see if I can create isolated test cases. The present DFA doesn't work for code which uses exceptions, Indeed, I can fix this. including implicit exception handling (read: a good 50% of all codebase). In the meantime I tried adapting DFA, or more precisely, definite assignment analyzer, from Mono compiler (Mantis #15523). It uses a different approach, which works fine with exceptions, but is not suited well (if at all) for determining live range of variables. See notes on Mantis #15523 for details. 15523 has different aims than optdfa. With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days. In particular, we have to solve the FillChar() issue before any DFA is enabled by default. I played with this yesterday and what about extended Initialize to support unmanaged types? In case of an unmanaged type it just calls fillchar. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
On 30 Dec 2011, at 12:13, Sergei Gorelkin wrote: With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be fixed because cycling is done with -Sew these days. Passing an uninitialized variable to a var-parameter should cause a hint, not a warning. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
30.12.2011 15:18, Florian Klämpfl пишет: I played with this yesterday and what about extended Initialize to support unmanaged types? In case of an unmanaged type it just calls fillchar. I was rather thinking about 'varout' (or so) parameter type, which was suggested already several times in the past. Extending Initialize is a) different from Delphi (Delphi ignores initialize(unmanaged_type)), b) does not affect already existing code, c) not applicable to all cases where FillChar is used (e.g. FillChar(x, sizeof(foo)+n*sizeof(bar)) Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Import typelib extension
Hi all,
I'm in the middle of adding to the typelib importer the automatic generation
of a component implementing a sink for the events created by the com object.
It'll use the EventSink object I wrote a while ago and will generate the
components Onxxx properties and the corresponding function signatures. This
will remove the burden of mapping dispids, retrieving and converting
parameters to fpc compatible types (VT_BYREF !), etc. This is all fpc and
would fit in with the current implementation of importtl.pas and
typelib.pas.
However, I just wrote a freepascal implementation of an Ole container
(visual ActiveX container) and I would obviously like to integrate this also
with the typelib importer to create also a complete (visual) component from
an ActiveX typelib, including its event handlers and eventually the lpk to
install the component in Lazarus. The Ole container is a descendant of
TWinControl and obviously LCL.
Comes my question: I would like to put the EventSink and the Ole container
in a OleComponents unit in the winunits-base package to avoid a
multiplication of units and directory paths. Is the use of {$ifdef LCL} to
encapsulate the Ole container in a fpc unit acceptable or is this a herecy?
The unit created by the typelib importer would also have parts inside
{$ifdef LCL}
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Import typelib extension
In our previous episode, Ludo Brands said:
I'm in the middle of adding to the typelib importer the automatic generation
of a component implementing a sink for the events created by the com object.
It'll use the EventSink object I wrote a while ago and will generate the
components Onxxx properties and the corresponding function signatures. This
will remove the burden of mapping dispids, retrieving and converting
parameters to fpc compatible types (VT_BYREF !), etc. This is all fpc and
would fit in with the current implementation of importtl.pas and
typelib.pas.
Good.
However, I just wrote a freepascal implementation of an Ole container
(visual ActiveX container) and I would obviously like to integrate this also
with the typelib importer to create also a complete (visual) component from
an ActiveX typelib, including its event handlers and eventually the lpk to
install the component in Lazarus. The Ole container is a descendant of
TWinControl and obviously LCL.
Also good.
Comes my question: I would like to put the EventSink and the Ole container
in a OleComponents unit in the winunits-base package to avoid a
multiplication of units and directory paths.
No that is not possible.
Is the use of {$ifdef LCL} to
encapsulate the Ole container in a fpc unit acceptable or is this a herecy?
Heresy, and worse, it will simply not work. A typical lazarus release then
would have a FPC version with the LCL disabled and compiled with -Ur, and
including the source directory might not force recompilation or lead to all
kinds of vague errors (which is an unsupportable situation)
I would say, two units, the visual part goes to Lazarus, and two different
importtl
options to enable the respective generations.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] Import typelib extension
Is the use of {$ifdef LCL} to
encapsulate the Ole container in a fpc unit acceptable or is this a
herecy?
Heresy, and worse, it will simply not work. A typical lazarus
release then would have a FPC version with the LCL disabled
and compiled with -Ur, and including the source directory
might not force recompilation or lead to all kinds of vague
errors (which is an unsupportable situation)
Understood, I didn't think about -Ur and/or the unit not always being
recompiled.
I would say, two units, the visual part goes to Lazarus, and
two different importtl options to enable the respective
generations.
OK.
Option 1: current CoClass extended with eventhandlers. Lifetime of Com
object is managed by user.
Option 2: ActiveXContainer (TWinControl) descendant with eventhandlers.
Lifetime of Com object is managed by Component.
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] JVM: Question regarding converted Java code
On 29 Dec 2011, at 14:18, Sven Barth wrote: On 29.12.2011 13:49, Jonas Maebe wrote: On 28 Dec 2011, at 23:28, Sven Barth wrote: 1) as it seems to be a rather usual practice in Java, would it be possible to disable the Constructor should be public warnings if the target cpu is the JVM? Yes. This would be nice :) Actually, it should only be done for external classes. For classes defined in Pascal code, the compiler itself enforces the default FPC/Delphi behaviour whereby constructors from parent classes are automatically inherited (if it would not do that, you would have to manually redeclare every constructor that you wanted to reuse, because you cannot construct a Java class using a constructor defined in a parent class). As a result, every class will have at least one public constructor (a parameterless one), which is the original reason for the warning and the same on all targets. You can of course always use the -vq/-vm command line parameters to manually disable that warning. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] JVM: Question regarding converted Java code
On 30.12.2011 15:25, Jonas Maebe wrote: On 29 Dec 2011, at 14:18, Sven Barth wrote: On 29.12.2011 13:49, Jonas Maebe wrote: On 28 Dec 2011, at 23:28, Sven Barth wrote: 1) as it seems to be a rather usual practice in Java, would it be possible to disable the Constructor should be public warnings if the target cpu is the JVM? Yes. This would be nice :) Actually, it should only be done for external classes. For classes defined in Pascal code, the compiler itself enforces the default FPC/Delphi behaviour whereby constructors from parent classes are automatically inherited (if it would not do that, you would have to manually redeclare every constructor that you wanted to reuse, because you cannot construct a Java class using a constructor defined in a parent class). As a result, every class will have at least one public constructor (a parameterless one), which is the original reason for the warning and the same on all targets. For me it would be ok if this is for external classes only. You can of course always use the -vq/-vm command line parameters to manually disable that warning. This is of course always a possibility, but this is a case - in my opinion - where not the symptom, but the cause the should be healed. ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
My assumptions for this idea are: 1. Pointers to classes are mostly stored on the heap, in slow RAM. What's fast RAM? That would be the CPU L1 cache ;) 2. Nested/delegated classes incur a pointer access penalty, the deeper the nesting the higher the penalty. Why? Nested classes are not a problem in OPL, more in C++ (multiple inheritance!). Nested classes are a problem because of the pointer overhead. For example 100 nested classes will require 100 pointer lookups and thus 100 instructions. However there is an interesting solution for Free Pascal and Delphi which is the old object type. This object type seems to behave in a nested way where it's one large data structure and only 1 to 2 instructions are needed for retrieving and storing the final nested level. The Free Pascal/Lazarus and Delphi compiler calculates the final nested field offset just like Visual Studio 2010 C/C++ compiler does. 3. Pointers are rarely if ever stored in constant values in the instruction encoding ?? Could you give an example of a “constant pointer in an instruction” ? E.g. address of a non-virtual method. To get to the methods still requires a pointer to the class instance I think... so accessing a field, property or method doesn't matter, it all requires the same: a pointer to the instance, or in this case 100 pointers to the 100th nested class. Or only 1 pointer to the calculated offset for the 100th nested object. 4. Pointers are probably frequently pushed out of data cache by other data. More frequently than what? A pointer can be used to access multiple (different) items, so that pointers are more frequently used than other data. Arbitrary data/fields which might be accessed just once... so no further cache hits, or perhaps a single cache hit if it was cached thanks to cache lines... so even a single cache hit is still interesting for data. This would need to be take in carefull consideration ;) For now a better solution seems to be for Delphi to keep supporting the object type and programmers requiring high performance to switch to object type. However I am not yet sure what the effect is of switching to object type, this might lead to reduced capabilities. So a good question would be: what capabilities do classes have which objects do not have ? 5. CPUs/GPUs do not have pointer caches yet or anything else that detects data as being pointers ?! This indicates that there exists no need or no chance to improve the current design. Hmm this depends a bit on how you look at it. If all pascal/delphi programmers know what they are doing then yes. But there is probably a whole lof of code/delphi programmers out there which simply default to class type while in same cases the object type might have been a better choice for performance. This is known in cpu world where programmers do dumb/unthoughtfull things and then the cpu people get to solve it ! LOL. So any CPU manufacturer wanting to accelerate Delphi programs might still benefit greatly by implementing a pointer cache. If there are enough Delphi applications out there to warrant this is a different matter. One example of why Delphi programmers are limited to the current situation is the VCL: this is written entirely with classes and has pretty deep nesting. There is pretty much nothing a Delphi programmer can do about this, except modifieing the entire VCL and replacing every class with an object version of it. So while in theory it might be possible, practice would be a different matter, time restrictions could also play a roll ;) :) 6. And finally the pointer cache would speed up Free Pascal/Delphi application execution speed because of less stalls for pointer retrieval. (Free Pascal/Delphi could then rival C/C++ or perhaps even exceed it because of other smart Delphi features like Strings (no null terminator searching required)). Are these assumptions valid ? Not really. Pointers rarely are used by themselves, instead they are mostly used to access data in other memory areas (pointed to). It's more important to keep related data together, e.g. in the same memory page. I think for Delphi all of the assumptions I made are pretty valid, I am not sure about Free Pascal and Lazarus for example, does Lazarus LCL use classes everywhere ? If so then the same would apply to Lazarus as well. The problem is with the pointers to the other memory areas as you describe it themselfes. The pointers function as a gate. To get to the other areas requires retrieving the pointer itself first. The pointer itself is also stored in memory and not in the instruction as you might believe. The more nesting the more gates there are and thus the slower the performance. Conclusion: By using classes gates are introduced into code, this can be prevented by using objects instead. The gates can lead to CPU stalls when those gates are not in the CPU cache (and must first be retrieved from
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb: 2. Nested/delegated classes incur a pointer access penalty, the deeper the nesting the higher the penalty. Why? Nested classes are not a problem in OPL, more in C++ (multiple inheritance!). Nested classes are a problem because of the pointer overhead. For example 100 nested classes will require 100 pointer lookups and thus 100 instructions. Please give example code of what you consider nested classes. So a good question would be: what capabilities do classes have which objects do not have ? Better question: what common capabilitiers are implemented differently in Object and TObject? Try to answer that question first, then we'll see what you didn't understand. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] -Oodfa
Am 30.12.2011 12:47, schrieb Sergei Gorelkin: 30.12.2011 15:18, Florian Klämpfl пишет: I played with this yesterday and what about extended Initialize to support unmanaged types? In case of an unmanaged type it just calls fillchar. I was rather thinking about 'varout' (or so) parameter type, which was suggested already several times in the past. My concern about varout is that it is a rather big change of the language ... Extending Initialize is a) different from Delphi (Delphi ignores initialize(unmanaged_type)), b) does not affect already existing code, c) not applicable to all cases where FillChar is used (e.g. FillChar(x, sizeof(foo)+n*sizeof(bar)) Sergei ___ 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
