From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 2DC967EE49 for ; Fri, 20 Sep 2013 16:13:28 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dschauer@gmail.com) identity=pra; client-ip=209.85.212.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="dschauer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of dschauer@gmail.com designates 209.85.212.51 as permitted sender) identity=mailfrom; client-ip=209.85.212.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="dschauer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vb0-f51.google.com) identity=helo; client-ip=209.85.212.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="postmaster@mail-vb0-f51.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0BAM9WPFLRVdQzlGdsb2JhbABahBHCSwgWDgEBAQEHCwsJEiqCbAEbHgMSCQddAREBBQGIJwEDD5lEgwOMUYMHhB4KGScNZIkAAQUMk34DiTiORJANGCmEah4 X-IPAS-Result: Av0BAM9WPFLRVdQzlGdsb2JhbABahBHCSwgWDgEBAQEHCwsJEiqCbAEbHgMSCQddAREBBQGIJwEDD5lEgwOMUYMHhB4KGScNZIkAAQUMk34DiTiORJANGCmEah4 X-IronPort-AV: E=Sophos;i="4.90,944,1371074400"; d="scan'208";a="33702063" Received: from mail-vb0-f51.google.com ([209.85.212.51]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Sep 2013 16:13:26 +0200 Received: by mail-vb0-f51.google.com with SMTP id x16so315665vbf.38 for ; Fri, 20 Sep 2013 07:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KT995OcpZE9Z8cG22ZDVtw3b17jVk8NLTgOig8kd5do=; b=zlR7Jxr1gEO3yGXteGWvIsN5/e/FeUpPzdnP2y9Ce7W4piiTJhtpaB744CxgwhlKHb aDZFbA4nxp9MK/PRmKBBMF3YXwsAFjIgAFoRSwv6dbBdkiYsiqmnW2g3VUg3Mm9Y6gAI r4JmTLrp+GTB7ROQSZZMyxzmRs2j+806B52Kit4OM0BEX5i5O8wkcE2eLHYfKLZi/2P8 DqQTYBXNQnKv9Bqr8vJ1FuIhnUwStGDDIbFwxudlxF2LjezDbquDLHNChgOfTXCa359m cs6M8y9v2I9UjKQpRIdJJECU5/7LZz2efZi5gzrpyja8zHVY9xxygcndm4zXfUxkB9nj aP2g== MIME-Version: 1.0 X-Received: by 10.52.118.73 with SMTP id kk9mr5523930vdb.13.1379686406501; Fri, 20 Sep 2013 07:13:26 -0700 (PDT) Received: by 10.52.228.71 with HTTP; Fri, 20 Sep 2013 07:13:26 -0700 (PDT) Date: Fri, 20 Sep 2013 09:13:26 -0500 Message-ID: From: Dwight Schauer To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=089e0122f0f2293c9004e6d14630 Subject: [Caml-list] Ocaml on an embedded arm system (no linux) --089e0122f0f2293c9004e6d14630 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm looking at the feasibility of targetting a couple ARM processeors in a similar manner to ocapic at its core. What I'm looking to end up with is a bytecode interpreter running coopertatively multi-tasked ocaml apps, that I can feed in more bytecode at runtime (start a new task, replace an existing task, or interpret a bytecode sequence in an existing task.) The framework for this on the embedded target would be in C (not assembly). Ideally I'd also have a shell on the host development that I could used to interactively compile and interpret ocaml code running on the target. I would also like to crosscomple (including metacompilation) for the target on the host machine, where I could have a sources file that switch between host and target code to produce applications for the target. Ideally the shell on the host would have access to the same environment used for cross compilation. I have not used OCaml all that much, so I don't know yet how how difficult (or feasible) that this task would be. Since the bare metal framework of the embedded target would be in C, I would develop and test it first on the host system. (Linux on x86_64). The ARM processors I'm looking to target are: STM32F407ZGT6 ARM Cortex-M4, 1MB Flash, 196KB RAM (Has floating point) STM32F103RB ARM Cortex-M3, 128 KB Flash, 20K RAM (No floating point) On both I'd like to be able to run bytecode both out of Flash and RAM. (Primarily flash, but RAM for debugging). Speed is on overly important as long as I can control when the garbage collection is run (could be done in C in the multitasker?). Dwight --089e0122f0f2293c9004e6d14630 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I'm loo= king at the feasibility of targetting a couple ARM processeors in a similar= manner to ocapic at its core.

What I'm looking to end up with i= s a bytecode interpreter running coopertatively multi-tasked ocaml apps, th= at I can feed in more bytecode at runtime (start a new task, replace an exi= sting task, or interpret a bytecode sequence in an existing task.) The fram= ework for this on the embedded target would be in C (not assembly).

Ideally I'd also have a shell on the host development that I = could used to interactively compile and interpret ocaml code running on the= target.

I would also like to crosscomple (including metacompi= lation) for the target on the host machine, where I could have a sources fi= le that switch between host and target code to produce applications for the= target.

Ideally the shell on the host would have access to the same envir= onment used for cross compilation.

I have not used OCaml all t= hat much, so I don't know yet how how difficult (or feasible) that this= task would be.

Since the bare metal framework of the embedded target would = be in C, I would develop and test it first on the host system. (Linux on x8= 6_64).


The ARM processors I'm looking = to target are:
STM32F407ZGT6 ARM Cortex-M4, 1MB Flash, 196KB RAM (Has floating point)
S= TM32F103RB ARM Cortex-M3, 128 KB Flash, 20K RAM (No floating point)

On both I'd like to be able to run bytecode both = out of Flash and RAM. (Primarily flash, but RAM for debugging).

Speed is on overly important as long as I can control when t= he garbage collection is run (could be done in C in the multitasker?).
<= /div>

Dwight

--089e0122f0f2293c9004e6d14630--