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 <
[email protected]> 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 <[email protected]> *On Behalf Of *Csaba
> Hruska
> *Sent:* 07 June 2021 15:18
> *To:* GHC developers <[email protected]>
> *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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to