Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Vincent Snijders wrote:
Instead of testing for arm cpu, you could use
FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well.
yes, the changed patch is attached.
Regards, Bernd.
Index: packages/graph/src/inc/gtext.inc
===
--- packages/graph/src/inc/gtext.inc(Revision 10376)
+++ packages/graph/src/inc/gtext.inc(Arbeitskopie)
@@ -68,7 +68,12 @@
{ pStroke = ^TStroke;}
+
+{$ifdef FPC_REQUIRES_PROPER_ALIGNMENT}
+ TStroke = record { avoid misaligned data access }
+{$else}
TStroke = packed record
+{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
opcode: byte;
x: smallint; { relative x offset character }
y: smallint; { relative y offset character }
___
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.
Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Vincent ___ 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] Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the code is speed critical, packed should not be used for aby platform. Therefore I would like Bernd to consider the use of the 'unaligned' pseudo-function, ifdefs make code less readable. The patch removes packed record for some platforms. IMO packed can be removed for all platforms. It will gain some speed. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch, font rendering on Arm-Linux devices.
Hello,
the attached patch avoids misaligned data access (bus errors), during
font rendering (with the graph unit) on Arm-Linux devices.
Regards, Bernd.
Index: packages/graph/src/inc/gtext.inc
===
--- packages/graph/src/inc/gtext.inc(Revision 10376)
+++ packages/graph/src/inc/gtext.inc(Arbeitskopie)
@@ -68,7 +68,12 @@
{ pStroke = ^TStroke;}
+
+{$ifdef cpuarm}
+ TStroke = record { avoid misaligned data access }
+{$else}
TStroke = packed record
+{$endif cpuarm}
opcode: byte;
x: smallint; { relative x offset character }
y: smallint; { relative y offset character }
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Unexpected behaviour for With ... Do construct
I've hit a subtle issue whilst using the With ... Do construct in a program I am working on. I have isolated the behaviour to the following trivial unit: Unit TestClasses; Interface Type TOtherClass = Class Public SomeValue: Boolean; End; TMainClass = Class Public FOtherClass: TOtherClass; Procedure DoSomething; End; Implementation Procedure TMainClass.DoSomething; Var Test: Boolean; Begin // This compiles ok: Test := FOtherClass.SomeValue; // This Fails to compile: With FOtherClass Do; Test := SomeValue; End; End. The compilation halts with: TestClasses.pas(27,22) Error: Identifier not found SomeValue I am working off Lazarus SVN with FPC 2.2.1 on Windows and 2.2.0 on Linux. The problem occurs in both environments, the version stamps are: v0.9.25 r14253 i386-win32-win32/win64 v0.9.25 r14253M i386-linux-gtk 2 (beta) Is this a compiler bug or am I missing something? Thanks, Paul ___ 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 Tue, 26 Feb 2008, schreef Vincent Snijders: Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the code is speed critical, packed should not be used for aby platform. Therefore I would like Bernd to consider the use of the 'unaligned' pseudo-function, ifdefs make code less readable. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected behaviour for With ... Do construct
You made the following error: With FOtherClass Do; You added semiclone after do, so you exist the scope of with ...Actually the compiler works really good in this case :) Ido On Tue, Feb 26, 2008 at 1:11 PM, [EMAIL PROTECTED] wrote: I've hit a subtle issue whilst using the With ... Do construct in a program I am working on. I have isolated the behaviour to the following trivial unit: Unit TestClasses; Interface Type TOtherClass = Class Public SomeValue: Boolean; End; TMainClass = Class Public FOtherClass: TOtherClass; Procedure DoSomething; End; Implementation Procedure TMainClass.DoSomething; Var Test: Boolean; Begin // This compiles ok: Test := FOtherClass.SomeValue; // This Fails to compile: With FOtherClass Do; Test := SomeValue; End; End. The compilation halts with: TestClasses.pas(27,22) Error: Identifier not found SomeValue I am working off Lazarus SVN with FPC 2.2.1 on Windows and 2.2.0 on Linux. The problem occurs in both environments, the version stamps are: v0.9.25 r14253 i386-win32-win32/win64 v0.9.25 r14253M i386-linux-gtk 2 (beta) Is this a compiler bug or am I missing something? Thanks, Paul ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- http://ik.homelinux.org/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected behaviour for With ... Do construct
Many Thanks... I've been staring at that all morning! Too many late nights. Paul You made the following error: With FOtherClass Do; You added semiclone after do, so you exist the scope of with ...Actually the compiler works really good in this case :) Ido ___ 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 schrieb: Op Tue, 26 Feb 2008, schreef Vincent Snijders: Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the Isn't this used to read a font file? ___ 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 Tue, 26 Feb 2008, schreef Florian Klaempfl: Daniël Mantione schrieb: Op Tue, 26 Feb 2008, schreef Vincent Snijders: Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the Isn't this used to read a font file? You are right. Therefore, the unaligned pseudo function is the proper solution. 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 Tue, 26 Feb 2008, schreef Florian Klaempfl: Daniël Mantione schrieb: Op Tue, 26 Feb 2008, schreef Vincent Snijders: Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the Isn't this used to read a font file? You are right. Therefore, the unaligned pseudo function is the proper solution. the main affected routines are unpack and decode. Both routines were called for every single character (only for a stroked font) via OutTextXYDefault. So speed is not unimportant ;-) Regards, Bernd. ___ 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.
Bernd Mueller wrote: the main affected routines are unpack and decode. Both routines were called for every single character (only for a stroked font) via OutTextXYDefault. So speed is not unimportant ;-) Perhaps you can separate I/O and processing? Read into unpacked structure and process from there? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
On Mon, Feb 25, 2008 at 10:12 AM, Michael Schnell [EMAIL PROTECTED] wrote: IMHO, nowadays, 8 (and 16) bit processors only make sense for very small projects. Those are very hardware specific and thus using C here does make sense. I have to disagree with this one, depending with what small means. If you mean small in project complexity, I'd say this is very far from true. BOSCH uses 8-bit microcontrolers (8051) widely inside several sensors (tire pressure sensors for example) and I'm sure I wouldn't call those projects simple considering the number of workers and years involved on them. If you mean small in size, then maybe =) The sensors are really small. Also considering how much time I saw the other internship student waste trying to understand the criptic C code for the microcontroler I'd also disagree that using C is necessarely the best choice. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
Of course you are right. By small I meant the size of the task the processor is supposed to do and thus to some extend the estimated effort needed for programming. If you plan a device that is to be sold in huge quantities, you select the cheapest possible processor whatsoever, completely disregarding the programming effort. I suppose here using Pascal is never considered anyway. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
Felipe Monteiro de Carvalho ha scritto: On Mon, Feb 25, 2008 at 10:12 AM, Michael Schnell [EMAIL PROTECTED] wrote: IMHO, nowadays, 8 (and 16) bit processors only make sense for very small projects. Those are very hardware specific and thus using C here does make sense. I have to disagree with this one, depending with what small means. If you mean small in project complexity, I'd say this is very far from true. BOSCH uses 8-bit microcontrolers (8051) widely inside several sensors (tire pressure sensors for example) and I'm sure I wouldn't call those projects simple considering the number of workers and years involved on them. If you mean small in size, then maybe =) The sensors are really small. Also considering how much time I saw the other internship student waste trying to understand the criptic C code for the microcontroler I'd also disagree that using C is necessarely the best choice. If Pascal, or another decent language is available, C is *never* the best choice. :-) Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
