[fpc-devel] FPC_REQUIRES_PROPER_ALIGNMENT

[Marc Weustink]

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 
>>fallback.
>>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:
>>var
>>   h: integer;
>>begin
>>   h := r.i;
>>   p(h);
>>   r.i := h;
>>end;
>>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.

alias ??


>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.

Marc