How about * concurrency (the ability to have zillions of little stacks, with stack overflow checks and growing the stck on overflow)? * exception handling (the ability to crawl over the stack looking for exception catch frames)? * garbage collection (the ability to find pointers in the stack) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- | haskell-users-bounces@haskell.org] On Behalf Of Wolfgang Thaller | Sent: 20 December 2006 23:55 | To: ttmrichter@gmail.com | Cc: GHC Users; Simon Marlow | Subject: Re: LLVM back end | | On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote: | | > Well, I'm almost entirely ignorant of LLVM and of Haskell -- | > especially the internals of both. That makes me ideally suited for | > this project since I'm not aware that it's impossible. | | I'm afraid LLVM currently lacks some features that are required for | efficient GHC code generation, specifically: | | a) Global Register Variables | b) The ability to put data next to code | c) (maybe, I'm not sure) Tailcalls | | ad a) | We need to keep some things in global registers for speed reasons | (depending on the number of available registers); among other things, | the haskell stack pointer and the heap pointer. Using regular global | variables instead would be a lot slower. | | ad b) | With (almost) every chunk of code, we want to associate a smal chunk | of data (the "info table") which contains information used by the | garbage collector and other parts of the run time system. We want to | use only one pointer to point to both of those things, and we don't | want to waste time with any additional indirections, so we make the | pointer point between the data chunk and the code chunk. | | ad c) | While they are supported in theory, I couldn't get LLVM to generate | any tailcalls. Maybe I've done something wrong, maybe they're not | really implemented yet. | | So I guess step one would be to start negotiating about those things | with the LLVM people. | | Cheers, | | Wolfgang | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users