In message <mpro.ko8muv0001wea0063.tim@xxxxxxxxx>, Tim Powys-Lybbe <tim@xxxxxxxxx> writes
OS. Not that I would understand the answer, but are you able to publicise what the problem was? If it was an obscure feature of SparkFS, I suppose we can hope that it is obscure enough that it does not occur on other applications and thus not something to titivate us with.
A word on the ARM chip is 32 bits or 4 bytes. Usually one loads words from a 4th. byte boundary i.e. address 0, 4, 8, etc. The question is what happens if one loads a word from another address like 1,2 or 3. Different ARM chips have different behaviours.
I have never gone in for such things, mostly because I was never really sure what the results would be.
The Zip module in Spark has to contend with loading words from arbitrary byte addresses so when it went wrong it seemed that the above would be the explanation. However the code avoids word access on non-word addresses.
Looking at archives produced on the beagle board it seemed that bytes were being scrambled in an area where compiled code was handling "shorts" i.e. 16 bit words.
A document on the RISC OS Open site shows different compiler flags should be used for different ARM chips, using:
-memaccess -L22-S22-L41 and recompiling the module, produced a version that worked.The bottom line is that if you have a new ARM based computer and RISC OS running on it, then in general you're going to need all your software recompiling to run on it.
-- David Pilling email: david@xxxxxxxxxxxxxxxxxxx web: http://www.davidpilling.net post: David Pilling P.O. Box 22 Thornton Cleveleys Blackpool. FY5 1LR UK fax: +44(0)870-0520-941 To unsubscribe or subscribe goto: //www.freelists.org/list/davidpilling
