[fpc-devel] CrossFPC
Hi! I need something to play with! Where can I get an alpha version of CrossFPC? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MacOSX: EXC_ARITHMETIC in PerformHIConversion
Hi,
I don't know if it is FCP problem, it looks like it is, but I can't see how.
In XCode i've created a Carbon app with the given in main.c. When
running this, everything works as expected. However when I replace
Hello.app/Contents/MacOS/Hello with a version created by FPC from
hello.pp, I get an exception when I hover with the mouse over the Hello
- Services - FileMerge menuitem (this is an empty submenu)
Now what I don't get is what this has to do with the fpc generated exe.
AFAIK this menu is handled by the OS internally.
Am I missing something ? Am I not allowed to change the exe ? Or is it
something FPC had to compile in the exe but didn't do ?
Anyone any clue ?
TIA, Marc
--- main.c ---
#include
int main(int argc, char* argv[])
{
WindowRef window;
OSStatuserr;
RectR;
R.top = 50; R.left = 50; R.right = 500; R.bottom = 200;
err = CreateNewWindow(
kDocumentWindowClass,
kWindowStandardDocumentAttributes |
kWindowStandardHandlerAttribute |
kWindowInWindowMenuAttribute,
&R, &window);
require_noerr( err, CantCreateWindow );
// The window was created hidden so show it.
ShowWindow( window );
// Call the event loop
RunApplicationEventLoop();
CantCreateWindow:
return err;
}
--- hello.pp ---
program FPCCarbon;
{$mode objfpc}
uses
Carbon;
label
CantCreateWindow;
var
R : Rect;
err : OSStatus;
window : WindowRef;
begin
R.Top := 50; R.Left := 50; R.Right := 500; R.Bottom := 200;
err := CreateNewWindow(
kDocumentWindowClass,
kWindowStandardDocumentAttributes or
kWindowStandardHandlerAttribute or
kWindowInWindowMenuAttribute,
R, window);
if err <> noErr then
goto CantCreateWindow;
// The window was created hidden so show it.
ShowWindow(window);
// Call the event loop
RunApplicationEventLoop;
// Error Handling
CantCreateWindow:
Halt(err);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for fixing bug 4117
On Sun, 14 Aug 2005, Peter Vreman wrote: > At 13:19 14-8-2005, you wrote: > > Hi, > > > > attached is a patch from Juergen Rathlev which *should* fixes bug 4117 and > > may fix 4234, too. It removes using of qword from fpreadpng.pp because > > qword seems to be buggy and may probably improve the performance of some > > functions, too, because it avoids redundant shifting operations. > > If qword is buggy then that needs to be fixed. Applying this patch will only > hide the real bug in the compiler. > > The compiler bug needs to be fixed first before this patch can be applied > otherwise it is not reproducable anymore. > > FYI i already analysed it a little a before my holiday, the bug only happends > when optimization with -O2 is done. Seems I was too fast for you :/ The patch created revision 859, so you can reproduce with version 858... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for fixing bug 4117
On Sun, 14 Aug 2005, Dirk wrote: > Hi, > > attached is a patch from Juergen Rathlev which *should* fixes bug 4117 and may > fix 4234, too. It removes using of qword from fpreadpng.pp because qword seems > to be buggy and may probably improve the performance of some functions, too, > because it avoids redundant shifting operations. Thank you, I reviewed and committed the patch. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for fixing bug 4117
At 13:19 14-8-2005, you wrote: Hi, attached is a patch from Juergen Rathlev which *should* fixes bug 4117 and may fix 4234, too. It removes using of qword from fpreadpng.pp because qword seems to be buggy and may probably improve the performance of some functions, too, because it avoids redundant shifting operations. If qword is buggy then that needs to be fixed. Applying this patch will only hide the real bug in the compiler. The compiler bug needs to be fixed first before this patch can be applied otherwise it is not reproducable anymore. FYI i already analysed it a little a before my holiday, the bug only happends when optimization with -O2 is done. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch for fixing bug 4117
Hi,
attached is a patch from Juergen Rathlev which *should* fixes bug 4117
and may fix 4234, too. It removes using of qword from fpreadpng.pp
because qword seems to be buggy and may probably improve the performance
of some functions, too, because it avoids redundant shifting operations.
Dirk Rathlev
--- fpreadpng.pp.orig 2005-08-14 12:48:39.0 +0200
+++ fpreadpng.pp 2005-08-14 12:54:25.0 +0200
@@ -1,4 +1,5 @@
{
+$Id: fpreadpng.pp,v 1.10 2003/10/19 21:09:51 luk Exp $
This file is part of the Free Pascal run time library.
Copyright (c) 2003 by the Free Pascal development team
@@ -518,7 +519,7 @@ end;
function TFPReaderPNG.ColorGrayAlpha16 (CD:TColorData) : TFPColor;
var c : word;
begin
- c := (CD and qword($)) shr 16;
+ c := (CD shr 16) and $;
with result do
begin
red := c;
@@ -535,56 +536,59 @@ begin
begin
c := CD and $FF;
red := c + (c shl 8);
-c := CD and $FF00;
-green := c + (c shr 8);
-c := (CD and $FF) shr 8;
-blue := c + (c shr 8);
+CD:=CD shr 8;
+c := CD and $FF;
+green := c + (c shl 8);
+CD:=CD shr 8;
+c := CD and $FF;
+blue := c + (c shl 8);
alpha := alphaOpaque;
end;
end;
function TFPReaderPNG.ColorColor16 (CD:TColorData) : TFPColor;
-var c : qword;
begin
with result do
begin
red := CD and $;
-c := qword($);
-green := (CD and c) shr 16;
-c := c shl 16;
-blue := (CD and c) shr 32;
+CD:=CD shr 16;
+green := CD and $;
+CD:=CD shr 16;
+blue := CD and $;
alpha := alphaOpaque;
end;
end;
function TFPReaderPNG.ColorColorAlpha8 (CD:TColorData) : TFPColor;
-var c : qword;
+var c : word;
begin
with result do
begin
c := CD and $FF;
red := c + (c shl 8);
-c := CD and $FF00;
-green := c + (c shr 8);
-c := (CD and $FF) shr 8;
-blue := c + (c shr 8);
-c := (CD and qword($FF00)) shr 16;
-alpha := c + (c shr 8);
+CD:=CD shr 8;
+c := CD and $FF;
+green := c + (c shl 8);
+CD:=CD shr 8;
+c := CD and $FF;
+blue := c + (c shl 8);
+CD:=CD shr 8;
+c := CD and $FF;
+alpha := c + (c shl 8);
end;
end;
function TFPReaderPNG.ColorColorAlpha16 (CD:TColorData) : TFPColor;
-var c : qword;
begin
with result do
begin
red := CD and $;
-c := qword($);
-green := (CD and c) shr 16;
-c := c shl 16;
-blue := (CD and c) shr 32;
-c := c shl 16;
-alpha := (CD and c) shr 48;
+CD:=CD shr 16;
+green := CD and $;
+CD:=CD shr 16;
+blue := CD and $;
+CD:=CD shr 16;
+alpha := CD and $;
end;
end;
@@ -830,3 +834,4 @@ end;
initialization
ImageHandlers.RegisterImageReader ('Portable Network Graphics', 'png', TFPReaderPNG);
end.
+
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
At 07:33 8-8-2005, you wrote: | > Okay, I researched the topic. Of course, yes, you can export functions from an executable | > on linux. But freepascal doesn't seem to like it just yet. | | How do you intend to use the exported symbols of an stand-alone | executable? | As a shared library, or how else? A shared library can call functions from the executable that it is running from. Two way communication is very important to me. | Perhaps Linux and Windows executable files are not too different. On They aren't really, is what I found, after reseaching them. | Windows the file format (MZ) is the same for DLLs and EXE files, the | main difference is the invocation through the WinMain or LibMain entry | points. On Linux the shared libraries may have a similar implementation, | so that the exported symbols can be used only with shared library | modules. Functions can be used in executables in linux by calling the -export-dynamic or -E with the linker (LD), but it isn't working yet with freepascal. Works with GCC (also called -rdynamic). In windows, you can either get the handle of the exe using getmodule, and then getprocaddress(exehandle, 'myproc')or you can just call statically procedure myproc; external 'myprogram.exe'; (instead of mylibrary.dll ). I asked some GCC guys "can an elf executable export functions?" and they sort of laughed at me. They do it all the time, and they wondered why I was asking such an obvious question. But I honestly think a lot of people don't know you can do this. Without being able to export functions form an executable, I find it's sort of like having a client without a server. Why have a client without a server? To me, it is essential for the executable to export functions.. (this is where the true power can be squeezed out of plug-in systems - Lazarus RB Edition relies on this and would never work without it...unless I used sockets, interprocess communication, or something similar.) If gcc can do it also fpc can be made to do it. But for me it has no priority to add support for this to fpc. Ofcourse patches are welcome. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] inline and asm code
At 10:46 3-8-2005, you wrote:
> I would suggest an "experimental" solution {$inline unsafe ?} which
does the
> inline without checks, and maybe gives a warning at compiletime: Warning:
> inlined func/proc might be unsafe.
The used registers still have to be known. For pascal code this is info that
is gained during the compilation. For asm this is afaik not kept.
However if sb would work on this and submit a patch (scanning assembler blocks
to build a register use), it would probably help.
> Could save some code and some exection time.
>
> I do not understand the argument with e.g. EBP usage. I would say this is
> dangerous in not inlined code also, isn't it?
procedure x(a:integer);assembler; stdcall;
asm
movl 8(%ebp),%eax
end;
Will load parameter in eax. However when inlined it will fail.
Also a lot of assembler procedures (coming from delphi) expect the
parameters in specific registers. The compiler then firsts needs to load
the values in these registers like the register calling convention
describes. The result is in a lot of cases not what was expected and it
makes the compiler a lot more complex regarding inlining. So for now the
inlining of assembler code is disabled to keep the code in the compiler
simple. Also note that this behaviour is compatible with delphi 2005.
Peter
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
