Florian Klaempfl wrote

> 2.It also make compiler code generation easier

because

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

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

Hello,

What exactly are those exceptions of Misalligned data access on windows CE?

And why that doesn´t exist on x86 architecture?

thanks,

Hello, What exactly are those exceptions of Misalligned data

access on windows CE?

And why that doesn´t exist on x86 architecture? thanks,

Those are something like access violation exceptions in x86,when for example you try to read/write to nil pointer region.
With ms embeded visual c-only v4.0-we can handle those with try/catch(i think we cant in fpc),and accur when you access unaligned memory addresses.
I dont know why we dont have them on x86,but i know for x86 it is also difiicult to handle,and internally it handles them aligned and do conversions.
maybe becouse in arm implementing and accessing them makes it slow.
I also read an article which said on ia64 it is also problem,and windows generate error for accessing
unaligned data as it is very slow.

regards

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

It depends all on how a CPU accesses memory.

Suppose a CPU has a 8bit data bus to memory and you want to read a byte. Since you have a 8bit bus, you are able to adress all individual bytes, so reading is not a problem.
Now imagine a CPU with a 32bit databus and reading a byte. Data is read in chuncks of 32bits (=4 bytes) and it is adressed by multiples of 4. For getting the exact byte, the CPU "shifts" the right byte.

Now we do the same for reading a 32bits integer. On a 8 bit cpu, you have to read 4 times one byte and then you have the integer. On a 32bits CPU it can be read in one go if the adress is aligned to 4 bytes. If not, it has to be read in 2 halves and then combined to one integer. The x86 supports reading like this, alltough it is inefficient. The SPARC and some implementations of the ARM (*) don't support this and raise a buserror if you read data like this.

(*) there are extentions to the ARM core which can handle it, but this depends on what functionality the manufacturer of a specific core has implemented.

Hope this made some thing clear.

Marc