Florian Klaempfl wrote: >> 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 :) Didnt get this?you mean my sample was wrong? >> >> 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. Yes maybe finding of bugs is same,but solution this way is far easier. >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 in all cases programmer have to use unalignment directive,it is not compilers job.This is the same case in other c compilers. for example declaring a pointer as unaligned is meaningless,but you can do your operations always as unaligned. >> 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. Maybe a little bit lenghty and slow,but not very! Misalignment only accours in very small parts of code,and you can use unalignment directive for those cases. Whats the diffrence betwen assigning a word to another word in size,with alignment and without alignment? just another mov opcode or maybe another ldrb opcode!it means 2bytes. About time i dont think comparing two more opcodes with calling of another procedure which itself calls an external imported function from windows,which by itself does alots of argument checking and so,is rational. If two more opcodes is very slow,the move approach might take years to end. >> 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. Yes,but you can never compare this slowness with that one! >> 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)); I can make a benchmark,i bet it is atleast 10 times faster. And speed is not everything.I cant imagine using of move for every condition. >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. Being fixed,or being in future roadmap list is enough,i never expected to be fixed soon. And thanks, 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
