Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] VxWorks? mailing list?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-03-30 (20:28)
From: james woodyatt <jhw@w...>
Subject: Re: [Caml-list] VxWorks? mailing list?
On Sunday, Mar 30, 2003, at 02:26 US/Pacific, Xavier Leroy wrote:
> [Someone else asked]
>> Has anyone heard of running OCaml programs under the VxWorks real-time
>> OS from WindRiver?  People who build actual products are asking me if
>> my OCaml code can run under VxWorks and I'd appreciate hearing about
>> any experiences others have had with either compiling the byte-code
>> interpreter or getting native code to work for any of the VxWorks
>> targets.  Wouldn't it be nice if we could point to OCaml code in
>> everyday office products?
> I have no experience with VxWorks, but from their Web site it appears
> to be POSIX-compliant.  If so, chances are very high that the bytecode
> interpreter will compile and work right out of the box.  For the
> native-code compiler, the porting effort can range from the trivial
> (e.g. one of the supported configurations just happens to work) to the
> fairly hard (e.g. a new code generator has to be written).  It's not
> possible to say without more details on the target platform and
> environment.

I have experience with VxWorks.  Its "POSIX compliance" is narrow.  
Code is generally cross-compiled and deployment is much more like 
loading a module into a dynamic kernel rather than launching a POSIX 

I would expect that some non-trivial labor would be involved in porting 
the build process for the byte-code interpreter to make it live with 
the VxWorks cross-development tools in $WIND_BASE/host/$arch/bin.  Then 
there would likely be a collection of issues revolving around symbol 
conflicts, i.e. things defined in the byte-code interpreter that are 
provided by VxWorks-- or by whatever other Wind River platform packages 
you're using.  There would finally be issues associated with making the 
VxWorks IPC mechanisms available to OCaml programs.

The native-code compiler could also be a major additional headache if 
the CPU of your target is something weird, like say an ARM processor.

I like OCaml, but I suspect that Lua might be a better choice for 
bringing functional programming to the embedded application world.  It 
would probably be a lot easier to get Lua up and running under VxWorks.

j h woodyatt <>

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: