Re: [fpc-devel] Unicode resourcestrings
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. Are there plans to implement unicode resourcestrings? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it looks quite different (and I'm not sure about all the types used here, some seem to be sets, some enumerations). Can be configured: http://lists.freepascal.org/docs-html/prog/progsu50.html Delphi has the minenumsize one, not the packset one. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. There is utf8decode/utf8encode. Are there plans to implement unicode resourcestrings? No, but this is just because you are the first one to ask. Could you make a proposal? Then we'll see how this can be implemented. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
This does work nicely ! Any chance to be able to use this in the foreseeable future ? What kind of license do you intend to use ? (Sourcecode is a must for us, of course.) Thanks agian, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
I made a demo of MSEifi with a server and a client connected by pipes. Win32 binaries: http://msedocumenting.svn.sourceforge.net/viewvc/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo/bin/i386-win32/ifipipedemoclient.exe?view=log and http://msedocumenting.svn.sourceforge.net/viewvc/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo/bin/i386-win32/ifipipedemoserver.exe?view=log Download ifipipedemoclient.exe and ifipipedemoserver.exe into yourdirectory, cd yourdirectory, run ifipipedemoclient.exe, click 'connect'. Screenshot: http://www.homepage.bluewin.ch/msegui/pics/mseifidemo.png Great thanks ! I'll take a look ASAP ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. There is utf8decode/utf8encode. The big advantage of resourcestrings is that they can be used like normal string constants in the source. If I need to call utf8encode for every used stringconstant I can use the MSEgui widestring stockcaption facility instead. Are there plans to implement unicode resourcestrings? No, but this is just because you are the first one to ask. Could you make a proposal? Then we'll see how this can be implemented. Ideally from my point of view would be if the resourcestrings are stored in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode for widestring assignment on runtime independent of the system encoding. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
The VirtualTreeView tries to make the fields of the (packed) record aligned at dword boundary by grouping together smaller (one or two byte fields) or adding dummy fields. Does this trick overrides the unaligned memory access? Of course it is always a good idea to sort the members of a record according to their size (if size is 2**n: order from big to small). As there is no definition about how the compiler is to place the record elements in a record, IMHO the compiler should do this automatically, unless the record is defined as (bit-)packed. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.25:18 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. There is utf8decode/utf8encode. The big advantage of resourcestrings is that they can be used like normal string constants in the source. If I need to call utf8encode for every used stringconstant I can use the MSEgui widestring stockcaption facility instead. Are there plans to implement unicode resourcestrings? No, but this is just because you are the first one to ask. Could you make a proposal? Then we'll see how this can be implemented. Ideally from my point of view would be if the resourcestrings are stored in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode for widestring assignment on runtime independent of the system encoding. This has been discussed before. Automatic conversion to/from ansistrings will always be to/from system encoding. If you want another encoding than the system encoding you will have to do a manual conversion. For the compiler, a resourcestring has the same type as an ansistring, so no distinction can be made between resourcestrings/ansistrings. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
On 29 Feb 2008, at 01:55, Luiz Americo Pereira Camara wrote: One more question: The VirtualTreeView tries to make the fields of the (packed) record aligned at dword boundary by grouping together smaller (one or two byte fields) or adding dummy fields. Does this trick overrides the unaligned memory access? Not at this time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
It depends what effort you plan to invest into testing and debugging. ;-) Missing pieces: - Documentation. - SSL on win32. - Consistent error handling and error recovery. - Pascalscript import units for complete MSEgui. - MSEifi webbrowser plugin. - Some convenience tools in MSEide for MSEifi project handling. As I pointed out, we (on the long run) have to do two projects which include remote a GUI. (1) Server done in Delphi running on a dedicated PC, no chance to install any non-standard software on the Terminal or use any non-standard protocols (2) Server is an embedded device, software done in Free Pascal, there can be our software on the Terminal, protocol: any kind of TCP/IP. I feel that MSEifi might help doing (2), as it needs software (at least a dll for the plugin) installed on the Terminal. So I suppose I don't need SSL, Pascalscript and a browser plugin. Regarding convenience tools: This project is not going to be started soon. It's an add-on for a Linux based embedded device that we are planning. First the hardware and the main function is to be crafted, this add-on will be the second step. And this step includes porting the Free Pascal compiler to the NIOS CPU (unless this is done by somebody else before we can start). Before I knew about MSEifi I intended to attach the remote GUI on a per-control base via a propriety protocol (e.g. using RemObjects). But this would imply handling any program done that way individually, which of course is not really desirable. Do you think MSEifi will help ? An additional consideration is to provide a miniature remote GUI for the primary firmware (done in ANSI C) of the device in a way consistent with the GUI planned for the future Pascal add-on. Do you think MSEifi will help with that ? MSEide is GPL, MSEgui and MSEifi use the same modified LGPL license as the FPC RTL. The code is on Sourceforge: http://sourceforge.net/svn/?group_id=165409 Sounds good ! During my investigations on open source software licenses I heard about some drawbacks when using LGPL code in embedded devices (it might be problematic to provide the requested support for the users to upgrade to a new version of the LGPL'ed libraries when statically linking, which is why sometimes it's recommended not to use the µCLinux version of glibc). But I do think this should be solvable, as I don't think it's intended by the FSF and the individual copyright holders to prevent the use of LGPL'ed code in embedded devices, only because they don't have an MMU and thus don't support .so's. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On 29 Feb 2008, at 09:25, Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Are there plans to implement unicode resourcestrings? No, but this is just because you are the first one to ask. There is already a bug report about it: http://bugs.freepascal.org/view.php?id=6477 Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.25:18 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. There is utf8decode/utf8encode. The big advantage of resourcestrings is that they can be used like normal string constants in the source. If I need to call utf8encode for every used stringconstant I can use the MSEgui widestring stockcaption facility instead. Are there plans to implement unicode resourcestrings? No, but this is just because you are the first one to ask. Could you make a proposal? Then we'll see how this can be implemented. Ideally from my point of view would be if the resourcestrings are stored in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode for widestring assignment on runtime independent of the system encoding. This has been discussed before. Automatic conversion to/from ansistrings will always be to/from system encoding. If you want another encoding than the system encoding you will have to do a manual conversion. For the compiler, a resourcestring has the same type as an ansistring, so no distinction can be made between resourcestrings/ansistrings. Another suggestion: implementation resourcestrings resstring1 = 'abc'; resstring2 = '1234'; resourcewidestrings resstring3 = 'abc'; resstring4 = '1234'; procedure test; var wstr1,wstr2: widestring; begin wstr1:= resstring3; //no conversion wstr2:= resstring1; //uses system encoding to convert end; Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
On Friday 29 February 2008 10.49:11 Michael Schnell wrote: Before I knew about MSEifi I intended to attach the remote GUI on a per-control base via a propriety protocol (e.g. using RemObjects). But this would imply handling any program done that way individually, which of course is not really desirable. Do you think MSEifi will help ? Sure, it is the purpose of MSEifi to connect client MSEgui objects and events with server events and data by the use of an universal client program. An additional consideration is to provide a miniature remote GUI for the primary firmware (done in ANSI C) of the device in a way consistent with the GUI planned for the future Pascal add-on. Do you think MSEifi will help with that ? I don't know. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
On Friday 29 February 2008 10.07:29 Dani?l Mantione wrote: Another suggestion: implementation resourcestrings resstring1 = 'abc'; resstring2 = '1234'; resourcewidestrings resstring3 = 'abc'; resstring4 = '1234'; I don't like inventing Delphi incompat syntax for it, specially since probably starting with D2008 resourcestrings will be unicode too. So a directive would make more sense (and more importantly, that can be abstracted in e.g. a global include files as many OSS pascal projects do) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Sure, it is the purpose of MSEifi to connect client MSEgui objects and events with server events and data by the use of an universal client program. Sounds good. Let me elaborate a bit more: The program in question needs to be ported from a a project running in Delphi. I do know how to port Delphi projects to Lazarus, and I do know how to debug using Lazarus, but I have no idea how to port Delphi projects to MSE and how to do debugging with MSE. Our programmers are trained on Delphi and I do feel that they will be able to work with Lazarus quite easily. I suppose you rather suggest to completely use MSE tools, but might it be a viable option to do the project in Lazarus and use MSEifi nonetheless ? Is it easy to install and try the MSE IDE ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
On Friday 29 February 2008 11.27:47 Michael Schnell wrote: Sure, it is the purpose of MSEifi to connect client MSEgui objects and events with server events and data by the use of an universal client program. Sounds good. Let me elaborate a bit more: The program in question needs to be ported from a a project running in Delphi. I do know how to port Delphi projects to Lazarus, and I do know how to debug using Lazarus, but I have no idea how to port Delphi projects to MSE and how to do debugging with MSE. Our programmers are trained on Delphi and I do feel that they will be able to work with Lazarus quite easily. MSEide+MSEgui compiles with Delphi7 with exception of DB components and therefore the adjacent MSEifi DB components. It should be possible to patch FPC db.pas in order it can be compiled with Delphi. MSEide uses gdb as Lazarus does, gdb integration of MSEide is possible a little bit better than the Lazarus one (widestrings, dynamic arrays...). MSEide and Lazarus both suffer from gdb problems on win32. I suppose you rather suggest to completely use MSE tools, but might it be a viable option to do the project in Lazarus and use MSEifi nonetheless ? No, VCL/LCL widgets and MSEgui widgets are incompatible. Is it easy to install and try the MSE IDE ? I can't believe it, you never tried MSEide+MSEgui? Installation instructions: http://www.homepage.bluewin.ch/msegui/ and in README.TXT in the distribution. For the ifipipe demo you need the SVN trunk version and the compiler option -dmse_with_ifi. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
This has been discussed before. Automatic conversion to/from ansistrings will always be to/from system encoding. If you want another encoding than the system encoding you will have to do a manual conversion. Actually you as the application developer can control how conversions between ansistrings and widestrings are handled by using getwidestringmanager/setwidestringmanager . So for example you could use a byte value of $7F at the beggining of an ansistring as a marker that the string was in UTF-8 and implement a Ansi2WideMoveProc that checked for it and either interpreted it as UTF-8 if it saw the marker and passed it off to the old Ansi2WideMoveProc if not. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
MSEide+MSEgui compiles with Delphi7 with exception of DB components and therefore the adjacent MSEifi DB components. It should be possible to patch FPC db.pas in order it can be compiled with Delphi. MSEide uses gdb as Lazarus does, gdb integration of MSEide is possible a little bit better than the Lazarus one (widestrings, dynamic arrays...). MSEide and Lazarus both suffer from gdb problems on win32. We don't need visual db components. So no problem here. No, VCL/LCL widgets and MSEgui widgets are incompatible. OK. That is understandable Is it easy to install and try the MSE IDE ? I can't believe it, you never tried MSEide+MSEgui? In fact I still don't know what it really is. At home I monitored the newsgroup for a while and once same was canceled, I thought the thing would be dead. (Like other Delphi related project I monitored died: Kylix / Cross-Kylix / Cross FPC and I had the impression that Lazarus would be collecting everyone remaining.) Installation instructions: http://www.homepage.bluewin.ch/msegui/ and in README.TXT in the distribution. For the ifipipe demo you need the SVN trunk version and the compiler option -dmse_with_ifi. Should I use Windows or Linux ? I'll take a look. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
On Friday 29 February 2008 14.16:18 Michael Schnell wrote: In fact I still don't know what it really is. At home I monitored the newsgroup for a while and once same was canceled, I thought the thing would be dead. (Like other Delphi related project I monitored died: Kylix / Cross-Kylix / Cross FPC and I had the impression that Lazarus would be collecting everyone remaining.) The MSEide+MSEgui newsgroup: news://news.grid-sky.com/public.mseide-msegui.talk (more than 10'000 messages). You monitored probably the public.kylix.talk newsgroup and there I fond your post from 2006-01-09: Martin Schreiber wrote: There is another alternative to Delphi-Kylix: http://mypage.bluewin.ch/msegui/ Downloaded and installed. Firsts tests Worked on the spot ! Even debugging (single stepping). I'll go on testing tomorrow. -Michael ;-) Should I use Windows or Linux ? Linux of course. I'll take a look. You are welcome. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Tue, 26 Feb 2008, schreef Luiz Americo Pereira Camara: Yury Sidorov wrote: The patch removes packed record for some platforms. IMO packed can be removed for all platforms. It will gain some speed. I'd like to understand more this issue. Why are non packed records faster? Cache trashing. One of the most underestimated performance killers in modern software. The difference occurs at memory allocation or at memory access? Memory access. What happens is that the non-packed version causes more cache misses. A cache miss costs many cycles on a modern cpu, a misaligned read just costs an extra memory access (which is fast if cached) on x86, and extra load instruction on ARM. This much cheaper than a chache miss. It's much worse than that. Some architectures simply _can't_ do unaligned access, and they will trigger an exception. This exception will in many configurations be caught by the OS, that then might simulate the read by doing 2 reads, putting the result together, writing into the application memory, and doing a task switch. This, in total, is several _orders of magnitude_ worse than unaligned access on a supported platform. Of course, unaligned access in itself is pretty bad. -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
Martin Schreiber wrote: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. Are there plans to implement unicode resourcestrings? There is a non-ambiguous UTF-8 to UTF-16 mapping. It should be no problem at all, except for the extra programming effort. -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Memory access. What happens is that the non-packed version causes more cache misses. A cache miss costs many cycles on a modern cpu, a misaligned read just costs an extra memory access (which is fast if cached) on x86, and extra load instruction on ARM. This much cheaper than a chache miss. It's much worse than that. Some architectures simply _can't_ do unaligned access, and they will trigger an exception. This exception will in many configurations be caught by the OS, that then might simulate the read by doing 2 reads, putting the result together, writing into the application memory, and doing a task switch. This, in total, is several _orders of magnitude_ worse than unaligned access on a supported platform. Of course, unaligned access in itself is pretty bad. True, but irrelevant, because the discussion was under the assumption than an unaligned read is done using the unaligned pseudo function. Unless there is a bug in the compiler, the use of unaligned will never cause an exception. Oh, you're right of course. I didn't catch that part of the argument. Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Op Fri, 29 Feb 2008, schreef Christian Iversen: Memory access. What happens is that the non-packed version causes more cache misses. A cache miss costs many cycles on a modern cpu, a misaligned read just costs an extra memory access (which is fast if cached) on x86, and extra load instruction on ARM. This much cheaper than a chache miss. It's much worse than that. Some architectures simply _can't_ do unaligned access, and they will trigger an exception. This exception will in many configurations be caught by the OS, that then might simulate the read by doing 2 reads, putting the result together, writing into the application memory, and doing a task switch. This, in total, is several _orders of magnitude_ worse than unaligned access on a supported platform. Of course, unaligned access in itself is pretty bad. True, but irrelevant, because the discussion was under the assumption than an unaligned read is done using the unaligned pseudo function. Unless there is a bug in the compiler, the use of unaligned will never cause an exception. Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. A cache miss is very expensive with latencies of modern memory. A smaller array results in less cache misses. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Op Fri, 29 Feb 2008, schreef Christian Iversen: Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. Unlike modern x86 processors? Granted, I haven't timed it, but most processors since early P4 models are supposed to have Streaming access detection, which is a fancy way of saying array detection. Are you sure your information is current? Please read again. I said modern X86 processors have, ARM processors don't have. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. Unlike modern x86 processors? Granted, I haven't timed it, but most processors since early P4 models are supposed to have Streaming access detection, which is a fancy way of saying array detection. Are you sure your information is current? (I could be wrong too, of course) -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
From: Daniël Mantione [EMAIL PROTECTED] Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. A cache miss is very expensive with latencies of modern memory. A smaller array results in less cache misses. I run my benchmark on ARM mobile and got the following results: 2080ms - for non-packed 4450ms - for packed It clearly shows that ualigned access kills performance on ARM... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. Unlike modern x86 processors? Granted, I haven't timed it, but most processors since early P4 models are supposed to have Streaming access detection, which is a fancy way of saying array detection. Are you sure your information is current? Please read again. I said modern X86 processors have, ARM processors don't have. Sorry, it's just really not my day today.. ;-) I'll now go join another discussion without reading it properly, in turn annoying even more people.. :-) -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Vinzent Hoefler wrote: Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it looks quite different (and I'm not sure about all the types used here, some seem to be sets, some enumerations). But at the first glance it seems, they used both packed records to either ensure minimum size or known record layout (maybe they even used the structure in some assembly module?), and also aligned them manually to avoid unaligned access issues. Yes. VirtualTreeView/Delphi uses asm instructions The size of sets are different from delphi to fpc making the record structure different. This is the record structure (size and offsets) in both compilers: fpc: Index Size: 4 Offset: 0 ChildCount Size: 4 Offset: 4 NodeHeight Size: 2 Offset: 8 States Size: 4 Offset: 10 Align Size: 1 Offset: 14 CheckState Size: 1 Offset: 15 CheckType Size: 1 Offset: 16 Dummy Size: 1 Offset: 17 Delphi: Index Size: 4 Offset: 0 ChildCount Size: 4 Offset: 4 NodeHeight Size: 2 Offset: 8 States Size: 2 Offset: 10 Align Size: 1 Offset: 12 CheckState Size: 1 Offset: 13 CheckType Size: 1 Offset: 14 Dummy Size: 1 Offset: 15 Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Jonas Maebe wrote: On 29 Feb 2008, at 01:55, Luiz Americo Pereira Camara wrote: One more question: The VirtualTreeView tries to make the fields of the (packed) record aligned at dword boundary by grouping together smaller (one or two byte fields) or adding dummy fields. Does this trick overrides the unaligned memory access? Not at this time. Due to differences in sets size, the layout is different between fpc and Delphi. Using packed records i save 4 bytes per record. Compiled under Delphi the structure is bellow. The question is: using the layout below with packed (i can force the set size to be equal to Delphi) i still have unaligned memory access? Index Size: 4 Offset: 0 ChildCount Size: 4 Offset: 4 NodeHeight Size: 2 Offset: 8 States Size: 2 Offset: 10 Align Size: 1 Offset: 12 CheckState Size: 1 Offset: 13 CheckType Size: 1 Offset: 14 Dummy Size: 1 Offset: 15 Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
On 01 Mar 2008, at 02:00, Luiz Americo Pereira Camara wrote: The question is: using the layout below with packed (i can force the set size to be equal to Delphi) i still have unaligned memory access? As long as you record is declared as packed, all memory accesses are handled as if they are to unaligned memory locations. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
