marc at dommelstein.net
Sun Oct 17 19:48:21 CEST 2004
At 20:02 16-10-2004, Florian Klaempfl wrote:
>Marc Weustink wrote:
>>At 00:15 14-10-2004, Florian Klaempfl wrote:
>>>Marc Weustink wrote:
>>>>At 16:38 13-10-2004, Jonas Maebe wrote:
>>>>>On 12 okt 2004, at 22:12, Marc Weustink wrote:
>>>>>>M:> Is a sigbus catchable so that you can read the data and continue
>>>>>>as if nothing happened (or is that something at OS level)
>>>>>That is normally possible, yes. But as Florian said, it's quite a bit
>>>>>of work and also extremely slow (you get 4 context switches per
>>>>>unaligned access, + the work to load the value).
>>>>Yes I do realize that there is a penalty for doing unaligned access.
>>>It's not a penalty, it's death regarding speed ;)
>>But there is still an infinite speed difference in no access and dead
>>slow access :)
>But the fault allows the programmer to optimize his program :)
Hints could also have done.
>Don't forget: Unaligned accesses also give _huge_ penalties on processors
>which even don't fault.
I do understand now that fpc doesn't support pll to write sloppy code. IMO
that is a valid reason.
>>>A solution I could imagine is that packed records are accessed
>>>correctly, i.e. shifting and oring but catching sigbus is too much imo
>>>and will cause serious performance problems.
>>As a first attempt solution, yes. I was talkin about situations where
>>everything else failed.
>>Aligning pointers, shifting and oring doesn't conflict with having a
>>The other option is to assume all pointer access unaligned and check if
>>it is the case and ifso, do shift&or. But this will affect normal
>>alligned access as well. (Or not if a compiler derective is introduced to
>>turn this behaviour locally on and off)
>>(alltough the last option isn't complete transparant, I personally would
>>prefer it above catching buserrors)
>We aren't talking even about pointer accesses, we're talking about simple
>data accesses. If we assume that every access could be unaligned, we
>should better write an interpreter.
Sorry, I mixed things up. For simple dataaccess we know what is unalingend.
>>>FPC always tries to do the best of both worlds, I guess you don't want
>>>the gpc behaviour either :)
>>Maybe I do, but without the (IMO silly) error.
>>To call p() in your example, you have to know if r.i is aligned or not
>>(and that alignment is required andsuch).
>>if alignment is needed, you need a local var in this case like:
>> h: integer;
>> h := r.i;
>> r.i := h;
>>Since the compiler already knows that r.i is unalligned (otherwise it
>>wouldn't give the error), it could generate this "wrapper" itself more
>>efficient than you can instead of giving an error.
>Using a helper is a different calling convention (copy back).
OK, it has even a name.
>Copy back was already thrown away with Fortran 66 I think because it
>caused too much trouble.
I'll believe it will give troubles in certain situations, I only have no
idea where (then again, I'm only a compiler user).
>r.i could have also an alias so the example above isn't equal to a direct
>usage of r.i.
>And keep in mind: the problem is much smaller than you think :) Normal
>pascal (without packed, ugly pointer arithmetics or absolute) compiles
>fine in 99.99 per cent of all cases. Further, all C/C++ code of e.g. KDE,
>GNOME, OpenOffice etc. works on cpus requiring alignment of data without
>special compiler tricks, ugly programmer tricks or heavy usage of memcpy.
The reason why I started this thread was that I was a bit disappointed that
running Lazarus on sparc failed. To apply all kinds of patches and ifdefs
for platforms not supporting unaligned access was not an option for me.
Today I realized that the only sensible use of packed records is when
interfacing with external libraries. The chance that this is needed
unaligned on a sparc is pretty much zero. So my request for unalinged
access makes no sense.
I'll have a look why packed records are used internally.
More information about the fpc-devel