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

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!
but with making that feature compiler only add one more opcode.

3.Using move can be really hard,in nested structures and classes.

I think this wishlist/bug report should opened again.

regards
roozbeh

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

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

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!
but with making that feature compiler only add one more opcode.

3.Using move can be really hard,in nested structures and classes.

I think this wishlist/bug report should opened again.

regards
roozbeh

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

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

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!
but with making that feature compiler only add one more opcode.

3.Using move can be really hard,in nested structures and classes.

I think this wishlist/bug report should opened again.

regards
roozbeh

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

This is a wrong program not wrong code generation :)

Of course, packed is packed and nothing else and you're on your own.

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

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.

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));

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.