Fwd: YHC for use in Lego Mindstorms NXT
From Alexis:
Hi Neil, I got your email from the YHC website, and I have several questions which I hope you can answer for me. I am an MSc student working on the development of a Haskell system for use with the Lego Mindstorms NXT (My intent is to port it using the GCC-ARM toolchain and get it running with the NXT firmware). For the most part I need a Haskell compiler that will run within the 256KB memory space. YHc seems like it could be perfect for such an application, but I am curious about the following: - Is YHc VM based? Or can it compile Haskell directly to C code, or both, or some intermediate code? - What is the typical memory footprint of the compiler/programs? Especially the interpreter/VM...? (I'm trying to compare this to GHc, for instance) Thanks in advance for your kind response. Cheers, -- </Alexis>
Hi Alexis, Sorry you couldn't post originally, perhaps you need to join the list first?
I am an MSc student working on the development of a Haskell system for use with the Lego Mindstorms NXT (My intent is to port it using the GCC-ARM toolchain and get it running with the NXT firmware). For the most part I need a Haskell compiler that will run within the 256KB memory space. YHc seems like it could be perfect for such an application, but I am curious about the following:
- Is YHc VM based? Or can it compile Haskell directly to C code, or both, or some intermediate code?
It compiles to a bytecode, which you execute using a C interpreter.
- What is the typical memory footprint of the compiler/programs?
The programs are small. The interpreter can be made quite small. The compiler is in the region of 5Mb, and would be impractical for running on the Lego machine, and should be unnecessary. You will probably find that porting Yhc is a lot easier, and the binaries are smaller - if I had to pick between GHC and Yhc for this task I'd choose Yhc. That said, 256kb is probably the lower end of what you can squeeze Yhc into. You may need to look at removing features like libgmp and ffi - Tom is probably in a better position to give you a minimum size. Thanks Neil
On Thu, May 31, 2007 at 12:13:26AM +0100, Neil Mitchell wrote:
Hi Alexis,
Sorry you couldn't post originally, perhaps you need to join the list first?
I am an MSc student working on the development of a Haskell system for use with the Lego Mindstorms NXT (My intent is to port it using the GCC-ARM toolchain and get it running with the NXT firmware). For the most part I need a Haskell compiler that will run within the 256KB memory space. YHc seems like it could be perfect for such an application, but I am curious about the following:
- Is YHc VM based? Or can it compile Haskell directly to C code, or both, or some intermediate code?
It compiles to a bytecode, which you execute using a C interpreter.
- What is the typical memory footprint of the compiler/programs?
The programs are small. The interpreter can be made quite small. The compiler is in the region of 5Mb, and would be impractical for running on the Lego machine, and should be unnecessary. You will probably find that porting Yhc is a lot easier, and the binaries are smaller - if I had to pick between GHC and Yhc for this task I'd choose Yhc.
That said, 256kb is probably the lower end of what you can squeeze Yhc into. You may need to look at removing features like libgmp and ffi - Tom is probably in a better position to give you a minimum size.
If you can't squeeze yhi, you can always rewrite it. Yhc bytecode is the best documented Haskell IR in existance; it took me a week and ~8 kbytes to produce a (throwaway prototype) implementation of most of yhi in Intel assembly. Also, the FFI is *mandatory* (Tom correct me), since all of Yhc's primops are pure (unlike GHC) - so FFI calls are the only way to perform IO. You might be able to revert to the nhc-ffi implementation, baking a set of allowable foreign functions into the interpreter. Also, gmp is bound using the FFI. Stefan
Hi
Neil Mitchell is working on a ultra-optimizing C backend for Yhc. Frankly this incongruity scares me.
It's currently looking like being an ultra-optimizing Haskell backend - I don't quite have the time to get down to the C. Its still something I do want to do one day though...
If you can't squeeze yhi, you can always rewrite it. Yhc bytecode is the best documented Haskell IR in existance; it took me a week and ~8 kbytes to produce a (throwaway prototype) implementation of most of yhi in Intel assembly.
Also, the FFI is *mandatory* (Tom correct me), since all of Yhc's primops are pure (unlike GHC) - so FFI calls are the only way to perform IO. You might be able to revert to the nhc-ffi implementation, baking a set of allowable foreign functions into the interpreter. Also, gmp is bound using the FFI.
It is currently mandatory, but the intention was to move back to baked in operations for the things in interpreter. The initial reason for moving everything into FFI was to test the FFI out. Our hope is that the interpreter can be parameterised (using #define) to remove the dependence of libffi and libgmp, to result in a smaller binary and less portability concerns - although those two libraries would be the standard on a normal computer. Thanks Neil
On Thu, May 31, 2007 at 12:10:06AM +0100, Neil Mitchell wrote:
From Alexis:
Hi Neil,
I got your email from the YHC website, and I have several questions which I hope you can answer for me. I am an MSc student working on the development of a Haskell system for use with the Lego Mindstorms NXT (My intent is to port it using the GCC-ARM toolchain and get it running with the NXT firmware). For the most part I need a Haskell compiler that will run within the 256KB memory space. YHc seems like it could be perfect for such an application, but I am curious about the following:
- Is YHc [sic] VM based? Or can it compile Haskell directly to C code, or both, or some intermediate code?
It currently uses a stack bytecode machine by default, and it can compile to two intermediate forms (PosLambda, which you don't want to know any more about, and Yhc.Core, a simple and orthogonal IR designed for use by external tools such as compiler backends) Neil Mitchell is working on a ultra-optimizing C backend for Yhc. Frankly this incongruity scares me.
- What is the typical memory footprint of the compiler/programs? Especially the interpreter/VM...? (I'm trying to compare this to GHc, for instance)
Thanks in advance for your kind response.
Cheers, -- </Alexis> _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc
participants (3)
-
Neil Mitchell -
Neil Mitchell -
Stefan O'Rear