<div dir="ltr">The external STG interpreter implements the RTS semantics and features, so if we apply the calculating correct compiler method to the external STG interpreter code then we should get an IR that will include the RTS code also.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021 at 12:21 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">How would this be used to generate the rts automatically? I’m intrigued / would like to understand what you’re envisioning design wise for that leg. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska <<a href="mailto:csaba.hruska@gmail.com" target="_blank">csaba.hruska@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Cmm is too low level, I've implemented the primops in haskell in a high level way, including the out of line primops with the rts related parts (scheduler, io manager).</div><div>see:</div><div><a href="https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs" target="_blank">https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs</a></div><div><a href="https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp" target="_blank">https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp</a></div><div><br></div><div>STM is still missing though, but IMO it would be similar to concurrency/exception related primops.</div><div>Regarding the ghcjs STM implementation, IMO the primops needs to be implemented at least in Haskell in a pure way with ADTs to be easy for reasoning.<br></div><div>But thanks for the reference.</div><div><br></div><div>Currently, I'm in the design phase. I.e. I need to design the abstract domain of the STG machine values.</div><div><br></div><div>If this approach succeeds then it would be interesting to apply the calculating correct compilers method on the stg interpreter to get a compiler form it.</div><div>With this level of automation it would be extremely easy to support new target platforms, because the RTS would be generated automatically. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">The stm impl In ghcjs might be a helpful comparative example on that front. </div><div dir="auto"><br></div><div dir="auto">Though I guess more broadly does this necessitate having a model of the Cmm semantics for the out of line primops ? </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
I wonder if there was an attempt in the past to create an abstract interpreter for GHC Core or STG to approximate the program runtime behaviour?<u></u><u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>No, not that I know of. Because of all the primops, concurrency, STM, etc, it would be something of a challenge. The AAM story could be interesting…</span></p></div></div><div lang="EN-GB"><div><p class="MsoNormal"><span><u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>>
<b>On Behalf Of </b>Csaba Hruska<br>
<b>Sent:</b> 07 June 2021 15:18<br>
<b>To:</b> GHC developers <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> abstract interpreter for GHC Core or STG<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I wonder if there was an attempt in the past to create an abstract interpreter for GHC Core or STG to approximate the program runtime behaviour?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I'm curious because I'd like to turn my external STG interterpreter to an abstract interpreter using the AAM (Abstracting Abstract Machines) method.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
This approach seems promising to me because a single Haskell code base (ext STG interpreter) could be the specification of the Haskell operational semantics and also be a detailed static analyzer that could help optimization transformations.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I'm interested in any attempt that happened during GHC/Haskell evolution.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Csaba Hruska<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>