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
>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.
>procedure p(var i : integer);
> r : packed record
> c : char;
> i : integer;
> r.i:=1; <--- works
> p(r.i); <--- test.p:15: packed fields may not be used as `var' parameters
>>This will throw away all advantages away form pascal (like strong typing
>>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:
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.
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;
More information about the fpc-devel