[llvm-dev] RFC: On non 8-bit bytes and the target for it

[Chris Lattner via llvm-dev]

> On Oct 24, 2019, at 4:02 PM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 24/10/2019 14:21, JF Bastien via llvm-dev wrote:
>> I’d like to understand what programming model you see programmers using. You don’t need 257 bits per byte if you only offer 257 bit integers. Rather, bytes aren’t really a thing at that point. LLVM kinda handles iN already, and your backend would legalize everything to exactly this type and nothing else, right? Would it be sufficient to expose something like int<unsigned Size> with Size=257 for your programming environment?
> 
> To add to what JF says:
> 
> Typically, a byte means some combination of:
> 
> 1. The smallest unit that can be indexed in memory (irrelevant for you, you have no memory).
> 2. The smallest unit that can be stored in a register in such a way that its representation is opaque to software (i.e. you can't tell the bit order of a byte in a multi-byte word).  For you, it's not clear if this is 257 bits or something smaller.
> 3. The smallest unit that is used to build complex types in software. Since you have no memory, it's not clear that you can build structs or arrays, and therefore this doesn't seem to apply.
> 
> From your description of your VM, it doesn't sound as if you can translate from any language with a vaguely C-like abstract machine, so I'm not certain why the size of a byte actually matters to you.  LLVM IR has a quite C-like abstract machine, and several of these features seem like they will be problematic for you.  There is quite a limited subset of LLVM IR that can be expressed for your VM and it would be helpful if you could enumerate what you expect to be able to support (and why going via LLVM is useful, given that you are unlikely to be able to take advantage of any existing front ends, many optimisations, or most of the target-agnostic code generator.

Right.  A 257-bit target is a bit crazy, but there are lots of other targets that only have 16-bit or 32-bit addressable memory.   I’ve heard various people saying that they all have out-of-tree patches to support non-8-bit-byte targets, but because there is no in-tree target that uses them, it is very difficult to merge these patches up stream.

I for one would love to see some of these patches get upstreamed.  If the only problem is one of testing, then maybe we could make a virtual target exist, or maybe we could accept the patches without test cases (so long as they doesn’t break 8-bit-byte targets obviously).

-Chris