<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>I was reading an article and one a good consequence of Using a type safe like CLR, C-- would be be able to detect deadlocks with type inference.<br>http://arxiv.org/pdarf/1002.0942.pdf<br><br>So it can be good to do that for safety reasons, but at the cost of type inference time, which I think you wouldn't like too much for JIT compilers.<br>Thanks in advance<br><br>--- El <b>mié, 22/8/12, Hendrik Boom <i><hendrik@topoi.pooq.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Hendrik Boom <hendrik@topoi.pooq.com><br>Asunto: Re: [M3devel] higher level m3cg?<br>Para: m3devel@elegosoft.com<br>Fecha: miércoles, 22 de agosto, 2012 13:38<br><br><div class="plainMail">On Tue, Aug 21, 2012 at 01:18:48PM +0200, Dirk Muysers wrote:<br>> *** A warning ***<br>>
 Norman Ramsey's opinion (in stackoverflow) on possible compiler backends:<br>> <br>> Code generation is my business :-)<br>> <br>> Comments on a few options:<br>> <br>>   a.. CLR: <br>> <br>>     a.. Pro: industrial support <br>>     b.. Con: you have to buy into their type system pretty much completely; depending on what you want to do with types, this may not matter <br>>     c.. Con: Only Windows platform is really prime-time quality<br>>   b.. LLVM:<br>> <br>>     a.. Pro: enthusiastic user community with charismatic leader <br>>     b.. Pro: serious backing from Apple <br>>     c.. Pro: many interesting performance improvements <br>>     d.. Con: somewhat complex interface <br>>     e.. Con: history of holes in
 the engineering; as LLVM matures expect the holes in the engineering to be plugged by adding to the complexity of the interface<br><br>When I was investigating using LLVM for Algol 68, I ran into one problem <br>that persuaded me to use C-- instead.  Pointer arithmetic is C's pointer <br>arithmetic; that is adding an integer to a pointer automatically scales <br>the integer by the size of the thing pointed to.  Now arrays in C++ have <br>the property that the stride -- the offset from each element to the next <br>-- in not neccarily a multiple of the item pointed to, so using LLVm's <br>pointer arithmetic is pretty well excluded -- without kludhes like <br>casting everything to void* and then casting it back again.  If LLVM <br>does any kind of type-based optimization, this will effectively disable <br>it.<br><br>I prefer to use things the way they were intended to be used, bot to <br>abuse them and hope things still work.<br><br>Of
 course the same objections apply to C and C++.<br><br>There was also a problem with having to completely define every <br>structure before you can even put any of its field names in the parse <br>tree you can in principle generate in any order you wish.  This <br>interfered with building run-time data structures whose full contents <br>would not be known until compilation was complete.<br>  <br>>   c.. C--<br>> <br>>     a.. Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit your C-- code <br>>     b.. Pro: design is reasonably mature and reasonably clean <br>>     c.. Pro: supports accurate garbage collection <br>>     d.. Pro: most users report it is very easy to use <br>>     e.. Con: very small development team <br>>     f.. Con: as of
 early 2009, supports only three hardware platforms (x86, PPC, ARM) <br>>     g.. Con: does not ship with a garbage collector <br>>     h.. Con: project has no future<br><br>C-- did allow unscaled pointer arithmetic.<br><br>C-- did not have any API calling order restrictions, because it didn't <br>have an API.  Any define-before-use restrictions could be fudged by <br>generating output as several files and then concatenating them <br>afterward.  Of course this could be done with LLVM too.<br><br>About the garbage collector.  The world needs a robust garbage <br>collector supports multicore systems on which collection is <br>concurrent with execution.  The necessary synchronisation will cause <br>performance loss, but there are applications where chunky <br>garbage-colections delays are unaccepatable, bot general slowness is OK.<br><br>Of course such a collector could have compile-time (or
 maybe run-time) <br>options whether to support expensive features for applications where <br>they are not relevant.<br><br>>   d.. C as target language<br>> <br>>     a.. Pro: looks easy <br>>     b.. Con: nearly impossible to get decent performance <br>>     c.. Con: will drive you nuts in the long run; ask the long line of people who have tried to compile Haskell, ML, Modula-3, Scheme and more using this technique. At some point every one of these people gave up and built their own native code generator.<br>> Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality, and expected longevity, I'd probably recommend LLVM.<br>> <br>> Full disclosure: I am affiliated with the C-- project.<br><br>Yay!<br><br>> <br>>  <br>> <br>> <br>> From: Jay K <br>> Sent: Thursday, August 16, 2012 4:21
 PM<br>> To: m3devel <br>> Subject: [M3devel] higher level m3cg?<br>> <br>> <br>> Should m3cg provide enough information for a backend to generate idiomatic C?<br>> (What is idiomatic C? e.g. I'm ignoring loop constructs and exception handlinh..)<br>> <br>> <br>> Should we make it so?<br>> <br>> <br>> Or be pragmatic and see if anyone gets to that point?<br>> <br>> <br>> But, look at this another way.<br>> Let's say we are keeping the gcc backend.<br>> <br>> <br>> Isn't it reasonable to have a better experience with stock gdb?<br>> <br>> <br>> What should m3cg look like then?<br>> <br>> <br>> Matching up m3front to gcc turns out to be "wierd".<br>> As does having a backend generate "C".<br>> <br>> <br>> In particular, "wierd" because there is a "level mismatch".<br>> <br>> <br>> m3cg presents a fairly low level view of the program.<br>>   It
 does layout. Global variables are stuffed into what you might call a "struct", with<br>> no assigned field names. Field references are done by adding to addresses and casting.<br>> <br>> <br>> Too low level to provide a "good" gcc tree representation or to generate "normal" C.<br>> <br>> <br>> One might be able to, by somewhat extraordinary means, make due.<br>> That is, specifically one could deduce field references from<br>> offsets/sizes. But maybe it is reasonable for load/store<br>> to include fields? Maybe in addition to what it provides?<br>> <br>> <br>> As well, it appears to me, that<br>> <br>> <br>> given TYPE Enum = {One, Two, Three};<br>> <br>> the m3cg is like:<br>> <br>> declare enum typeidblah<br>> declare enum_elt One<br>> declare enum_elt Two<br>> declare enum_elt Three<br>> declare_typename typeidblah Enum<br>> <br>> <br>> One kind of instead wants more
 like:<br>> <br>> <br>> declare enum typeidblah Enum<br>> declare enum_elt One => rename it Enum_One<br>> declare enum_elt Two ""<br>> declare enum_elt Three ""<br>> <br>> <br>> However I understand that {One, Two, Three} exists<br>> as anonymous type independent of the name "Enum".<br>> <br>> <br>> One could just as well have:<br>> given TYPE Enum1 = {One, Two, Three};<br>> given TYPE Enum2 = {One, Two, Three};<br>> <br>> <br>> Enum1 and Enum2 probably have the same typeid, and are just<br>> two typenames for the same type.<br>> <br>> <br>> likewise:<br>> given TYPE Enum1 = {One, Two, Three};<br>> given TYPE Enum2 = Enum1;<br>> <br>> <br>> but, pragmatically, in the interest of generating better C,<br>> can we pass a name along with declare_enum?<br>> <br>> I ask somewhat rhetorically. I realize there is the answer:<br>>   enum Mtypeid {
 Mtypeid_One, Mtypeid_Two, Mtypeid_Three };<br>>   typedef enum Mtypeid Enum1;<br>> <br>> <br>> Also, enum variables I believe end up as just UINT8, 16, or 32.<br>> Loads of enum values I believe end up as just loads of integers.<br>> Can we pass along optional enum names with declare_local/declare_param?<br>> And optional enum names with load_int?<br>> Or add a separate load_enum call?<br>> <br>> <br>> Really, I understand that the current interface can be pressed to do<br>> pretty adequate things. I can infer field references. The way enums work<br>> isn't too bad.<br>> <br>> <br>>  - Jay <br></div></blockquote></td></tr></table>