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

Groups > comp.lang.c > #280466 > unrolled thread

Re: MCC Compiler

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: MCC Compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-15 19:26 -0700
    Re: MCC Compiler Bart <bc@freeuk.com> - 2023-10-16 13:41 +0100

#280466 — Re: MCC Compiler

Bart <bc@freeuk.com> writes:

> On 29/09/2023 06:10, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>> to say about your experience working on compilers, especially
>> since those compilers are not written in C
>
> Is that really relevant?  Does a compiler for language L have to be
> written in L to be taken seriously?

What matters is whether you have something to say about
programming in C or about the C language.  Your compiler
isn't written in C so anything you have to say about the
compiler itself isn't relevant here, whether or not it
should be taken seriously.

In talking about how the compiler behaves, you don't say
anything that pertains to the C language.  I don't think
this notion is very hard to understand.  Talking about the
environment in which the compiler is built, even though it
might be interesting in other contexts, still has nothing
to do with the C language.

>> and aren't faithful to
>> the C language (and it isn't clear whether you don't know that or
>> if you just don't care).
>
> In which ways?

No one knows but you, and it's not even clear if you know.
Ironically, if you were to go through and make up a list of
differences between what your compiler accepts and what the
C standard requires, and present that list here, that WOULD
be topical, especially if there were reasons related to how
easy or hard some aspects of C are to compile.  For reasons
beyond understanding you leave out exactly the pieces of
information that would make it relevant in comp.lang.c.  I'm
at a loss to understand why you do that.

> My product compiles a C 'subset' but does not formally
> define what it is.

An informal definition is a lot better than no description
at all, and at least is something about the C language.
So figure out what the discrepancies are (and only you can
do that), and tell us about it.  That's why we're here!

> [speed of compiler]

There's nothing wrong with feeling pride in having written
a fast program (in a non-C language), but it's not a subject
of interest in this newsgroup.

> But it no longer supports my own extensions, like the many that gcc
> provides, and it no longer tries to improve on the language or fail
> programs on features I feel ought to be deprecated.

What would be relevant and possibly interesting is to say
what C language constructs you think should be considered
or left out.  Not what constructs IN OTHER LANGUAGES you
think are nice but what additions or changes to C you think
could add value.  Explain what, and leave it at that;  let
other people form their own opinions about how valuable
each change might be.

[toc] | [next] | [standalone]

#283775

On 16/10/2023 03:26, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:


>> My product compiles a C 'subset' but does not formally
>> define what it is.
> 
> An informal definition is a lot better than no description
> at all, and at least is something about the C language.
> So figure out what the discrepancies are (and only you can
> do that), and tell us about it.  That's why we're here!

OK, an informal definition is the subset of C that I personally use, and 
that I saw being commonly used on open source projects, at the start of 
2017.

It would loosely be C99 but missing Complex, VLAs, designated 
initialisers, compound literals, but with _Generic from C11 (that one 
could be trivially implemented in about 40 lines of code).

Since 2017, those missing features are much more commonly used, but I 
haven't changed the front end of the compiler.

There are also a whole bunch of restrictions and points of non-conformance.

Still, the compiler works on these projects there were used for testing:

* sqlite3.c + shell.c
* Tiny C 0.9.27 (0.9.28 uses extra features)
* Lua 5.4
* Pico C interpreter
* BBX (Malcolm's resource compiler)
* LIBJPEG 9e
* Piet (an interpeter for programs that look like Mondrian paintings)

Plus a bunch of smaller ones. Plus all the generated C code from my 
tools, but that uses an even smaller subset (eg. there are no #includes 
and no macros).

>> [speed of compiler]
> 
> There's nothing wrong with feeling pride in having written
> a fast program (in a non-C language), but it's not a subject
> of interest in this newsgroup.

I didn't mention the speed of the compiler. I said I can /transpile/ the 
source code to C more or less instantly, since the choice of the 
implementation language seemed to be an issue for you.

The actual speed of MCC is limited by having to use an intermediate ASM 
stage.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web