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

[JF Bastien via llvm-dev]

> On Oct 29, 2019, at 6:18 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
> 
> 
> 
> 
>> On Tue, Oct 29, 2019 at 5:14 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> 
>> > On Oct 29, 2019, at 3:39 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> > 
>> > On Tue, Oct 29, 2019 at 07:19:25PM +0000, Tim Northover via llvm-dev wrote:
>> >> On Tue, 29 Oct 2019 at 19:11, Dmitriy Borisenkov via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >>> 2. Test with a dummy target. It might work if we have a group of contributors who is willing to rewrite and upstream some of their downstream tests as well as to design and implement the target itself. The issue here might be in functional tests, so we'd probably need to implement a dummy virtual machine to run them because lit tests are unlikely to catch all issues from paragraphs (2) and (3) of the scope described.
>> >>> 3. TON labs can provide its crazy target or some lightweight version of it. From the testing point of view, it works similar to the second solution, but it doesn't require any inventions. I could create a separate RFC about the target to find out if the community thinks it's appropriate.
>> >> 
>> >> I'm not great at history, are there any historically iconic targets
>> >> that aren't 8-bit but are otherwise sane? I'd prefer to spend the
>> >> project's resources supporting something like that than either an
>> >> invented target or a speculative crypto-currency oddity.
>> > 
>> > PDP10 is iconic enough?
>> 
>> Is it relevant to any modern compiler though?
>> 
>> I strongly agree with Tim. As I said in previous threads, unless people will have actual testable targets for this type of thing, I think we shouldn’t add maintenance burden.
> 
> +1: we should have a testable target in the first place to motivate the maintenance/support in LLVM. Someone should write a HW simulator for such an "academic" architecture and a LLVM backend for it! :)
>  
>> This isn’t really C or C++ anymore because so much code assumes CHAR_BIT == 8, or at a minimum CHAR_BIT % 8 == 0, that we’re supporting a different language. IMO they should use a different language, and C / C++ should only allow CHAR_BIT % 8 == 0 (and only for small values of CHAR_BIT).
> 
> I'm missing the link between the LLVM support for non 8-bits platforms and  "they should use a different language" than C/C++, can you clarify?

C code with 257 bits per byte is nominally C, but it’s realistically incompatible with any existing C code. It’s therefore not the C people use, it’s the C the standard says should exist because historically it might have been a good idea. 

Similarly, C with signed magnitude or ones’ complement integers isn’t the same C we all use. 


> Best,
> 
> -- 
> Mehdi
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/80fa92c3/attachment.html>