<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>So..rambling a bit..but I have discussed some with people<br>and considered it. </div><div><br></div><div> "the interface to the compiler backend" </div><div><br></div><div><br> and my half serious answer: </div><div><br></div><div><br> All of the compilers have a well documented very stable <br> interface to their backends, and it is in fact the same, <br> roughly, interface to all the backends: source code. </div><div><br></div><div><br> It is true it isn't the most efficient representation. <br> Maybe the least efficient.</div><div><br></div><div><br> It might not expose all the internals at least portable (e.g. tail call). <br> But it works, is heavily used, is well known, documented, <br> has high compatibility requirements, somewhat readable with<br> standard tools, etc. </div><div><br></div><div><br> I would advocate that C and C++ be evolved a little bit<br> for these purposes. In particular, C needs exception handling.<br> C and C++ need a tail call notion.<br> _alloca should maybe be standardized.<br> I should be able to generate image-relative pointers/offsets. <br> (trivial in Microsoft assembly with "imagerel"), to help<br> me layout position indepenent data structures. </div><div><br></div><div><br> C-- is kind of this, and there was some C-resembling assembly,'<br> but I think really C should be the starting point, as it is pretty close. </div><div><br></div><div><br> Probably need some extensions like non-int bitfields, and<br> rotate, and shift right with both sign copying and zero fill. </div><div><br></div><div><br> > A teacher of mine called this behavior "version junkie".</div><div><br></div><div><br> There are at least two big reasons for this. <br> </div><div><br></div><div> - The language really is improving. Programs <br> written in the newer language are easier to read <br> and often easier to optimize and sometimes easier <br> to implement a compiler for. <br> <br> - Dogfooding -- using the language helps inform the <br> language implementer where they have done things right, <br> or wrong, and what to improve. <br> <br> <br> I believe in fact that under-dogfooding of C++ led <br> to some early omissions. The need for auto for example. <br> Granted, Stroustrup put it in in the 1980s and had to remove it. <br> But with more dogfooding by more implementers, it would <br> have been added earlier. Similarly "template typedefs". <br> Are obviously needed once you use templates for about a day. </div><div><br></div><div><br> Modula-3 has similar failings imho.<br> For example, the fact that with/var imply <br> a nesting that "needs" indentation and needs "end". <br> This is something that C++ and much later even C fixed. </div><div><br></div><div><br> Perhaps though, perhaps the Modula-3 designers were <br> balancing the specification and implementation against <br> user convenience, as the current design is obviously <br> simpler to specify and implement. But tedious to use. <br> </div><div><br></div><div>So the binary form of LLVM bit code is more stable than the text form?</div><div><br></div><div><br> - Jay<br><br><br><br><br></div><div>> Date: Mon, 27 Jun 2016 19:31:53 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] cm3 llvm backend?<br>> <br>> <br>> <br>> On 06/27/2016 03:29 PM, Henning Thielemann wrote:<br>> ><br>> > On Mon, 27 Jun 2016, Rodney M. Bates wrote:<br>> ><br>> >> And no, the names and operator spellings are not close to adequate<br>> >> to clue you in. They have gone to every length possible to use<br>> >> every clever new C++ "feature" that comes out in the latest<br>> >> C++-<n> standard, which always just increases the complexity<br>> >> of the search to a declaration. So I don't fancy doing any of<br>> >> this. (BTW, <n>=17 in recent discussions.)<br>> ><br>> > A teacher of mine called this behavior "version junkie".<br>> ><br>> <br>> Yes, yes.<br>> <br>> ><br>> >> Actually, keeping their bitcode stable across llvm releases is<br>> >> one place they do talk about compatibility. But m3llvm uses calls<br>> >> to llvm APIs to construct llvm IR as in-memory data, then another<br>> >> call to get llvm to convert it to bitcode. So bitcode's stability<br>> >> is irrelevant to us. I once thought about producing llvm bitcode<br>> >> directly, but that seems like a pretty big job. It would, however,<br>> >> obviate creating most of those wretched bindings.<br>> ><br>> > An alternative would be to create .ll text files. But its format changes, too.<br>> <br>> Yes. But, according to the list talk, they don't have the intention to<br>> make it as stable as the bitcode format.<br>> <br>> <br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br></div> </div></body>
</html>