On Sun, 1 Aug 2010, Chris Young wrote: > On Sat, 31 Jul 2010 23:38:49 +0100 (GMT Daylight Time), Jeffrey Lee wrote: >> I didn't make any effort to ensure >> the new memory code ran on big-endian machines, so it wouldn't surprise me >> if it's failing. Take a look at the LoadByte, StoreByte and SwapByte >> functions in fastmap.c, and for anything in arch/armarc.c that handles the >> FASTMAP_ACCESSFUNC_BYTE flag. With any luck that should be all that needs >> changing. > > fastmap.c isn't even compiled, there's no reference to it in the > makefile?
It's either included by arch/armarc.h (if the code is being inlined) or arch/armarc.c (if inlining is disabled for easier debugging). In fact, it should probably be moved to the arch folder :) > The access functions in armarc.c look like they might be the culprit, > but I don't fully understand what it is supposed to be doing: > > data = (data>>((addr&3)<<3))&0xff; > > Where are the functions to write these bytes? I think I need to see > those to decypher how to reverse it for BE in the above (simply > changing 0xff to 0x000000ff didn't work sadly) 'addr' is an unaligned address, so (addr&3) would give the byte offset within the word of data (under the assumption that 'data' will have been loaded from a word-aligned address). So shift (addr&3) left 3 times to get the number of bits into the word at which the byte starts, then shift data right by that amount to get the byte we're interested in into the lower 8 bits. Looking at the old code, this seems to be practically identical to what ARMul_LoadByte does (complete with a "WARNING! Little endian only" warning). So assuming that code did indeed work on BE platforms, I don't think it needs modification. The bit that most likely will need modification, however, are the bits in FastMap.c which directly access memory as a char *. For those to work on BE platforms you'd either need to resort to loading words and shifting or invert the lower two bits of the address (so 00 -> 00, 01 -> 11, 10 -> 10, 11 -> 01... say addr ^= (addr&1)<<1, or a more efficient method if possible) Also while looking at this I've spotted a bug in my ARMul_SwapByte implementation (when accessing memory directly it returns *phy when it should reutrn temp). And code which accesses memory as a char * should probably be changed to unsigned char * for portability. Since my code was a bit more broken then I was expecting, I think I'll spend today tidying it up a bit, test it on Windows/Linux, and upload a new archive with any fixes Chris produces. Cheers, - Jeffrey ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
