[fpc-devel] closing of bug 5042 or general unalignment problems with arm compiler
florian at freepascal.org
Mon Apr 24 14:16:30 CEST 2006
Roozbeh GHolizadeh wrote:
> I've already sent peter an email,but didnt know
> mailing list was also availble.I think here is a
> better place to discuss.
> My wishlist on bug 5042 was adding of something like
> __unaligned keyword to fpc.
> As you know unalignment access in arm cpus cause
> exception and make program terminate.
> Having unaligned keyword or directive is a must for
> arm compiler.I have several reasons:
> 1.gcc,ms visual c,and almost all c compiler have
> this,so there might be a reason those developers
> bothered themself implementing that.
> 2.It also make compiler code generation easier because
> now it know where to generate unalignement
> code,instead of currently geussing and somethimes
> generate wrong code(bug 5028)
This is a wrong program not wrong code generation :)
> and if not unaligned
> keyword specified,means do as normal.(it is the same
> case in c compilers).
> 3.With this also no more automatic unaligned/aligned
> code generation for packed records,which is also buggy
> now(havent had time to report this,but accessing
> packed record also sometimes generate errors).
Of course, packed is packed and nothing else and you're on your own.
> Compiler have to generate unaligned code for packed
> record if only it is declared as unaligned.
> Peter suggested that you can use move in these cases.
> About peter solution,i think following problems exist:
> 1.Just imagine how to port you current working win32
> program-which is almost the case for majarity of wince
> developers-to wince.
> start your program,try to see if any errors
> happen,then convert each assignment by adding move
Same with unaligned: you need to find the places it crashes and add a unaligned
> How about the assignment where sizes mismatch?
> well now you have to add another temporary variable,do
> move on it,assign it to that another one.
> How about members of a record (pointer packed
> record,which now compiler doesnt know anything about
Don't forget that supporting unaligned would only solve part of the problem.
Passing such a variable by reference or getting a pointer on it still calls for
> Well use move for each member of record,or see if it
> is unaligned and do that!
> This one simply means,forget about it,and rewrite your
Yes :) Don't forget that support of unaligned would also create very lengthy and
> 2.Move currently is a procedure which in turn calls
> memset from winapi.Well imagine how slow it is.
> In a 10000 times loop which you only want to assign a
> word(type) to another word;now you have to call memset
> 10000 times!
Unaligned accesses are slow.
> but with making that feature compiler only add one
> more opcode.
Which one? Unaligned accesses on arm generate lengthy code, it requires loading
byte by byte and bit shifting and masking. So
a = __unaligned(b);
isn't probably much faster than
> 3.Using move can be really hard,in nested structures
> and classes.
> I think this wishlist/bug report should opened again.
Of course, it can be reopened but this doesn't mean that it would be fixed
quickly ;) We got lazarus working with a few fixes on sparc which also bus
faults on unaligned accesses so imo the problem is minor.
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel