Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3767 > unrolled thread

EDG open source C++ front end

Back to article view | Back to comp.compilers

Contents

  EDG open source C++ front end Derek M Jones <derek@knosof.co.uk> - 2026-10-02 23:05 +0100
    Re: EDG open source C++ front end anton@mips.complang.tuwien.ac.at - 2026-10-03 16:01 +0000
      Re: EDG open source C++ front end Derek M Jones <derek@knosof.co.uk> - 2026-10-04 13:40 +0100
        Re: EDG open source C++ front end anton@mips.complang.tuwien.ac.at - 2026-10-05 17:33 +0000
          Re: EDG open source C++ front end Derek M Jones <derek@knosof.co.uk> - 2026-10-06 22:00 +0100
            Re: EDG open source C++ front end anton@mips.complang.tuwien.ac.at - 2026-10-07 07:10 +0000
    Re: EDG open source C++ front end Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-10-05 16:55 +0000

#3767 — EDG open source C++ front end

All,

EDG have open sourced their C++ front end
https://edgcpp.org/

Is there a commercial market for compilers anymore?

The LLM generated compilers are creatures of their
training data
https://shape-of-code.com/2026/02/22/investigating-an-llm-generated-c-compiler/

Is there a future for programming languages.
Coding agents could cut out the middle man and go
direct to assembler.

--
Derek M. Jones           Evidence-based software engineering
blog:https://shape-of-code.com

[toc] | [next] | [standalone]

#3768

Derek M Jones <derek@knosof.co.uk> writes:
>All,
>
>EDG have open sourced their C++ front end
>https://edgcpp.org/
>
>Is there a commercial market for compilers anymore?

There seems to be lots of money in gcc and LLVM development, and this
money comes from commercial interests, so they are commercial
compilers.  It's just not the classic proprietary-software business
model.

>Is there a future for programming languages.
>Coding agents could cut out the middle man and go
>direct to assembler.

For now, they don't, for whatever reason.  And the code they generate
is stored in version control systems, not the prompts.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

[toc] | [prev] | [next] | [standalone]

#3769

Anton,

>> Is there a commercial market for compilers anymore?
>
> There seems to be lots of money in gcc and LLVM development, and this
> money comes from commercial interests, so they are commercial

The gcc people and llvm people I spoke to about funding, some
years ago, said that funding was hard to come by.

Nowadays, there are lots of companies building new 'AI' chips,
so demand has picked up.  Or rather, job opportunities.

>> Is there a future for programming languages.
>> Coding agents could cut out the middle man and go
>> direct to assembler.
>
> For now, they don't, for whatever reason.  And the code they generate
> is stored in version control systems, not the prompts.

It does not matter where the code is stored.

To generate training data the model builders could use
existing compilers to generate assembler, then feed this
into model training.

--
Derek M. Jones           Evidence-based software engineering
blog:https://shape-of-code.com

[toc] | [prev] | [next] | [standalone]

#3771

Derek M Jones <derek@knosof.co.uk> writes:
>> There seems to be lots of money in gcc and LLVM development, and this
>> money comes from commercial interests, so they are commercial
>
>The gcc people and llvm people I spoke to about funding, some
>years ago, said that funding was hard to come by.

Maybe.  But it did come.  They don't work on these compilers for free.

>Nowadays, there are lots of companies building new 'AI' chips,
>so demand has picked up.  Or rather, job opportunities.

If that has increased for them, that's an answer to:

>>> Is there a future for programming languages.
>>> Coding agents could cut out the middle man and go
>>> direct to assembler.
>>
>> For now, they don't, for whatever reason.  And the code they generate
>> is stored in version control systems, not the prompts.
>
>It does not matter where the code is stored.

My sentence was phrased in a misleading way.  What I meant is: Not the
prompts (or not only), but primarily the generated code is stored in
the version control systems.  I.e., the companies that use AI in
programming see a value in the code in a language that's higher-level
than assembly language or machine code.

