[fpc-devel] FPC_REQUIRES_PROPER_ALIGNMENT

[Florian Klaempfl]

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 :) Don't 
forget: Unaligned accesses also give _huge_ penalties on processors 
which even don't fault.

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

>> 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). Copy back 
was already thrown away with Fortran 66 I think because it caused too 
much trouble. r.i could have also an alias so the example above isn't 
equal to a direct usage of r.i.

> 
> Something related, how are the following arrays accessed ?
> array[0..10] of Byte;
> packed array[0..10] of Byte;
> array[0..10] of Word;
> packed array[0..10] of Word;

The are equal in FPC and are simply accessed with byte and word reads 
without any trouble.

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.