abstract interpreter for GHC Core or STG
Carter Schonwald
carter.schonwald at gmail.com
Tue Jun 8 20:51:32 UTC 2021
The stm impl In ghcjs might be a helpful comparative example on that front.
Though I guess more broadly does this necessitate having a model of the Cmm
semantics for the out of line primops ?
On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:
> 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?
>
>
>
> 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…
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
> Hruska
> *Sent:* 07 June 2021 15:18
> *To:* GHC developers <ghc-devs at haskell.org>
> *Subject:* abstract interpreter for GHC Core or STG
>
>
>
> Hello,
>
>
>
> 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?
>
> I'm curious because I'd like to turn my external STG interterpreter to an
> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>
> 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.
>
> I'm interested in any attempt that happened during GHC/Haskell evolution.
>
>
>
> Regards,
>
> Csaba Hruska
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/3ec40cad/attachment.html>
More information about the ghc-devs
mailing list