4 ms·

Notes on Type Layouts and ABIs in Rust

73 points by telotortium 8y ago

btashton 8y ago
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.
wnoise 8y ago
> For Rust to support a platform at all, its standard C dialect must: If Rust is going to have its own defined ABI, why should it require a C implementation at all?
- yorwba 8y ago
  At least part of the reason for having an ABI is that it enables exposing functions written in Rust to code written in other languages. In practice, most languages are unlikely to add support for a Rust-exclusive ABI, so the most convenient choice is to stay compatible with C.
- comex 8y ago
  It doesn't require one. If you compile for a bare metal microcontroller, for example, you're probably running zero C code in your firmware image, so the only "ABI" that matters is how the hardware sets up register state at reset and for interrupts. Usually interrupt handlers are written in assembly anyway, but there's at one platform where someone modified the Rust compiler with a custom calling convention to allow writing interrupt handlers directly in Rust. [1] However, if you do have any assembly code in your project (for interrupt handlers or anything else), and it needs to call Rust or be called by it (likely), then you do want to mark the call (on Rust's end) as using the "C" ABI – simply because it is well-defined, while the Rust ABI is intentionally undefined. For now. Well-defined by what, you ask? Well, by whatever ABI or ABIs LLVM has been taught about for that architecture. The details of each ABI are baked into LLVM's source code, but often there's more than one ABI available for a given architecture, with different origins, and the compiler provides a flag to choose between them. There are also various customization options. Normally, the choice of OS determines the proper values for all those options, but if you're writing your own OS… you can set whatever you want. Of course, you could also define an ABI from scratch, if you feel like hacking up LLVM to support it. [1] https://stackoverflow.com/a/43392404 https://stackoverflow.com/a/43392404
ta43653463546 8y ago
I really wish some more thought had been done on Rust's syntax. It's god-awful. Apostraphes for namespaces is a shocker, the rest don't spring to mind but there were a few more. Syntax/character soup.
- yjftsjthsd-h 8y ago
  Most languages are character soup. It's hardly intuitive that star is a pointer, yet we get used to that.
- steveklabnik 8y ago
  Apostrophes are not used for namespaces. Almost no syntax in rust is unique, even that syntax. It’s used by ocaml for something very similar to rust.
- uryga 8y ago
  afaik apostrophes are used for lifetimes.
- leetcrew 8y ago
  depends on what you're used to. as a C++ dev, i find rust's syntax quite pleasing. it's not too different than what i'm used to, but a lot of the ugliest parts of C syntax have been improved. the only bad example that comes to mind is the lifetime specifier (what i think you are alluding to with the apostrophe).
- TheCoelacanth 8y ago
  The apostrophes are for lifetimes, and they don't even have to be specified most of the time. I just checked for all of the rust code that I have written and explicit lifetimes only occur once per 36 lines and in less than a third of files. Tutorials and blogs will give you a skewed idea about how frequently lifetimes need to be specified because lifetimes get a disproportionate amount of content written about them.

73 points by telotortium 8y ago

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.

wnoise 8y ago

> For Rust to support a platform at all, its standard C dialect must: If Rust is going to have its own defined ABI, why should it require a C implementation at all?

yorwba 8y ago
At least part of the reason for having an ABI is that it enables exposing functions written in Rust to code written in other languages. In practice, most languages are unlikely to add support for a Rust-exclusive ABI, so the most convenient choice is to stay compatible with C.
comex 8y ago
It doesn't require one. If you compile for a bare metal microcontroller, for example, you're probably running zero C code in your firmware image, so the only "ABI" that matters is how the hardware sets up register state at reset and for interrupts. Usually interrupt handlers are written in assembly anyway, but there's at one platform where someone modified the Rust compiler with a custom calling convention to allow writing interrupt handlers directly in Rust. [1] However, if you do have any assembly code in your project (for interrupt handlers or anything else), and it needs to call Rust or be called by it (likely), then you do want to mark the call (on Rust's end) as using the "C" ABI – simply because it is well-defined, while the Rust ABI is intentionally undefined. For now. Well-defined by what, you ask? Well, by whatever ABI or ABIs LLVM has been taught about for that architecture. The details of each ABI are baked into LLVM's source code, but often there's more than one ABI available for a given architecture, with different origins, and the compiler provides a flag to choose between them. There are also various customization options. Normally, the choice of OS determines the proper values for all those options, but if you're writing your own OS… you can set whatever you want. Of course, you could also define an ABI from scratch, if you feel like hacking up LLVM to support it. [1] https://stackoverflow.com/a/43392404 https://stackoverflow.com/a/43392404

ta43653463546 8y ago

I really wish some more thought had been done on Rust's syntax. It's god-awful. Apostraphes for namespaces is a shocker, the rest don't spring to mind but there were a few more. Syntax/character soup.

yjftsjthsd-h 8y ago
Most languages are character soup. It's hardly intuitive that star is a pointer, yet we get used to that.
steveklabnik 8y ago
Apostrophes are not used for namespaces. Almost no syntax in rust is unique, even that syntax. It’s used by ocaml for something very similar to rust.
uryga 8y ago
afaik apostrophes are used for lifetimes.
leetcrew 8y ago
depends on what you're used to. as a C++ dev, i find rust's syntax quite pleasing. it's not too different than what i'm used to, but a lot of the ugliest parts of C syntax have been improved. the only bad example that comes to mind is the lifetime specifier (what i think you are alluding to with the apostrophe).
TheCoelacanth 8y ago
The apostrophes are for lifetimes, and they don't even have to be specified most of the time. I just checked for all of the rust code that I have written and explicit lifetimes only occur once per 36 lines and in less than a third of files. Tutorials and blogs will give you a skewed idea about how frequently lifetimes need to be specified because lifetimes get a disproportionate amount of content written about them.