[jhc] Emitting Optimal C

John Meacham john at repetae.net
Mon Feb 23 18:44:07 EST 2009


On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote:
> I have been looking for a functional language that compiles to efficient
> C/C++ to fufill two rather odd criteria.
> 
> 1. To conform to the requirements of the iPhone Developers Program. Code
> must compile in XCode and be either C/C++/Obj-C. Garbage collection is
> mostly disallowed. Program size and memory must fit below a threshold.

Hmm.. interesting. What compiler is XCode based on? If it is a gcc
derivitive, I don't see any reason this wouldn't work. It is actually
quite easy to compile programs for OSX or windows with jhc
if you have something like IMCROSS[1] installed. you just do

jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe

I was able to compile programs for the iPhone the same way, but I had a
jailbroken phone so didn't need to conform to their other standards.

I am not sure what they could mean by 'no GC', is it simply because they
require C/C++ or ObjC? I mean, when you write a C program, clearly you
need to write in some mechanism to deal with garbage. 

Hmm.. you might want to ask them whether it is okay to link against the
boehm gc.  although not ideal (very not ideal speed-wise), jhc works
with that, but if they allow it, then I imagine the more advanced gc
options will be okay too.


> 2. Separately, to perform Naive Bayes computation across huge datasets. What
> is required is function inlining as well as use of SIMD instructions.
> I would provide the inlined functions via .h's and compile them in with gcc.

How huge of a dataset? Are you working on a better song recommendation
wizard? Something you might want to look into is that I am pretty sure
the iPhone has sqlite as standard equipment, I think you can extend it
with your own operations, perhaps a bayes computation operation or
something. hmm... but the sqlite overhead might kill you. hard to say.

> I see that jhc see offers a way to specify unboxed values and tuples. And
> I'm sure there is a way to manage large native arrays as well. Is there a
> way to pass that data directly to an inline C function that would be
> compiled in by gcc? (i.e. not loaded from a library through FFI)

When you import something via the FFI, say something like

foreigin import ccall foo :: CInt -> CInt

then nothing special happens other than calls to foo(x) will appear in
the source. now, you can provide that function however you want, via a
library, or via direct linking against the C code, jhc doesn't really
care. 

Hmm.. if you want to actually have them be inlined functions, I will
probably have to give you a way to specify that the definition actually
might appear in the header file, not just a prototype (since prototypes
arn't needed in general) so a pragma might be in order to say "I really
need this file #included.". It should be easy to implement. When you
come across the issue post it on the list and we can figure out what the
best solution is. A trivial workaround would be to just postprocess the
c code produced by jhc itself until a built in mechanism is created.


> I've looked through most of the jhc mailing list archives and haven't found
> any such discussions. Would this be something that would be achievable
> somewhere in the jhc roadmap, or at least conceivable with a few hacks?

Nothing sounds like a showstopper. jhc is great at cross compiling, so
embedded targets like phones are a natural match with it.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the jhc mailing list