From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA10542; Thu, 5 Feb 2004 17:43:06 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA11336 for ; Thu, 5 Feb 2004 17:43:04 +0100 (MET) From: Leszek.Holenderski@philips.com Received: from gw-nl6.philips.com (gw-nl6.philips.com [161.85.127.52]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i15Gh3f11301 for ; Thu, 5 Feb 2004 17:43:04 +0100 (MET) Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 44D486B498 for ; Thu, 5 Feb 2004 17:43:03 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id B6FEB19C4A for ; Thu, 5 Feb 2004 17:43:02 +0100 (MET) Received: from smtprelay-nl1.philips.com (smtprelay-eur1.philips.com [130.139.36.3]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 49FC019C47 for ; Thu, 5 Feb 2004 17:43:02 +0100 (MET) Received: from prle4.natlab.research.philips.com (prle4.natlab.research.philips.com [130.145.137.96]) by smtprelay-nl1.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id RAA06987 for ; Thu, 5 Feb 2004 17:43:01 +0100 (MET) Received: from smtpmon (smtpmon [130.145.137.150]) by prle4.natlab.research.philips.com (8.11.6/8.11.6) with ESMTP id i15Gh1U10790 for ; Thu, 5 Feb 2004 17:43:01 +0100 Received: from PC7076.ddns.htc.nl.philips.com ([130.145.174.21]) by smtpmon (MailMonitor for SMTP v1.2.0 ) ; Thu, 5 Feb 2004 17:43:01 +0100 (CET) Message-ID: <40227294.714891FF@philips.com> Date: Thu, 05 Feb 2004 17:43:00 +0100 Organization: Philips Research X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Is Caml good for embedded systems? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; philips:99 caml-list:01 basile:01 2004:99 philips:99 experimented:01 embedding:01 obstacle:01 floats:01 pointers:01 encodings:01 runtime:01 runtime:01 behave:01 kernel:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Basile Starynkevitch wrote: > > On Wed, Feb 04, 2004 at 02:28:20PM +0100, Leszek.Holenderski@philips.com wrote: > > > I wonder if anybody attempted to use Caml (or any of its variants) > > to program embedded systems? > > You didn't define what you mean by embedded systems... There are lots > of various definitions, and you didn't gave any (real or fictiuous) > examples, so we have to guess. I don't have any specific kind of embedded systems in mind. I was just probing, to check whether Caml could be advertised for embedded programming in Philips. Since Philips is involved in embedded systems of various kinds I didn't want to limit the subject. The simplest example would be video processing (say, digital TV and 3D TV). I've been promoting Caml for desktop programming for some time now (with rather modest results so far :) and I'd like to try another strategy to introduce Caml in Philips. > Some old version of Caml-light (not Ocaml) has been ported to some old > Palm PDA, IIRC. > > IIRC, someone experimented embedding Ocaml [or some Caml variant...?] > (using the bytecode interpreter) inside the Linux kernel. I'd prefer native code. Also, something lighter than Linux. > > The main obstacle, as I see it, is a rather poor arithmetic. It > > seems that the only directly supported numerical type is 31-bit > > integers. Everything else (floats, 32-bit integers, fixed-point > > integers) has to go via pointers. > > I'm not sure that the arithmetic is poor enough to be a problem in > practice (but YMMV). It is. In embedded programming you often (over)use various encodings, say packing 4 bytes (colour components) into one 32-bit word. > I see others potential issues > > 1. embedded systems usually are extremely tight on memory space, and > the runtime does take some space. Not necessarily. In video processing you often have access to 16, 32 or 64MB. > 2. The current runtime requires floating point (and also some IO > support) in the runtime - this can be worked around with some > work... Didn't know. This is serious. > 3. most importantly, embedded systems usually have significant real > time requirements, and the Ocaml garbage collector, even if it is very > performant, is not exactly realtime (and coding realtime GC is a > nightmare, and has important costs), but behave nicely even in > interactive usage. In most cases you can live with it. Hard real-time embedded applications are in fact not that common. And even then only a small part is critical, usually. > Still, I tend to believe that the current Ocaml is usable in embedded > systems, provided they are powerful enough (i.e. a 32bit CPU, with at > least 16Mb RAM... ie something which is not smaller than 10times less > my average desktop).... That's what I hope for, and that's why I'd be very interested to know if anybody has some evidence for this. Leszek --------------------------------------------------------------- Leszek Holenderski, Philips Research, The Netherlands ------------------- 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