You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing people sometimes want is to generate files of GHC’s bytecode. That can make for faster recompilation and even a way to build an “interpreted” exe, both of these could yield much faster dev cycles when the project is large and build times are more painful than runtime. On a project with 1000 modules and lots of TH, that recompiling of bytecode can hurt.
I’m wondering whether one could generate external STG when in GHC’s Interpreted linker mode.
Your external-stg looks like it goes in both directions: stg -> external stg and back. Are there any pitfalls/caveats to its current implementation?
I’m aware that its speed won’t be good because it’s using the binary package, but that’s easily swapped out for something more efficient.
The text was updated successfully, but these errors were encountered:
Yes, the external-stg-compiler can feed back ext-stg to ghc for codegen.
The latest code is available on github.
The pipeline does not use the bytecode at all.
One thing people sometimes want is to generate files of GHC’s bytecode. That can make for faster recompilation and even a way to build an “interpreted” exe, both of these could yield much faster dev cycles when the project is large and build times are more painful than runtime. On a project with 1000 modules and lots of TH, that recompiling of bytecode can hurt.
I’m wondering whether one could generate external STG when in GHC’s Interpreted linker mode.
Your external-stg looks like it goes in both directions: stg -> external stg and back. Are there any pitfalls/caveats to its current implementation?
I’m aware that its speed won’t be good because it’s using the
binary
package, but that’s easily swapped out for something more efficient.The text was updated successfully, but these errors were encountered: