On 2022-02-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <suot6g$uus$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>>On 2/18/2022 10:12 AM, Dan Cross wrote:
>>> In article <620e5870$0$701$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> And since it will be LLVM based then it must be x86-64 only.
>>>
>>> Why do you say that?
>>
>>VAX, Alpha, and itanic are not VSI's future.
>
> Undoubtedly, but I wasn't suggesting that it was.
> My comment was motivated by an apparent statement
> that LLVM == x86. It does not.
>

There is one way in which LLVM is effectively x86 however and
that is the sheer horsepower and RAM needed to build the damn
thing from source. :-(

I'm also less than impressed in how they keep updating the toolchain
source code with the very latest C++ standards so you need the latest
C++ compilers to build it. (In fairness, that knowledge is from several
versions back, so I don't know if they have matured somewhat recently
and stopped chasing the "nice new shiny" at every opportunity.)

This is exactly the kind of thing that should be easy to build reasonably
quickly with any reasonable C++ compiler. :-(

I wish there were a more lightweight compiler toolchain that targeted
the same range of backends that LLVM does and for which it was also
easy to plug in your own frontend...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <sv0onu$66b$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-02-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Undoubtedly, but I wasn't suggesting that it was.
>> My comment was motivated by an apparent statement
>> that LLVM == x86. It does not.
>>
>
>There is one way in which LLVM is effectively x86 however and
>that is the sheer horsepower and RAM needed to build the damn
>thing from source. :-(

It is definitely large. That said, I've built it on ARM
and RISC-V (actual silicon, yes), and it's not _that_ bad.

>I'm also less than impressed in how they keep updating the toolchain
>source code with the very latest C++ standards so you need the latest
>C++ compilers to build it. (In fairness, that knowledge is from several
>versions back, so I don't know if they have matured somewhat recently
>and stopped chasing the "nice new shiny" at every opportunity.)
>
>This is exactly the kind of thing that should be easy to build reasonably
>quickly with any reasonable C++ compiler. :-(
>
>I wish there were a more lightweight compiler toolchain that targeted
>the same range of backends that LLVM does and for which it was also
>easy to plug in your own frontend...

You mean like GEM? :-D

- Dan C.

On 2022-02-21, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <sv0onu$66b$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>I wish there were a more lightweight compiler toolchain that targeted
>>the same range of backends that LLVM does and for which it was also
>>easy to plug in your own frontend...
>
> You mean like GEM? :-D
>

GEM is not freely available so it can't be downloaded and built on Linux.

No backends for x86, x86-64, ARM, or MIPS.

No documentation on how to add your own frontend to GEM.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <sv3a3g$9rl$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-02-21, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <sv0onu$66b$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>>I wish there were a more lightweight compiler toolchain that targeted
>>>the same range of backends that LLVM does and for which it was also
>>>easy to plug in your own frontend...
>>
>> You mean like GEM? :-D
>
>GEM is not freely available so it can't be downloaded and built on Linux.

You didn't specify that as a requirement.

>No backends for x86, x86-64, ARM, or MIPS.

I'll bet cookies to cake it's got at least a MIPS backend.

>No documentation on how to add your own frontend to GEM.

*shrug* I wasn't being literal, but here we are.

- Dan C.

On 2022-02-21 19:21:35 +0000, Simon Clubley said:

> There is one way in which LLVM is effectively x86 however and that is
> the sheer horsepower and RAM needed to build the damn thing from
> source. :-(

Your hardware shopping list: https://openbenchmarking.org/test/pts/build-llvm

I would hope that developers finding themselves rebuilding most or all
of llvm will have mid- or upper-range boxes, or are hosting the builds:
https://blog.nelhage.com/post/building-llvm-in-90s/

VSI wants seriously fast build servers for building OpenVMS itself, too.

> I'm also less than impressed in how they keep updating the toolchain
> source code with the very latest C++ standards so you need the latest
> C++ compilers to build it. (In fairness, that knowledge is from several
> versions back, so I don't know if they have matured somewhat recently
> and stopped chasing the "nice new shiny" at every opportunity.)

This is not unusual for any self-hosting compiler, clang or otherwise,
and particularly for any self-hosting compilers with an evolving
language specification.

> This is exactly the kind of thing that should be easy to build
> reasonably quickly with any reasonable C++ compiler. :-(

Could you point to what you might consider "any reasonable C++
compiler"? 🤪 The C++ language is quite powerful, and the resulting
compilers tend complex. And many developers will want or need different
C++ subsets.

C compilers tend smaller than C++, and C11 and other subset compilers
are available: https://github.com/rui314/chibicc

> I wish there were a more lightweight compiler toolchain that targeted
> the same range of backends that LLVM does and for which it was also
> easy to plug in your own frontend...

In years past, there have been similar discussions around writing a
custom networking stack, and writing a custom database, and which
usually also means maintaining and updating the resulting tools and
toolchains, and which too often grows to the size of whatever was being
replaced.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2/22/2022 5:59 PM, Stephen Hoffman wrote:
> On 2022-02-21 19:21:35 +0000, Simon Clubley said:
>> I'm also less than impressed in how they keep updating the toolchain
>> source code with the very latest C++ standards so you need the latest
>> C++ compilers to build it. (In fairness, that knowledge is from
>> several versions back, so I don't know if they have matured somewhat
>> recently and stopped chasing the "nice new shiny" at every opportunity.)
>
> This is not unusual for any self-hosting compiler, clang or otherwise,
> and particularly for any self-hosting compilers with an evolving
> language specification.
>
>> This is exactly the kind of thing that should be easy to build
>> reasonably quickly with any reasonable C++ compiler. :-(
>
> Could you point to what you might consider "any reasonable C++
> compiler"? 🤪  The C++ language is quite powerful, and the resulting
> compilers tend complex. And many developers will want or need different
> C++ subsets.

I don't think the request was to be able to build with a
compiler supporting a subset of C++ XX - I think the request
was for being able to build with a compiler fully
supporting C++ XX but where XX is not latest and greatest.

That makes bootstrapping a bit tricky.

Arne

On 2022-02-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <sv3a3g$9rl$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>No documentation on how to add your own frontend to GEM.
>
> *shrug* I wasn't being literal, but here we are.
>

I know. Next time, I will add one of these: :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I don't think the request was to be able to build with a
> compiler supporting a subset of C++ XX - I think the request
> was for being able to build with a compiler fully
> supporting C++ XX but where XX is not latest and greatest.
>

Yes, that's exactly what I mean.

> That makes bootstrapping a bit tricky.
>

Why ? It's just another set of source files to be compiled as far
as the existing compiler is concerned. What the source code implements
does not need to match the language or language variant it is written in.

Until gcc 4.8, you could build gcc using just a C compiler, unless
you wanted Ada included, in which case you had to use an existing
gcc that also had Ada support built in (because the Ada frontend was
written in Ada).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/23/2022 2:06 PM, Simon Clubley wrote:
> On 2022-02-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I don't think the request was to be able to build with a
>> compiler supporting a subset of C++ XX - I think the request
>> was for being able to build with a compiler fully
>> supporting C++ XX but where XX is not latest and greatest.
>>
>
> Yes, that's exactly what I mean.
>
>> That makes bootstrapping a bit tricky.
>>
>
> Why ? It's just another set of source files to be compiled as far
> as the existing compiler is concerned. What the source code implements
> does not need to match the language or language variant it is written in.

Thumbs on keyboard - the other way around.

Requiring latest C++ version makes bootstrapping difficult,
because existing compilers may be older C++ version.

> Until gcc 4.8, you could build gcc using just a C compiler,

That is even nicer than working with any C++ version.

But I can understand the desire to go from C to C++. Some code
can become a lot cleaner.

But I am not so sure that requiring latest C++ really gain so
much.

> unless
> you wanted Ada included, in which case you had to use an existing
> gcc that also had Ada support built in (because the Ada frontend was
> written in Ada).

Give how rare Ada compilers are and that C/C++ has pretty good compiler
support (lex/yacc, flex/bison etc.) then that choices does not make
sense to me.

Arne

On 2022-02-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/23/2022 2:06 PM, Simon Clubley wrote:
>> unless
>> you wanted Ada included, in which case you had to use an existing
>> gcc that also had Ada support built in (because the Ada frontend was
>> written in Ada).
>
> Give how rare Ada compilers are and that C/C++ has pretty good compiler
> support (lex/yacc, flex/bison etc.) then that choices does not make
> sense to me.
>

It was driven by the usual ego trip about implementing the compiler
you are writing in the language it is implementing. :-(

If you want to do that, then for goodness sake, implement enough
of it in a popular language to get your core compiler itself running
and then use this newly built compiler to compile the rest of your
source code (the extended RTL, utilities, etc) which you can now
write in your nice new language. :-(

Ada: great language, _really_ horrible compiler situation.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.