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