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

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 29 18:18:21 PDT 2019

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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/6000b321/attachment-0001.html>

More information about the llvm-dev mailing list