Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: mikel evins <mikel@e...>
Subject: Re: [Caml-list] Re: bytecode and native code at once

On Aug 26, 2004, at 11:04 AM, Paul Snively wrote:

> Finally, the one thing that's a stumbling block for most folks in our 
> circle when talking about O'Caml is the lack of platform bindings. 
> Mike Hamburg has taken a good stab at an O'Caml/Objective-C gateway. 
> That really needs finishing, and I had begun thinking about how to 
> automatically generate actual OS bindings by parsing Objective-C 
> headers and providing any necessary external annotations a la the 
> Forklift FFI, but I haven't gotten anywhere with that beyond thinking 
> about it.

You might consider using ffigen to parse the headers and writing a 
simple parser in Ocaml to read its output. This is basically how the 
autogenerated ffi works in OpenMCL (ffigen can be hard to find; I can 
send you a copy of the version used with OpenMCL if you like).

>
> Anyway, I now take O'Caml very, very seriously. I believe it to be a 
> perfectly reasonable alternative to C++ for folks who want expressive 
> power, safety, reasonable resource consumption, and runtime 
> performance. Clearly there are areas in which there's still more work 
> to be done, cf. the conversations about floating-point representation 
> for high-performance 3D programming, or about memory-mapped files and 
> their interaction with the garbage collector. Nothing you're not 
> familiar with from your extensive work in Common Lisp and Mac OS X. 
> :-)

Yep. :-)

>
> Your turn: what's your O'Caml story?

I like languages. I like FP, always have. I've been messing with Caml 
and its variants for too long to remember when I started. For several 
years now I almost always had some small project going in Ocaml. Things 
heated up over the past two years as I found it possible to deploy 
Ocaml tools at work, and now I rely on it extensively for certain 
classes of project.

Basically, I still think best and most fluidly in Lisp, and I explore 
ideas and prototype things there. If I want to deploy a compact, 
single-file native executable that is really fast, I rewrite it in 
Ocaml (which I find quite easy to do most of the time). When I 
absolutely need something in C, for those (rare) cases that Ocaml won't 
do the job, I write it first in Ocaml and then translate it to C, using 
Ocaml as a specification language to make it easier to write correct C 
code.

An example of where I have to -- reluctantly -- do things in C or 
assembler is a virtual machine I'm doing where I really need to control 
register allocation, alignment, and specific bit-patterns in 64-bit 
words. I prototyped it in Ocaml using the Int64 library, then moved to 
C so that my word size was the native word size on AMD64, using GCC's 
extensions to control register allocation and alignment. The VM is 
about 30 times faster in C than in Ocaml and about one twentieth the 
object size, but that's specific to the nature of the project. I've 
also done projects in which Ocaml produced significantly faster code 
than GCC.

Of course, if someone showed me that I could get the same results using 
Ocaml, I'd move right back in a heartbeat. :-)

>
>>> Is there some reason that asmdynlink, which is part of the Caml 
>>> Development Kit, doesn't address this?
>>
>> I don't know. All I was saying is that I knew nothing about it, 
>> because I had devoted no attention to the issue.
>>
> Right; fair enough. You can find the CDK, including asmdynlink, at 
> <http://pauillac.inria.fr/cdk>.
>
>>>
>>> I also think that once MetaOCaml gets its native compiler done that 
>>> it will help answer the question as well, among others. I find 
>>> MetaOCaml very exciting!
>>
>> Yeah, I heard the same thing from Adam Megacz. I suppose I oughta 
>> check it out.
>>
> <http://www.metaocaml.org> is the place. I don't know what the status 
> of their native-code support is, though; it's been a long time coming.

Thanks for the pointers.

--me

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners