On Tue, Jun 23, 2009 at 09:44:50PM -0400, Rick R wrote:
I don't know if you follow haskell cafe, but there was a lot of buzz over a new iPhone target. for GHC. It apparently took some hacks of the ghc source to get it into that state.
Yeah, that is part of the reason I pushed out the new release, since it makes compiling for targets like the iPhone a lot simpler. I was using jhc to write haskell programs for the iPhone back with my Gen1 phone before the AppStore existed. (jailbroken of course)
There is a lot of interest in being able to easily target other platforms, if it supported JVM that would be huge. Compiling to C/Native for the arm platform would be pretty great as well.
Compiling to the ARM works just fine via gcc right now. I have tested MIPS, ARM, and x86, but I don't think there is any reason jhc won't work with any back end that gcc supports. I would like to do a JVM target, but there are a couple things holding me back. The first is that a clear mapping from Grin to JVM isn't clear. jvm doesn't support some vital things such as structures (without the class overhead) and unsigned arithmetic (this may not be true anymore, does anyone know?) The other thing is library support, We would need to rewrite the Prelude functions to refer to JVM primitives rather than 'fread' 'fopen' and whatnot. I don't think the task is difficult, but it's time consuming and I don't know enough about the JVM api to get started. A syntax for 'foreign' declarations importing java primitives would also be needed. I have a syntax for dotnet primitives, perhaps it can be re-used pretty straightforwardly for java. In any case, I think a JVM or .NET back end would be quite doable, but it is not something I can do without help/support from someone fluent in the given VM and its APIs.
I'm sorry to hear about the region based GC. It would be neat if it worked. As an idea, it seems like the holy grail of GC. But everyone I've talked to says that it seems easy at 1st, but bucketing objects into regions seems to frequently place too much into the global pool.
Well, it is not lost work. as any effort I put into static analysis (which I lump all compile-time garbage reduction techniques) puts less of a strain on the run-time garbage collector and improves cache efficiency. No doubt some hybrid will evolve. Region inference can tell me what can be allocated on the stack for instance, and that is a big win even if I don't have general regions.
Timber sports a nice, incremental garbage collector that can be made to guarantee sub millisecond response times. Perhaps one could take some inspiration from it as a replacement for the current GC.
I'll look into it, an issue is that I am looking for a GC I can use with the gcc backend. Other backends (such as cmm or jvm) come with their own garbage collectors, and although a native code generator would be neat, I wouldn't want to rely on one. In fact, rather than write a native code generator, I would likely want to write a standalone c-- compiler that I can bundle with jhc. In the end, grin is close enough to c-- that I don't think I lose anything in the translation. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/