You define your Renderscript code in .rs and .rsh files in the src/ directory of your Android project. The code is compiled to intermediate bytecode by
Hi Cafe! I know, this topic comes back on the list from time to time. I know, there probably isn't anything new since the last time it was asked here, on reddit or on SO. However, I remember seeing that iPwn Studios were thinking about getting GHC to build applications for android, in addition to their ghc-iphone project. Is this correct? Is there anything new on that front? Is anyone else working/thinking-to-work on this? Aside from these questions, I'm wondering about the "easiest" way to get a ghc-android compiler up and running. I have found a few things, but they all look really, really painful and cumbersome, like http://stackoverflow.com/a/5152910/193424 or http://stackoverflow.com/a/7301024/193424 . Recently, I heard about Renderscript: http://developer.android.com/guide/topics/renderscript/index.html Of course, we could write a binding or some kind of EDSL à-la Atom to have some funny apps/games running on Android by generating Renderscript code under the hood. However, something in the "Renderscript Runtime Layer" section caught my attention: the llvm compiler
that runs as part of an Android build. When your application runs on a device, the bytecode is then compiled (just-in-time) to machine code by another llvm compiler that resides on the device. The machine code is optimized for the device and also cached, so subsequent uses of the Renderscript enabled application does not recompile the bytecode.
But hey, GHC *does* have an LLVM backend! So can't we somehow break that chain of compilers so that we can plug GHC's LLVM codegen on top of it and then use their llvm-on-the-device thing? I know I am skipping over many, many technical details like how we could have an analog to their "reflected layer" on the java side but I would really be interested in hearing your opinions/objections/thoughts on this. -- Alp Mestanogullari