>To generate training data the model builders could use
>existing compilers to generate assembler, then feed this
>into model training.

What would the advantage be?  Can the LLM generate the assembly
language more cheaply than what we get with the workflow that AI
generates "high-level code and the compiler generates assembly/machine
code"?  What about human review that still happens AFAIK?  What about
programs that need to run on several architectures?

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
[I think that last point is important -- writing code that compiles
cleanly to several modern architectures like amd64 and arm is easy,
asking an LLM to do it, who knows? -John]

[toc] | [prev] | [next] | [standalone]

#3772

Anton,

> My sentence was phrased in a misleading way.  What I meant is: Not the
> prompts (or not only), but primarily the generated code is stored in
 > the version control systems.

Imagine if, when high level languages were new, that companies
stored the compiler generated assembler in the version control system,
rather than the source code.

It is the specification used to generate the source that needs to
be stored.

The source is currently stored because coding agents are unreliable,
and following existing practice is the lowest friction route.

>                              I.e., the companies that use AI in
> programming see a value in the code in a language that's higher-level
> than assembly language or machine code.

If coding agents become reliable, the generated source becomes
as interesting as the assembler generated by compilers.

> What would the advantage be?  Can the LLM generate the assembly
> language more cheaply than what we get with the workflow that AI
> generates "high-level code and the compiler generates assembly/machine
 > code"?

Going to assembler will certainly require more tokens.
Can coding agents generate smaller and/or more efficient assembler
compared to going via source/compiler?

We shall see.

>        What about human review that still happens AFAIK?  What about
> programs that need to run on several architectures?

The review should happen at the specification stage.

English is the new source code (probably some controlled).
--
Derek M. Jones           Evidence-based software engineering
blog:https://shape-of-code.com

[toc] | [prev] | [next] | [standalone]

#3773

Derek M Jones <derek@knosof.co.uk> writes:
>Anton,
>
>> My sentence was phrased in a misleading way.  What I meant is: Not the
>> prompts (or not only), but primarily the generated code is stored in
> > the version control systems.
>
>Imagine if, when high level languages were new, that companies
>stored the compiler generated assembler in the version control system,
>rather than the source code.

Why would they?  The compiler always produces the same binary from the
source code.

>It is the specification used to generate the source that needs to
>be stored.
>
>The source is currently stored because coding agents are unreliable,

The prompts are not a complete specification, and that's why
unreliability is inherent in LLM code generation.  The superpower of
LLMs is that it takes a request that is missing a lot of things, and
guesses the missing things based on the stuff in the training data.
But the guesses can vary, so the unreliability is inherent in this
development model.

There is also the other unreliability where an LLM produces some stuff
that is not aligned with what is explicitly asked for in the prompt,
and maybe they will get that fixed (or, hopefully not; imagine what
will happen once our oligarchs no longer need humans to build and
control their machines, including swarms of killer drones, because the
machines are reliably aligned with the oligarchs' prompts).

>Going to assembler will certainly require more tokens.

That's a good reason to keep higher-level languages.

>Can coding agents generate smaller and/or more efficient assembler
>compared to going via source/compiler?

Even if they can, for most programs, and for the largest part of the
rest, efficiency is not important, and higher-level languages will be
used for that code in order to reduce token costs.

>>        What about human review that still happens AFAIK?  What about
>> programs that need to run on several architectures?
>
>The review should happen at the specification stage.

It's a benefit of LLMs that the need for a complete specification is
avoided, but that means that reviewing at the prompt level is
insufficient, even if the alignment problem is solved.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

[toc] | [prev] | [next] | [standalone]

#3770

Derek M Jones <derek@Knosof.co.UK> wrote:
|---------------------------------------------|
|"Is there a future for programming languages"|
|---------------------------------------------|

Of course. A person who uses an A.I. reports that to get non-trivial
problems solved via an AI, that he needs to specify so many details
that coding himself is easier.

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web