Hi David, I am developing the "faster-rstruct" branch, which aims to speedup struct.unpack by reading the values at once from memory, instead of byte-by-byte as it's doing right now. The branch works fine on x86 but fails on armhf (see e.g. http://buildbot.pypy.org/summary/longrepr?testname=AppTestStruct.%28%29.test_unpack_standard_little&builder=pypy-c-jit-linux-armhf-v7&build=843&mod=module.struct.test.test_struct). I suspect a big/little endian issue. Two questions: 1) I know that ARM CPUs can be either little or big endiam. What is the case for our armhf machine? 2) is it possible to have ssh access to one or more of our ARM machines so I can test easily? thank you :) ciao, Anto
Hi Anto, On Sun, Nov 22, 2015 at 12:10 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
I suspect a big/little endian issue.
Fwiw, the error doesn't seem to be an endianness issue, but rather reading garbage (and I'm pretty sure that all our ARMs are little endian). A bientôt, Armin.
Hi again, Here's a guess. The value expected is 0x4142434445464748. The value we read is 0xb3f4bce041424344. That hints at an off-by-4-bytes issue. My guess is an alignment issue. When you force-cast the RPython string to a type with an 8-bytes-per-item array, on some 32-bit platforms it might be aligned to 8 bytes anyway. It is not the case on Linux x86-32, but it is the case on Win32 for example. So you force-cast to a type that looks like this: gc header (4 bytes) hash (4 bytes) length (4 bytes) PADDING! (4 bytes) array items (8 bytes each) Maybe you should not force-cast to any type whose size is greater than a Signed, to avoid the issue. A bientôt, Armin.
Hi Anto,
On 22.11.2015, at 12:10, Antonio Cuni <anto.cuni@gmail.com> wrote:
1) I know that ARM CPUs can be either little or big endiam. What is the case for our armhf machine?
Our builders are all little endian. To my knowledge most (maybe all) Linux distributions for ARM are little endian nowadays.
2) is it possible to have ssh access to one or more of our ARM machines so I can test easily?
at least for the raspberry pi builders it is not that easy to provide external access. Maybe on the “cubieboard-bob” builder, which is managed by Matti, it is possible. Cheers David
Hi Anto, On Sun, Nov 22, 2015 at 12:10 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
I suspect a big/little endian issue.
Fwiw, the error doesn't seem to be an endianness issue, but rather reading garbage (and I'm pretty sure that all our ARMs are little endian). A bientôt, Armin.
Hi again, Here's a guess. The value expected is 0x4142434445464748. The value we read is 0xb3f4bce041424344. That hints at an off-by-4-bytes issue. My guess is an alignment issue. When you force-cast the RPython string to a type with an 8-bytes-per-item array, on some 32-bit platforms it might be aligned to 8 bytes anyway. It is not the case on Linux x86-32, but it is the case on Win32 for example. So you force-cast to a type that looks like this: gc header (4 bytes) hash (4 bytes) length (4 bytes) PADDING! (4 bytes) array items (8 bytes each) Maybe you should not force-cast to any type whose size is greater than a Signed, to avoid the issue. A bientôt, Armin.
Hi Anto,
On 22.11.2015, at 12:10, Antonio Cuni <anto.cuni@gmail.com> wrote:
1) I know that ARM CPUs can be either little or big endiam. What is the case for our armhf machine?
Our builders are all little endian. To my knowledge most (maybe all) Linux distributions for ARM are little endian nowadays.
2) is it possible to have ssh access to one or more of our ARM machines so I can test easily?
at least for the raspberry pi builders it is not that easy to provide external access. Maybe on the “cubieboard-bob” builder, which is managed by Matti, it is possible. Cheers David
participants (3)
-
Antonio Cuni -
Armin Rigo -
David Schneider