[fpc-devel] FPC_REQUIRES_PROPER_ALIGNMENT

Marc Weustink marc at dommelstein.net
Sat Oct 16 16:53:26 CEST 2004


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 :)

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

>BTW: Does anybody have TP 5.5 for m68k and can test what it does :)?
>
>gpc accesses packed records correctly but it doesn't allow to take the 
>address of a field of a packed record.
>
>gpc example:
>
>program test;
>
>procedure p(var i : integer);
>   begin
>   end;
>
>var
>   r : packed record
>     c : char;
>     i : integer;
>   end;
>
>begin
>   r.i:=1; <--- works
>   p(r.i); <--- test.p:15: packed fields may not be used as `var' parameters
>end.
>
>>This will throw away all advantages away form pascal (like strong typing 
>>etc).
>>And if you forget to make it aligned, you get all kinds of errors.
>>I hope I got this all wrong, otherwise I would be better of using a C 
>>compiler for this (then I've the ability to use macros to get around this)
>
>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.

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;

Marc





More information about the fpc-devel mailing list