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.
On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska <csaba.hru...@gmail.com> wrote: > 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). > see: > > https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs > > https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp > > STM is still missing though, but IMO it would be similar to > concurrency/exception related primops. > 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. > But thanks for the reference. > > Currently, I'm in the design phase. I.e. I need to design the abstract > domain of the STG machine values. > > 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. > With this level of automation it would be extremely easy to support new > target platforms, because the RTS would be generated automatically. > > On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> 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
