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

[Roozbeh GHolizadeh]

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