Re: [Caml-list] VxWorks? mailing list?

[james woodyatt <jhw@wetware.com>]

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 
process.

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 <jhw@wetware.com>

-------------------
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