Apologies, my example was not a good representation of the problem, it was a much simplified version of what I am actually doing. As such, it didn’t accurately reflect the problem.
After playing with it more, I think I understand what is going on.
I am porting my byte-code based implementation of Forth to the Redboard. In this system, the value at any address can be interpreted by the system as desired … a byte, a 2-byte (16-bit) number, a 4 byte (32-bit) number, variable-length string, it doesn’t matter. On PC, you can cast any address to a (long *), an it behaves as expected, even when the ‘pointed-to’ address is odd.
On the other Arduino-board (ATMEGA-2560) to which I have ported my Forth, it is also not a problem.
On the Redboard-Turbo, that doesn’t appear to be the case. If you have a (long *), it needs to point to an address that is aligned to a 4-byte boundary, otherwise when you de-reference it, it hangs.
I can work around it by building the 2- and 4- byte values by hand, but that would be a pain, and it would be specific to the RedBoard (and other boards that I come across with the same restriction), so I’d like to not have to do that is I can avoid it.
12:58:02.257 ->
12:58:02.257 -> long: [20007fd4 -> 20007fd7], 4 bytes
12:58:02.257 -> short: [20007fd2 -> 20007fd3], 2 bytes
12:58:02.257 -> int: [20007fd8 -> 20007fdb], 4 bytes
12:58:02.257 -> byte *: [20007fdc -> 20007fdf], 4 bytes
12:58:02.257 -> mem: [20000120 -> 2000711f], 28672 bytes
12:58:02.257 -> here: [20000000 -> 20000003], 4 bytes
12:58:02.257 -> here is 0x20000120, (0x08), now 0x20000121
12:58:02.257 -> here is 0x20000121, (0x09), now 0x20000122
12:58:02.257 -> here is 0x20000122, (0x10), now 0x20000123
12:58:02.257 -> here is 0x20000123, (0x11), now 0x20000124
12:58:02.257 -> here is 0x20000124, (0x04030201), now 0x20000128
12:58:02.257 -> here is 0x20000128, (0x12), now 0x20000129
12:58:02.257 -> here is 0x20000129, (0x13), now 0x2000012a
12:58:02.257 -> here is 0x2000012a, (0x14), now 0x2000012b
12:58:02.257 -> here is 0x2000012b, (0x15), now 0x2000012c
12:58:02.257 -> here is 0x2000012c, (0x16), now 0x2000012d
Many 32-bit processors require memory accesses to be aligned on 4-byte boundaries. The compiler knows how to pack smaller size variables into a 32-bit word and can hide this from you.
There it is … the documentation that explains my findings. thanks. Sigh … such is life … I’ll have to work around it. i’ll use #ifdefs to handle the different cases.