[fpc-devel] closing of bug 5042 or general unalignment problems with arm compiler

[Florian Klaempfl]

Roozbeh GHolizadeh wrote:
> Hi.
> 
> 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
> procedure.

Same with unaligned: you need to find the places it crashes and add a unaligned
directive.

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

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
trouble.

> 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
> program.

Yes :) Don't forget that support of unaligned would also create very lengthy and
slow code.

> 
> 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
move(a,b,sizeof(4));

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

> 
> regards
> roozbeh
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>