[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