[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.
>
>   - 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?
>

That's what they are saying.

A terminology point:  llvm would consider, I think, that "bit code" refers only
to the binary form, and the text form would be called something like
"llvm assembly code".  Files of binary form are conventionally
named <mumble>.bc and assembly code <mumble>.ll.  In the M3 llvm back end
binary files are <mumble>.ib and <mumble>.mb, to distinguish interfaces
and modules.  I am also using .ill and .mll for assembly files, but I'm
not sure these suffixes are coded in anywhere.

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