On 09/08/2010 09:58 PM, Hans-Peter Diettrich wrote:
So my primary interest in a new back-end structure is more targeted at
ease of development, than on really using multiple back-ends in one
application.
+1
-Michael
___
fpc-devel maillist -
Am 08.09.2010 03:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
I stopped searching after finding such code in aasmtai, aoptbase,
aoptobj, assemble, globals, nadd, ncgutil, nld, ogcoff, options,
optloop, pdecsub, pmodules, psub, symdef, systems.
Well, I see no problem with it.
Florian Klaempfl schrieb:
That's why I suggested solutions other than $IFDEF or virtual methods.
Using ifs is usually not possible because some symbols simply don't
existing on certain architectures.
A solution for such problems was one of the first steps in that
refactoring :-)
Life
On 09/06/2010 02:59 PM, Florian Klaempfl wrote:
And if needed, it can be improved later.
As discussed recently, it supposedly _can_ be improved even without
completely removing the libc-pthreadlib dependency (e.g. for X86/32
using FS in Windows and GS in Linux according to how MS-C and
On 09/06/2010 09:09 PM, Hans-Peter Diettrich wrote:
When objects are used as containers for thread-local variables, these
object references (to the thread-local objects) should be cached.
Yep. that is what I supposed you would do to eliminate threadvar access:
the threads work on their own
Florian Klaempfl schrieb:
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
Another more recent experiment was to convert the back-ends into
classes. It turned out that much target-specific code resides in the
general compiler units, whose separation into virtual back-end methods
would
On 09/07/2010 09:49 AM, Hans-Peter Diettrich wrote:
Logical grouping is not necessarily arbitrary or subjective. A
compiler can be subdivided into front-ends, back-ends and
infrastructure. Back-ends can be subdivided into system and CPU, with
further exchangable functional blocks for e.g.
Am 07.09.2010 09:49, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
Another more recent experiment was to convert the back-ends into
classes. It turned out that much target-specific code resides in the
general compiler units, whose
Florian Klaempfl schrieb:
I stopped searching after finding such code in aasmtai, aoptbase,
aoptobj, assemble, globals, nadd, ncgutil, nld, ogcoff, options,
optloop, pdecsub, pmodules, psub, symdef, systems.
Well, I see no problem with it. Of course, one can do an overly complex
design to
On 5 September 2010 19:36, Florian Klämpfl wrote:
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
That's a matter of opinion I guess. I much prefer stand-alone tools,
so I think they hit the nail on the head. I hate shell or
Am 06.09.2010 09:47, schrieb Graeme Geldenhuys:
On 5 September 2010 19:36, Florian Klämpfl wrote:
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
That's a matter of opinion I guess. I much prefer stand-alone tools,
Yes, I
On 6 September 2010 10:04, Florian Klaempfl flor...@freepascal.org wrote:
Yes, I forgot that you don't like easy to use software.
I'm using FPC and Lazarus, aren't I? ;-)
Oh really? Strangly enough other software works fine on my system :)
Nothing strange really. Windows behaviour is so
On 5 September 2010 18:36, Florian Klämpfl flor...@freepascal.org wrote:
Am 05.09.2010 19:04, schrieb Graeme Geldenhuys:
but rather features and
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
usability.
Yes,
Replied on fpc-other.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar). This
_could_ be improved but I think this only makes sense when removing the
dependency of the RTL to the libc
Am 06.09.2010 14:30, schrieb Michael Schnell:
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar).
And? Those variables aren't used very often. And if needed, it can be
Florian Klaempfl schrieb:
I have no real idea, how in such a model the initialization of the
threadvars has to be implemented. That's why I try to assign all
state-related variables to a definite object, whose reference can be
easily copied (or moved?) into any created thread.
In case of
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
I have no real idea, how in such a model the initialization of the
threadvars has to be implemented. That's why I try to assign all
state-related variables to a definite object, whose reference can be
easily copied
Florian Klaempfl schrieb:
Am 06.09.2010 14:30, schrieb Michael Schnell:
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar).
And? Those variables aren't used very often.
On 5 September 2010 05:04, Hans-Peter Diettrich drdiettri...@aol.com wrote:
I only commited these changes so that they don't get lost. Please review the
preceding version, as mentioned in the Readme.
[... simply stating my observation. If there is a subversion way of
doing the same as I
On Sunday 05 September 2010 13:29:38 Graeme Geldenhuys wrote:
Reading Jonas's comments and your reply above, it seems a git mirror
(or a subversion/git dual setup) would be much better suited for your
working style. git allows local commits and local branches. Ideal for
cases like so those
On 05 Sep 2010, at 05:04, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
I think it is quite systematic and logical that the ppu loading
should not depend on code generator internals.
Right, that's how it *should* be designed.
That's how it is in trunk.
But try to find out why the
Am 05.09.2010 14:17, schrieb Juha Manninen (gmail):
On Sunday 05 September 2010 13:29:38 Graeme Geldenhuys wrote:
Reading Jonas's comments and your reply above, it seems a git mirror
(or a subversion/git dual setup) would be much better suited for your
working style. git allows local commits
Am 05.09.2010 05:04, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
On 04 Sep 2010, at 19:41, Hans-Peter Diettrich wrote:
Every parallel processing requires that all related data is private
to every thread. Since some time I'm trying to eliminate such
(currently) global variables. Now
On 5 September 2010 15:08, Florian Klämpfl wrote:
+1
I can recommend it, too.
In some earlier mail I mentioned it would solve DoDi's problems with merging
his branch with trunk after they have deviated much from each other.
The problem is conflict solving and this is usually the equally
Am 05.09.2010 17:40, schrieb Graeme Geldenhuys:
On 5 September 2010 15:08, Florian Klämpfl wrote:
+1
I can recommend it, too.
In some earlier mail I mentioned it would solve DoDi's problems with merging
his branch with trunk after they have deviated much from each other.
The problem is
On 5 September 2010 18:00, Florian Klämpfl wrote:
Juha has a valid point about less conflicts.
How do you know if you don't use svn? I tried hg and sometimes I use git
I've only used git for the last two years. So no, I don't use svn any
more, but for many years before git, I used svn. So
Am 05.09.2010 19:04, schrieb Graeme Geldenhuys:
but rather features and
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
usability.
Yes, unfortunatly, git gui is basically unusable on windows: most of the
time it's hanging.
Jonas Maebe schrieb:
Nobody ever said that it would be easy to restructure the compiler. In
fact, I will be the first to admit that it is incredibly hard, and since
the compiler is 15 years old (although several parts have been rewritten
over the years), there are bound to be quite a few less
Florian Klämpfl schrieb:
Right, that's how it *should* be designed. But try to find out why the
code generation is added, when variables like current_filepos or
current_tokenpos are moved into TModule (current_module) :-(
Why should current_filepos and current_tokenpos go into TModule? They
Every parallel processing requires that all related data is private to
every thread. Since some time I'm trying to eliminate such (currently)
global variables. Now ppudump turned into an show stopper, due to the
unsystematic and obscure unit dependencies in the compiler:
Hans-Peter Diettrich
Am 04.09.2010 19:41, schrieb Hans-Peter Diettrich:
Every parallel processing requires that all related data is private to
every thread. Since some time I'm trying to eliminate such (currently)
global variables.
What's the problem with using threadvars (I did not look at your code
yet, I were
Just to make sure: This multi-threading would be user selectable, right?
What would be the default value? Multi-threaded or single-threaded?
Personally I enjoy the fact that FPC only goes up to 50% of the CPU
usage (using 1 processor fully out of 2 processors) and then I can
keep working
On 4 September 2010 18:49, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
Personally I enjoy the fact that FPC only goes up to 50% of the CPU
usage (using 1 processor fully out of 2 processors) and then I can
keep working normally with OpenOffice and other heavy stuff.
On 04 Sep 2010, at 19:41, Hans-Peter Diettrich wrote:
Every parallel processing requires that all related data is private to every
thread. Since some time I'm trying to eliminate such (currently) global
variables. Now ppudump turned into an show stopper, due to the unsystematic
and
Jonas Maebe schrieb:
On 04 Sep 2010, at 19:41, Hans-Peter Diettrich wrote:
Every parallel processing requires that all related data is private
to every thread. Since some time I'm trying to eliminate such
(currently) global variables. Now ppudump turned into an show
stopper, due to the
Florian Klämpfl schrieb:
Every parallel processing requires that all related data is private to
every thread. Since some time I'm trying to eliminate such (currently)
global variables.
What's the problem with using threadvars (I did not look at your code
yet, I were on holiday)? As I said in
37 matches
Mail list logo
