5 ms·

I find it interesting that they have the restriction that 'bytes' be 8 bit. The XAP2 architecture is likely the third most common by volume, and sizeof(int) ==

I find it interesting that they have the restriction that 'bytes' be 8 bit. The XAP2 architecture is likely the third most common by volume, and sizeof(int) == 1. I get that embedded systems are not the main focus of rust, but the embedded world is hardly just ARM. https://en.m.wikipedia.org/wiki/XAP_processor https://en.m.wikipedia.org/wiki/XAP_processor Edit: wrote 16 instead of 8 bits

telotortium 8y ago
From the article, it looks like Rust requires 8-bit bytes (although there is no citation): "Have 8-bit, unaligned bytes (chars)".
- btashton 8y ago
  I wrote 16 when I meant 8bits. For this arch you cannot have 8 but types. Casting a int16_t* to char* won't let you access upper and lower bytes as most people would except (c standard does not define this behavior).
  - yorwba 8y ago
    What happens if you use uint8_t in a C program on XAP? Does the compiler emulate 8-bit values using 16-bit fields or is there simply no support for such a type? FWIW, https://www.cambridgeconsultants.com/xap https://www.cambridgeconsultants.com/xap claims support for 8-bit datatypes, but offers further documentation only by email.
    - comex 8y ago
      Note that "XAP" refers to a whole range of processors with incompatible instruction sets; the latest is XAP6 [1]. [1] https://en.wikipedia.org/wiki/XAP_processor#History https://en.wikipedia.org/wiki/XAP_processor#History
    - btashton 8y ago
      XAP2 you will still be allocating a 16bit value. So you if you create an array of 2 uint8 you will still be allocating 32bits of memory.
jononor 8y ago
Are XAP2 used in application processors much? I thought it was mostly in specialized uses like radiochip controllers etc.
- btashton 8y ago
  I guess it depends on what you mean by application processors. There are a lot of low cost Bluetooth chips out there that run the application logic of the device.
comex 8y ago
Most of the embedded world has 8-bit bytes, not just ARM. Even when it comes to XAP2, there's the newer XAP2b which apparently supports byte addressing [1]. But if you do want larger bytes… well, the first step would be getting LLVM to support them. According to this blog post from last year, it's theoretically possible but would need work: https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/ https://www.embecosm.com/2017/04/18/non-8-bit-char-support-i... And of course, you'd need an LLVM backend for the architecture in question. Only then would the ball be in the court of rustc itself. At that point, I still wouldn't expect non-8-bit byte support be a priority for the core developers, but I expect patches would be welcome. Though if the LLVM backend includes support for emulating u8 and u8 pointers where necessary, relatively little change would be needed from rustc anyway. [1] "The XAP2b adds data-side byte addressing support to the XAP2 by utilizing the 15th bit of the data-side address bus to indicate byte or word accesses." http://static6.arrow.com/aropdfconversion/ef173143abb7413e6981d32e4d994087aed76942/333em250.pdf http://static6.arrow.com/aropdfconversion/ef173143abb7413e69...
- btashton 8y ago
  My comment was more just trying to address this statement. >A lot of the things C was trying to cope with have largely died off or been relegated to incredibly niche platforms. This particular property of C is not uncommon in the embedded space. Especially since the XAP2 is by far the most used in the XAP family and is right behind ARM in volume. That said I don't know how much it is still being used by Qualcomm as I know they are now using more Xtensa cores alongside ARM. Xtensa is another major architecture sitting as small co processors in various silicon designs that is not well known, but is highly flexible. LLVM does not support even the cor versions of it. I know the Espressif team is looking to bring some support for it in.

telotortium 8y ago

From the article, it looks like Rust requires 8-bit bytes (although there is no citation): "Have 8-bit, unaligned bytes (chars)".

btashton 8y ago
I wrote 16 when I meant 8bits. For this arch you cannot have 8 but types. Casting a int16_t* to char* won't let you access upper and lower bytes as most people would except (c standard does not define this behavior).
- yorwba 8y ago
  What happens if you use uint8_t in a C program on XAP? Does the compiler emulate 8-bit values using 16-bit fields or is there simply no support for such a type? FWIW, https://www.cambridgeconsultants.com/xap https://www.cambridgeconsultants.com/xap claims support for 8-bit datatypes, but offers further documentation only by email.
  - comex 8y ago
    Note that "XAP" refers to a whole range of processors with incompatible instruction sets; the latest is XAP6 [1]. [1] https://en.wikipedia.org/wiki/XAP_processor#History https://en.wikipedia.org/wiki/XAP_processor#History
  - btashton 8y ago
    XAP2 you will still be allocating a 16bit value. So you if you create an array of 2 uint8 you will still be allocating 32bits of memory.

jononor 8y ago

Are XAP2 used in application processors much? I thought it was mostly in specialized uses like radiochip controllers etc.

btashton 8y ago
I guess it depends on what you mean by application processors. There are a lot of low cost Bluetooth chips out there that run the application logic of the device.

comex 8y ago

Most of the embedded world has 8-bit bytes, not just ARM. Even when it comes to XAP2, there's the newer XAP2b which apparently supports byte addressing [1]. But if you do want larger bytes… well, the first step would be getting LLVM to support them. According to this blog post from last year, it's theoretically possible but would need work: https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/ https://www.embecosm.com/2017/04/18/non-8-bit-char-support-i... And of course, you'd need an LLVM backend for the architecture in question. Only then would the ball be in the court of rustc itself. At that point, I still wouldn't expect non-8-bit byte support be a priority for the core developers, but I expect patches would be welcome. Though if the LLVM backend includes support for emulating u8 and u8 pointers where necessary, relatively little change would be needed from rustc anyway. [1] "The XAP2b adds data-side byte addressing support to the XAP2 by utilizing the 15th bit of the data-side address bus to indicate byte or word accesses." http://static6.arrow.com/aropdfconversion/ef173143abb7413e6981d32e4d994087aed76942/333em250.pdf http://static6.arrow.com/aropdfconversion/ef173143abb7413e69...

btashton 8y ago
My comment was more just trying to address this statement. >A lot of the things C was trying to cope with have largely died off or been relegated to incredibly niche platforms. This particular property of C is not uncommon in the embedded space. Especially since the XAP2 is by far the most used in the XAP family and is right behind ARM in volume. That said I don't know how much it is still being used by Qualcomm as I know they are now using more Xtensa cores alongside ARM. Xtensa is another major architecture sitting as small co processors in various silicon designs that is not well known, but is highly flexible. LLVM does not support even the cor versions of it. I know the Espressif team is looking to bring some support for it in.