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
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
__
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
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.i
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:
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.
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 co
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
__
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 c
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.
Instea
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-
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 f
Op Tue, 26 Feb 2008, schreef Bernd Mueller:
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), dur
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 "sma
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Bernd Mueller:
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
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 disr
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 w
17 matches
Mail list logo