Newest at the top
| 2025-02-08 13:00:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 13:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-02-08 12:53:59 +0100 | euleritian | (~euleritia@dynamic-176-006-128-136.176.6.pool.telefonica.de) |
| 2025-02-08 12:53:38 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-02-08 12:34:50 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) (Remote host closed the connection) |
| 2025-02-08 12:32:03 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-02-08 12:31:33 +0100 | tavare | (~tavare@user/tavare) (Ping timeout: 252 seconds) |
| 2025-02-08 12:27:29 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-02-08 12:17:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-08 12:12:55 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 12:12:21 +0100 | hazmat_237 | (~hazmat_23@user/Monospace) (Ping timeout: 276 seconds) |
| 2025-02-08 12:09:39 +0100 | <euouae> | nice, thank you |
| 2025-02-08 12:09:22 +0100 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary is another very good place to look |
| 2025-02-08 12:08:49 +0100 | <geekosaur> | this happens post-Cmm in the compile pipeline |
| 2025-02-08 12:08:34 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f0588a4d7c575081360.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-02-08 12:08:17 +0100 | <euouae> | I'm realizing the GHC docs are a valuable source to learn stuff from |
| 2025-02-08 12:07:49 +0100 | <euouae> | very nice |
| 2025-02-08 12:07:41 +0100 | <geekosaur> | unless you're in LLVM mode where it outputs LLVM IR and calls `opt` and `llc` |
| 2025-02-08 12:07:24 +0100 | <geekosaur> | it generates assembly language and calls `as` on it |
| 2025-02-08 12:07:04 +0100 | <euouae> | yup; although it doesn't explain how the code is natively generated |
| 2025-02-08 12:06:27 +0100 | <geekosaur> | section 1.5.6 in particular, second entry |
| 2025-02-08 12:04:01 +0100 | <euouae> | ah thank you |
| 2025-02-08 12:03:51 +0100 | <int-e> | (more generally you can start from https://www.haskell.org/ghc/download.html and select the version and that'll have a release notes link) |
| 2025-02-08 12:03:23 +0100 | <int-e> | https://downloads.haskell.org/~ghc/7.2.1/docs/html/users_guide/release-7-2-1.html |
| 2025-02-08 12:02:40 +0100 | <euouae> | I can't find a changelog file, how can I read the GHC notes for 7.2? |
| 2025-02-08 12:02:24 +0100 | <euouae> | no that's not what I meant |
| 2025-02-08 12:00:58 +0100 | <geekosaur> | unless you mean unregisterised mode, but you absolutely don't want that if you want speed; it's intended for porting and produces extremely slow but extremely portable ANSI C |
| 2025-02-08 11:59:56 +0100 | <geekosaur> | not since 7.2 |
| 2025-02-08 11:59:28 +0100 | <euouae> | does ghc still target C? because tahts' what STG targets in SPJs paper |
| 2025-02-08 11:53:47 +0100 | <geekosaur> | (certainly old implementation papers will be too old to help, especially since none of them will know about amd64 or aarch64) |
| 2025-02-08 11:48:28 +0100 | <geekosaur> | there are a few things at Cmm and STG levels but you won't find anything except the ghc source to help with those |
| 2025-02-08 11:48:19 +0100 | <euouae> | Ah, hm... I meant that I want to write code that is fast, not to study the optimizations of GHC |
| 2025-02-08 11:47:50 +0100 | <geekosaur> | almost all optimizations in ghc are done at the level of Core |
| 2025-02-08 11:47:46 +0100 | <euouae> | I've read that Core does not capture certain issues with memory use & other benchmarking analysis |
| 2025-02-08 11:47:25 +0100 | <geekosaur> | GRIN itself seems to be kinda stuck, but STGi will show you how STG works without requiring you to delve into implementation details (SPJ's paper talks a lot about register allocation etc.) |
| 2025-02-08 11:47:02 +0100 | <euouae> | when you say stick to Core for optimizations & parallel what do you mean? |
| 2025-02-08 11:46:47 +0100 | <euouae> | nice thanks |
| 2025-02-08 11:46:02 +0100 | <geekosaur> | https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-inter… |
| 2025-02-08 11:45:51 +0100 | <int-e> | I don't really know which one comes closest to current GHC in terms of syntax and semantics. |
| 2025-02-08 11:45:32 +0100 | <geekosaur> | not the while thing, just the external STG interpreter |
| 2025-02-08 11:43:52 +0100 | <int-e> | Hmm there's the more recent "making a fast curry: push/enter vs. eval/apply" paper as well. And another implementation: https://hackage.haskell.org/package/ministg |
| 2025-02-08 11:43:48 +0100 | <euouae> | Are you talking about <https://github.com/grin-compiler/ghc-whole-program-compiler-project>? |
| 2025-02-08 11:43:41 +0100 | <geekosaur> | if you want to write optimized and parallel code, stick to Core |
| 2025-02-08 11:43:07 +0100 | <geekosaur> | *incomplete |
| 2025-02-08 11:43:00 +0100 | <geekosaur> | even though that is imcomplete (e.g. doesn't support update frames) |
| 2025-02-08 11:42:36 +0100 | <geekosaur> | IMO if you want to know how to implement it, read SPJ's paper. If you want to understamnd what's going on down there, see Csaba Hruska's STGi |
| 2025-02-08 11:42:30 +0100 | <euouae> | But if I should say something I guess my goal is to write optimized & parallel code |
| 2025-02-08 11:41:58 +0100 | <euouae> | I'm just messing around with the lower parts I don't have explicit goals |
| 2025-02-08 11:41:49 +0100 | <euouae> | I |
| 2025-02-08 11:39:57 +0100 | <__monty__> | That depends rather more on your goals than anything. |