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