llvm dev - Oct 2019 - RFC: On non 8-bit bytes and the target for it

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?

Joerg

> 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. 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).

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?

Best,

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

On 10/29/19 5:13 PM, JF Bastien via llvm-dev 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.
Strongly agreed here as well.

Philip
>   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).

> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF
Bastien via
[..]
> 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. 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).
We (Synopsys ASIP Designer team) and our customers tend to disagree: our
customers do create plenty of cpu architectures
with non-8-bit characters (and non-8-bit addressable memories). We are able to
provide them with a working c/c++ compiler solution.
Maybe some support libraries are not supported out of the box, but for these
kind of architectures that is acceptable.
(Besides that, llvm is also more than just c/c++)

Greetings,

Jeroen Dobbelaere