[fpc-devel] LoadLibrary and FPU control word
Hi,
I encounter strange thing. Look at this program please:
var
LibraryHandle: TLibHandle;
cw: word;
begin
cw:=Get8087CW;
writeln('CW before:',cw, ' IntPower:', intpower(10,-6));
LibraryHandle:=LoadLibrary('odbc32.dll');
writeln('CW after:',Get8087CW, ' IntPower:', intpower(10,-6));
Set8087CW(cw);
end.
Output:
CW before:4978 IntPower: 1.E-0006
CW after:4722 IntPower: 2.E-0006 --- Wrong result
of IntPower!!!
As you can see, LoadLibrary changes FPU control word (from $1372 to
$1272, from 64bit precision to 53bit precision).
Which leads to wrong result of PowerInt.
But it seems, that this happens on *Windows98* only, on Windows XP,Vista
it does not happen.
Do you have same experience on Windows98?
If yes, then I think, that good idea will be use SafeLoadLibrary instead
of LoadLibrary (which partialy solves this problem).
Next:
But this error I have encounter when running fcl-db tests suite with
IBConnection, where is PowerInt used.
When I change in ibase60.inc LoadLibrary to SafeLoadLibrary problem
still exists, because later call to isc_attach_database again changes
FPU control word. So I must save CW before call to isc_attach_database
and then reset CW to original value.
This solves problem.
Please look at attached patches . Do you think, that this approach is
acceptable or is there any other solution ?
BTW:
When I look at function SafeLoadLibrary in dynlibs.pas there is used :
{$ifdef i386}
w:=get8087cw;
When I look at function SafeLoadLibrary in SysUtils.inc there is used :
{$if defined(cpui386) or defined(cpux86_64)}
fpucw:=Get8087CW;
Which conditional is correct ? (i386 or cpui386)
Looking at
http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G ... I
see no i386 ?
And what FPUX87 ? Can not be used this ?
Thanks
-Laco.
--- ibase60.inc.ori Sat Feb 19 19:24:38 2011
+++ ibase60.inc Wed Aug 17 08:59:28 2011
@@ -2458,7 +2458,7 @@ begin
Result := 0;
if (RefCount=0) then
begin
-IBaseLibraryHandle:=LoadLibrary(LibraryName);
+IBaseLibraryHandle:=SafeLoadLibrary(LibraryName);
if (IBaseLibraryHandle=nilhandle) then
Exit;
inc(RefCount);
--- ibconnection.pp.ori Tue Aug 09 14:18:46 2011
+++ ibconnection.pp Wed Aug 17 09:23:14 2011
@@ -381,6 +381,9 @@ procedure TIBConnection.ConnectFB;
var
ADatabaseName: String;
DPB: string;
+{$if defined(cpui386) or defined(cpux86_64)}
+ cw: word;
+{$endif}
begin
DPB := chr(isc_dpb_version1);
if (UserName '') then
@@ -397,10 +400,16 @@ begin
FSQLDatabaseHandle := nil;
if HostName '' then ADatabaseName := HostName+':'+DatabaseName
else ADatabaseName := DatabaseName;
+{$if defined(cpui386) or defined(cpux86_64)}
+ cw:=get8087cw;
+{$endif}
if isc_attach_database(@FStatus[0], Length(ADatabaseName), @ADatabaseName[1],
@FSQLDatabaseHandle,
Length(DPB), @DPB[1]) 0 then
CheckError('DoInternalConnect', FStatus);
+{$if defined(cpui386) or defined(cpux86_64)}
+ set8087cw(cw);
+{$endif}
end;
function TIBConnection.GetDialect: integer;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpvectorial xml docs
On Tue, 16 Aug 2011, Felipe Monteiro de Carvalho wrote: Hello, I added xml docs for fpvectorial (fpdocs/fpvectorial.xml). It would be excellent if someone added it to the standard fcl help build. I searched a little, but I couldn't find how to do it. I see that one can add it to the makefile, but I'm not sure what is really needed to add it to the toplevel fcl html page. if it is included in the fcl, you don't need to add it to the toplevel HTML page, because then it is below the fcl. Besides, the toplevel html page is a manually edited page. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] C++ gets language-internal concurrency support
http://www.linuxfordevices.com/c/a/News/C11-standard-approved/ Prism already does have parallel loops and future variable for that purpose (but of course usable only with a .NET/Mono framework, as the implementation is done therein) I remember discussions about providing something on that behalf in fpc for native code.. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
Some c++11 code doing parallel execution:
*
void f(vectordouble);
struct F {
vectordouble v;
F(vectordouble vv) :v{vv} { }
void operator()();
};
int main()
{
std::thread t1{std::bind(f,some_vec)}; //*f(some_vec) executes
in separate thread*
std::thread t2{F(some_vec)};//*F(some_vec)()
executes in separate thread*
t1.join();
t2.join();
}
*
*-Michael*
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
In our previous episode, Michael Schnell said:
Some c++11 code doing parallel execution:
*
void f(vectordouble);
struct F {
vectordouble v;
F(vectordouble vv) :v{vv} { }
void operator()();
};
int main()
{
std::thread t1{std::bind(f,some_vec)}; //*f(some_vec) executes
in separate thread*
std::thread t2{F(some_vec)};//*F(some_vec)()
executes in separate thread*
t1.join();
t2.join();
}
I'm no C++ expert, but:
Where is the parallel aspect? It looks more like a shorthand to spawn a
thread to evaluate an expression/closure/function call, and then wait on it
using .join().
The closure-like aspect (be able to pass expressions to be evaluated
somewhere else) looks like a bigger feature then that threads are now
grouped under namespace std.
I'm note sure we are actually witnessing something like the parallel for you
talked about earlier? Are you sure?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/17/2011 04:24 PM, Marco van de Voort wrote: I'm no C++ expert, but: Where is the parallel aspect? It looks more like a shorthand to spawn a thread to evaluate an expression/closure/function call, and then wait on it using .join(). Same here. I just did a short search in the FAQ ( http://www2.research.att.com/~bs/C++0xFAQ.html ) to get a glimpse. I'm note sure we are actually witnessing something like the parallel for you talked about earlier? Are you sure? Maybe this was in the Lazarus list. But I suppose here it would be more appropriate (if at all). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On Wed, 17 Aug 2011 16:24:35 +0200 (CEST), Marco van de Voort wrote
about Re: [fpc-devel] C++ gets language-internal concurrency support:
In our previous episode, Michael Schnell said:
[snip]
int main()
{
std::thread t1{std::bind(f,some_vec)};
//*f(some_vec) executes in separate thread*
std::thread t2{F(some_vec)};
//*F(some_vec)()executes in separate thread*
t1.join();
t2.join();
}
I'm no C++ expert, but:
I am (reasonably so, at least).
Where is the parallel aspect?
The threads t1 and t2 execute in parallel. Moreover, they will execute
in parallel with any code that occurs between the declaration that
start the threads and the join() method calls that synchronize them
with the invoking thread. On a SMP system they will execute physically
in parallel, not simply timesliced against one another. The underlying
implementation model is that of POSIX threads.
This is tantamount to the TThread class (e.g. from Borland C++) becoming
part of the C++ Standard Template Library (STL). It is nothing
particularly new or special, but at least the C++ standard now
acknowledges concurrent execution and its need for reentrancy.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
signature.asc
Description: PGP signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
In our previous episode, David W Noon said: The threads t1 and t2 execute in parallel. Moreover, they will execute in parallel with any code that occurs between the declaration that start the threads and the join() method calls that synchronize them with the invoking thread. On a SMP system they will execute physically in parallel, not simply timesliced against one another. The underlying implementation model is that of POSIX threads. I know, but this is an explicit form of parallelism, and spawns one thread, not much different from Delphi tthread. (specially as coupled with anonymous methods in later versions) The .NET/Prism parallel for however spawns multiple threads, one for each for iteration, probably with some maximum. Note that I'm not so sure that the parallel for is a good (read: practical) thing to have, it is just that I noted some discrepancy in M. Schnell's original post where he tied the new C++ features to the Prism functionality. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On Wed, 17 Aug 2011 18:14:03 +0200 (CEST), Marco van de Voort wrote about Re: [fpc-devel] C++ gets language-internal concurrency support: In our previous episode, David W Noon said: The threads t1 and t2 execute in parallel. Moreover, they will execute in parallel with any code that occurs between the declaration that start the threads and the join() method calls that synchronize them with the invoking thread. On a SMP system they will execute physically in parallel, not simply timesliced against one another. The underlying implementation model is that of POSIX threads. I know, but this is an explicit form of parallelism, and spawns one thread, not much different from Delphi tthread. (specially as coupled with anonymous methods in later versions) The .NET/Prism parallel for however spawns multiple threads, one for each for iteration, probably with some maximum. This is like OpenMP and its parallelisation of FORTRAN DO-loops, which can also be used for C/C++ for-loops. It is quite a separate concept from that of the std::thread class (and its vendor-supplied predecessors). Note that I'm not so sure that the parallel for is a good (read: practical) thing to have, it is just that I noted some discrepancy in M. Schnell's original post where he tied the new C++ features to the Prism functionality. Mu FORTRAN experience of it is that it is poor practice. The granularity of the workload is too fine for the context switching overheads of threads. Perhaps the slower execution speed of CIL (.NET, Mono) byte code masks the context switching overheads and makes this practice look less inefficient. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 15 August 2011 10:48, Michael Schnell wrote: I never tried this, but I feel that IDEs (integrating code editor, GUI designer, make process, and debugger) have been invented for a purpose. I agree with all except the gui designer part. Layout Managers are by far the better choice compared to something like Delphi or Lazarus or MSEgui and even fpGUI's UI Designer gives. Java hit the nail on the head. Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc. I have also seen to many developers fight with GUI Designers to try and get them to do what the developer actually wants. I think Lazarus improved a lot over Delphi here, but Lazarus's designer is still way to complicated and error prone for complex UI's. Look at all the settings in the Align/Anchor property editors, yet often you still have to code some UI rules irrespectively. With good layout managers everything is easy - no matter how complex the UI. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 15 August 2011 10:52, Michael Schnell wrote: What is the main difference between the fpGUI designer and MiGLayout ? Like day and night. fpGUI's UI Designer is similar to Delphi or Lazarus's Form designers. Drop components, set some properties etc. The only difference there is that fpGUI's UI designer generates pascal code, and the other two generates some form object output separate from the code unit. The best way to see what MiGLayout can do, is to download the demo jar file which has a lot of examples built-in, then play around with those examples. You can even right-click on each example to do live editing, or enable the debug-mode to see how the layout manager does it's calculation and layout. There was also a nice UI competition between layout managers. A UI Form was designed, and people could submit how to recreate that form using various layout managers available. MiGLayout had very little code compared to most alternatives, and the result was often more flexible too. If you read the MiGLayout white paper, you will learn some more of the advanced features which are mind blowing! The author thought of everything. Automatically managed button orders per platform (OK, Cancel vs Cancel,OK etc), automatic style defaults per platform (border sizes around components, default sizes of buttons etc), layouts can be described in any units like pixels, mm, cm, inchs, dpi independent, alignment or anchoring or resizing can be described really simple or even by using complex expressions. I can go on and on, but rather just download the demo and see for yourself. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Graeme Geldenhuys schrieb: I think Lazarus improved a lot over Delphi here, but Lazarus's designer is still way to complicated and error prone for complex UI's. Look at all the settings in the Align/Anchor property editors, yet often you still have to code some UI rules irrespectively. With good layout managers everything is easy - no matter how complex the UI. +1 Unfortunately the added Lazarus layout options can not be removed any more, from TControl, TWinControl etc. I just wonder what will come next, in an attempt to add more layout features to the LCL :-( Currently the only chance, to disable all layout features, seems to be the use of an DockManager - which is not much more than a layout manager. The LCL developers missed that simple fact, and continue to add layout features to every single control, instead of letting the user choose layout managers from an (extensible) set of predefined layout managers. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Graeme Geldenhuys schrieb: On 15 August 2011 10:52, Michael Schnell wrote: What is the main difference between the fpGUI designer and MiGLayout ? [...] If you read the MiGLayout white paper, you will learn some more of the advanced features which are mind blowing! The author thought of everything. This is exactly the wrong approach, that also invaded the LCL layout management. Real life proves that there cannot exist one single solution for everything :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
