Embecosm, a compiler and embedded software consultancy, writes about GCC, LLVM, Rust, RISC-V, and unusual processor targets.
Commenters cite it for compiler work like non-8-bit char support and RISC-V vector extension support in GCC and LLVM, and a Cray-1 wiring photo.
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/
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
Some links on the most promising effort so far, gccrs
https://opensrcsec.com/open_source_security_announces_rust_gcc_funding
https://www.embecosm.com/2021/01/12/gcc-rust-how-it-can-be-achieved/
https://rust-gcc.github.io/
This is an entirely new frontend written in C++, that shares no code with rustc (the official rust compiler). It might be merged some day in GCC proper.
But honestly, I'm more excited for rustc_codegen_gcc:
https://github.com/antoyo/rustc_codegen_gcc
It adds gcc as an alternative backend of the official Rust compiler. That way it is much more feasible to stay up to date as the language evolves.
Anyway the former two don't actually work right now. The one that does work today is mrustc, or at least it works for bootstrapping rustc; it doesn't have a borrow checker though (and instead assumes the program is correct). Also, mrustc isn't based on gcc.
https://github.com/thepowersgang/mrustc
(There's a fourth project, https://github.com/sapir/gcc-rust, but it seems abandoned)
Ugh, all external links in this article go through the Google click tracker. :-/
Here are ungoogled URLs:
https://elixir.bootlin.com/linux/v4.17/source/include/linux/jhash.h#L70
https://elixir.bootlin.com/linux/v4.17/source/include/net/dst.h#L442
https://elixir.bootlin.com/linux/v4.17/source/include/linux/thread_info.h#L121
https://c9x.me/x86/html/file_module_x86_id_318.html
https://elixir.bootlin.com/linux/v4.17/source/arch/x86/include/asm/bug.h#L33
https://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Extended-Asm.html
https://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html#idp109760
https://patchwork.kernel.org/patch/10450037/
https://lkml.org/lkml/2018/10/4/25
https://elixir.bootlin.com/linux/v4.17/source/include/linux/slab.h#L699
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
https://elixir.bootlin.com/linux/v4.17/source/arch/x86/kvm/vmx.c#L9669
https://elixir.bootlin.com/linux/v4.17/source/arch/x86/kvm/vmx.c#L706
To be fair, the octet as the byte has been dominant for decades. POSIX even has the definition “A byte is composed of a contiguous sequence of 8 bits.” I would wager many software engineers don't even know that a non-octet bytes were a thing, given that college CS curricula typically just teach a byte is 8 bits.
I found some search results about Texas Instruments' digital signal processors using 16-bit bytes, and came across this blogpost from 2017 talking about implementing 16-bit bytes in LLVM: https://embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/. Not sure if they actually implemented it, but that was surprising to me that non octet bytes still exist, albeit in a very limited manner.
Do you know of any other uses for bytes that are not 8 bits?
Agreed on the sentiment.
There is zero chance of getting it into the base, C or even M sets, as they have existing implementations. But maybe a lone Z (without the usual lowercase letters) could mean just this instruction.
I found this to be a helpful discussion: https://www.embecosm.com/2019/10/22/gcc-risc-v-bit-manipulation-extension/
Who do you think does most of the work in LLVM for example?
It is full of PhD paper contributions.
For example, research students doing internships at Embecosm (https://embecosm.com), as many others, plenty of material from LLVM Developers Meeting sessions.