inside the GHC code generator

[Bulat Ziganshin]

Hello Ben,

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

>> * multiple results can be returned via C++ pair<a,b> 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 at gmail.com