Hi,

Florian and I had a discussion on IRC and we decided to continue it here.

F:> I guess the main problem will be that the typeinfo structures has changed to fit sparc 's alignment
M:> this will be on sparc only ?
F:> on cpus which define FPC_REQUIRES_PROPER_ALIGNMENT
F:> mainly, the data after strings in type info must be aligned
F:> the key is function aligntoptr(p : pointer) : pointer;
F:> in typeinfo, it is used to do the alignment
M:> trying examples/hello
M:> Program received signal SIGBUS, Bus error.
F:> yes, SIGBUS is an alignment exception
F:> the compiler contains also several packed ifdef'ed by FPC_REQUIRES_PROPER_ALIGNMENT


M:> about alignment:
M:> I don't know if the average Lazarus user will be happy with taking care of alignment
M:> IMO, for compiler internals yes, but as an enduser I think it is a task of the compiler
M:> I know that unalignged memory access in this case has a large performance penalty, but IMO is should be allowed


F:> there are two options: (to allow unaligned accesses)
F:> - catch the sigbus and "fix" the access; requires a lot of work to implement
F:> - always assume unaligned accesses: hugh speed penalty: load byte by byte and shift/or the result
F:> so I think we should follow the C way of doing it: the user has to take care of alignment
F:> if a data access is unaligned: do a move(unaligneddata,aligneddataloc,sizeof(unaligneddata));


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)
M:> I know that some arm implementations can read this way (unfortunately not the one we're using at work). I thought it was more a OS thingy
M:> @2) You don't have to read byte by byte in all cases. You can check first if it is unalligned, after that you can read regsize instead of bytesize
M:> Let the user take care of alignment makes me a bit itchy. I don't get a good feeling with it.
M:> But how are members of packed records accessed ?



Marc


_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to