Re[2]: inside the GHC code generator

Hello Ben, Friday, February 24, 2006, 2:04:26 AM, you wrote:

...

* multiple results can be returned via C++ pair template, if this is efficiently implemented in gcc

BRG> There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off BRG> by default on many architectures. thank you! -1 problem. moreover, we can use just plain C for our translation instead of C++

...

* recursive definitions translated into the for/while loops if possible

BRG> I think recent versions of GCC do a good job of this. See BRG> http://home.in.tum.de/~baueran/thesis/ there is no problem with proper handling of tail calls. the problem is what these loops are not unrolled, generating significantly worse code than explicit loop. you can see this in the files i attached to the original letter BRG> All of this efficiency stuff aside, there's a big problem you're neglecting: BRG> GARBAGE COLLECTION. For a language that allocates as much as Haskell I think BRG> a conservative collector is absolutely out of the question, because they BRG> can't compact the heap and so allocation becomes very expensive. A copying BRG> collector has to be able to walk the stack and find all the roots, and that BRG> interacts very badly with optimization. All the languages I've seen that BRG> compile via C either aren't garbage collected or use a conservative or BRG> reference-count collector. as i said, we can just use 2 stacks - one, pointed by EBP register, contains all boxed values, second is hardware stack, pointed of course by ESP, contains unboxed values and managed by gcc as for any other C programs. so, the boxed parameters to functions are go through EBP-pointed stack and unboxed values passed via usual C conventions: int fac(int n, int r) currently, EBP is used for all data and ESP is just not used. moreover, until 1999 the same two stacks scheme was used in GHC. comparing to current one stack scheme, we will need more space for stacks and may lose something because memory usage patterns will be slightly less localized -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com