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
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
