Browse thread
[Caml-list] VxWorks? mailing list?
-
Wheeler Ruml
-
Xavier Leroy
- Wheeler Ruml
- David Brown
- james woodyatt
-
Xavier Leroy
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 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