[M3devel] cm3 llvm backend?

[Rodney M. Bates]

On 06/27/2016 08:03 PM, Jay K wrote:
> So..rambling a bit..but I have discussed some with people
> and considered it.
>
>   "the interface to the compiler backend"
>
>
>   and my half serious answer:
>
>
>   All of the compilers have a well documented very stable
>   interface to their backends, and it is in fact the same,
>   roughly, interface to all the backends: source code.
>
>
>   It is true it isn't the most efficient representation.
>    Maybe the least efficient.
>
>
>   It might not expose all the internals at least portable (e.g. tail call).
>   But it works, is heavily used, is well known, documented,
>   has high compatibility requirements, somewhat readable with
>   standard tools, etc.
>
>
>   I would advocate that C and C++ be evolved a little bit
>   for these purposes. In particular, C needs exception handling.
>   C and C++ need a tail call notion.
>   _alloca should maybe be standardized.
>   I should be able to generate image-relative pointers/offsets.
>    (trivial in Microsoft assembly with "imagerel"), to help
>   me layout position indepenent data structures.
>
>
>   C-- is kind of this, and there was some C-resembling assembly,'
>   but I think really C should be the starting point, as it is pretty close.
>
>
>   Probably need some extensions like non-int bitfields, and
>   rotate, and shift right with both sign copying and zero fill.
>
>
>   > A teacher of mine called this behavior "version junkie".
>
>
>   There are at least two big reasons for this.
>
>   - The language really is improving. Programs
>     written in the newer language are easier to read
>     and often easier to optimize and sometimes easier
>     to implement a compiler for.

Sometimes so, sometimes not.  Sadly, many language "features" reflect
an implicit but very misguided belief that fewer keystrokes/characters
means increased readability.  Or at least that writability is more
important than readability.  So often, this means actual code is less
explicit.  But this makes maintenance far worse.

E.g., Ada decided use parentheses for both actual parameter lists to
function calls and subscript lists to arrays.  Along with optional
implicit operations like dereferencing, there are somewhere in the
teens of possible meanings for the innocent looking "f(x)".  I have forgotten
the exact number, but once had to do the semantic analysis.  That was
Ada 83.  Maybe more have been added since.  For the poor schmuck who
gets called at 3:00 AM to fix a bug in half a million lines of code
she didn't write, this is a readability disaster.  The savings of
keystrokes in not making the operations explicit is penny-wise and
million-pound foolish.

>
>   - Dogfooding -- using the language helps inform the
>    language implementer where they have done things right,
>    or wrong, and what to improve.
>
>
>   I believe in fact that under-dogfooding of C++ led
>   to some early omissions. The need for auto for example.
>   Granted, Stroustrup put it in in the 1980s and had to remove it.
>   But with more dogfooding by more implementers, it would
>   have been added earlier. Similarly "template typedefs".
>   Are obviously needed once you use templates for about a day.
>
>
>   Modula-3 has similar failings imho.
>   For example, the fact that with/var imply
>   a nesting that "needs" indentation and needs "end".
>   This is something that C++ and much later even C fixed.
>
>
>   Perhaps though, perhaps the Modula-3 designers were
>   balancing the specification and implementation against
>   user convenience, as the current design is obviously
>   simpler to specify and implement. But tedious to use.
>
> So the binary form of LLVM bit code is more stable than the text form?
>
>
>   - Jay
>
>
>
>
>  > Date: Mon, 27 Jun 2016 19:31:53 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] cm3 llvm backend?
>  >
>  >
>  >
>  > On 06/27/2016 03:29 PM, Henning Thielemann wrote:
>  > >
>  > > On Mon, 27 Jun 2016, Rodney M. Bates wrote:
>  > >
>  > >> And no, the names and operator spellings are not close to adequate
>  > >> to clue you in. They have gone to every length possible to use
>  > >> every clever new C++ "feature" that comes out in the latest
>  > >> C++-<n> standard, which always just increases the complexity
>  > >> of the search to a declaration. So I don't fancy doing any of
>  > >> this. (BTW, <n>=17 in recent discussions.)
>  > >
>  > > A teacher of mine called this behavior "version junkie".
>  > >
>  >
>  > Yes, yes.
>  >
>  > >
>  > >> Actually, keeping their bitcode stable across llvm releases is
>  > >> one place they do talk about compatibility. But m3llvm uses calls
>  > >> to llvm APIs to construct llvm IR as in-memory data, then another
>  > >> call to get llvm to convert it to bitcode. So bitcode's stability
>  > >> is irrelevant to us. I once thought about producing llvm bitcode
>  > >> directly, but that seems like a pretty big job. It would, however,
>  > >> obviate creating most of those wretched bindings.
>  > >
>  > > An alternative would be to create .ll text files. But its format changes, too.
>  >
>  > Yes. But, according to the list talk, they don't have the intention to
>  > make it as stable as the bitcode format.
>  >
>  >
>  > > _______________________________________________
>  > > M3devel mailing list
>  > > M3devel at elegosoft.com
>  > > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>  > >
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://m3lists.elegosoft.com/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org