
Notes on Type Layouts and ABIs in Rust - telotortium
https://gankro.github.io/blah/rust-layouts-and-abis
======
wnoise
> 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?

~~~
comex
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
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.

~~~
TheCoelacanth
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.

------
btashton
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

~~~
comex
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-i...](https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-
clang-and-llvm/)

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/ef173143abb7413e69...](http://static6.arrow.com/aropdfconversion/ef173143abb7413e6981d32e4d994087aed76942/333em250.pdf)

~~~
btashton
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.

