Re: [fpc-devel] MM_MaskInvalidOp in mxcsr

2010-09-04 Thread Jonas Maebe
On 03 Sep 2010, at 12:05, Markus Beth wrote: > Is there a reason why MM_MaskInvalidOp is not set in mxcsr in > rtl/x86_64/x86_64.inc? Because on all FPC platforms, the default behaviour is that an invalid floating point operation causes an exception. > I have a 3rd party application that depe

Re: [fpc-devel] Type redefinitions

2010-09-04 Thread Florian Klämpfl
Am 28.08.2010 13:54, schrieb Hans-Peter Diettrich: > Several type redefinitions are reported in compiling the compiler, can > these be removed? Yes. > > Most types (PByte...) are declared in systemh.inc and objpash.inc. I'm > not sure, but can't these redefinitions be excluded conditionally, for

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread 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. Now ppudump turned into an show stopper, due to the unsystematic and obscure unit dependencies in the compiler: Hans-Peter Diettrich s

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread Florian Klämpfl
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 wer

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread Felipe Monteiro de Carvalho
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 normally

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread Graeme Geldenhuys
On 4 September 2010 18:49, Felipe Monteiro de Carvalho 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. That's the joy of the thread sc

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread Jonas Maebe
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 obs

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread 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 ppudump turned into an show stopper, due to the unsystem

Re: [fpc-devel] Parallel processing in the compiler

2010-09-04 Thread Hans-Peter Diettrich
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