[Caml-list] Ocaml on an embedded arm system (no linux)

[Caml-list] Ocaml on an embedded arm system (no linux)

[Dwight Schauer]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1887 bytes --]

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Am Freitag, den 20.09.2013, 09:13 -0500 schrieb Dwight Schauer:

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

I hope this isn't a typo. 196 KB RAM is way too low to even run a hello
world program. The predecessor of ocaml, caml-light, needed 640K at
minimum for running it on DOS, and that was 16 bit code. Ocaml is a lot
larger, and generates less dense 32 bit code.

For a very small app on bare metal, I think you need at least 4-8 MB of
memory. For making you happy, calculate 64 MB. I cannot say much about
the split flash mem vs. RAM - but you should take into account that the
representation of values isn't optimized for compactness, and you also
need extra RAM to give the garbage collector room.

Maybe it is possible to lower the memory requirements by modifying the
ocaml runtime (e.g. make the bytecode more compact at the cost of extra
decoding steps, remove unneeded parts like the compactor, ...), but I
doubt you'll be able to hit the mentioned limits.

Gerd


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

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Dwight Schauer]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

No, the Flash/RAM sizes I mentioned are not a typo.

OCaPIC is a similar OCaml project for PIC microntrollers.
http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC:OCAPIC

The microcontrollers targetted by OCaPIC have the following characteristics:
  RAM memory: a few kB.
  Flash memory: a few tens of kB.
  Clock: a few MHz

The ARM microcontrollers I'm looking to target are much bigger than PIC
microcontrollers on all 3 of those counts are significantly larger.



On Fri, Sep 20, 2013 at 10:54 AM, Gerd Stolpmann <info@gerd-stolpmann.de>wrote:

> Am Freitag, den 20.09.2013, 09:13 -0500 schrieb Dwight Schauer:
>
> > 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)
>
> I hope this isn't a typo. 196 KB RAM is way too low to even run a hello
> world program. The predecessor of ocaml, caml-light, needed 640K at
> minimum for running it on DOS, and that was 16 bit code. Ocaml is a lot
> larger, and generates less dense 32 bit code.
>
> For a very small app on bare metal, I think you need at least 4-8 MB of
> memory. For making you happy, calculate 64 MB. I cannot say much about
> the split flash mem vs. RAM - but you should take into account that the
> representation of values isn't optimized for compactness, and you also
> need extra RAM to give the garbage collector room.
>
> Maybe it is possible to lower the memory requirements by modifying the
> ocaml runtime (e.g. make the bytecode more compact at the cost of extra
> decoding steps, remove unneeded parts like the compactor, ...), but I
> doubt you'll be able to hit the mentioned limits.
>
> Gerd
>
>
> >
> >
> > 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
> >
> >
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> Creator of GODI and camlcity.org.
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>

[-- Attachment #2: Type: text/html, Size: 3495 bytes --]

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]

Am Freitag, den 20.09.2013, 11:19 -0500 schrieb Dwight Schauer:
> No, the Flash/RAM sizes I mentioned are not a typo.
> 
> 
> OCaPIC is a similar OCaml project for PIC microntrollers.
> http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC:OCAPIC
> 
> 
> The microcontrollers targetted by OCaPIC have the following
> characteristics:
>   RAM memory: a few kB.
>   Flash memory: a few tens of kB.
>   Clock: a few MHz
> 
> 
> The ARM microcontrollers I'm looking to target are much bigger than
> PIC microcontrollers on all 3 of those counts are significantly
> larger.

Just looked at the slides. They implemented a lot of things to increase
the compactness (bytecode compression, 16 bit integers and pointers, a
simple stop-and-copy GC, a utility to remove dead code, ...). This is
essentially a complete port of ocaml to a new architecture, with heavy
modification of the runtime. At the end, it is possible to run programs
with a few hundred lines of code (which is really impressive). You
cannot run the toploop shell.

What you could do, of course, it to port OcaPIC to ARM (well, there is
some assembly code, but not that much). But this doesn't give you a
toploop, probably not even dynamic loading of bytecode.

I really wonder what makes these very small devices so interesting as
platform for OCaml (other than, of course, having fun to run some code
in the favorite language there).

Gerd



> 
> 
> 
> 
> 
> On Fri, Sep 20, 2013 at 10:54 AM, Gerd Stolpmann
> <info@gerd-stolpmann.de> wrote:
>         Am Freitag, den 20.09.2013, 09:13 -0500 schrieb Dwight
>         Schauer:
>         
>         > 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)
>         
>         
>         I hope this isn't a typo. 196 KB RAM is way too low to even
>         run a hello
>         world program. The predecessor of ocaml, caml-light, needed
>         640K at
>         minimum for running it on DOS, and that was 16 bit code. Ocaml
>         is a lot
>         larger, and generates less dense 32 bit code.
>         
>         For a very small app on bare metal, I think you need at least
>         4-8 MB of
>         memory. For making you happy, calculate 64 MB. I cannot say
>         much about
>         the split flash mem vs. RAM - but you should take into account
>         that the
>         representation of values isn't optimized for compactness, and
>         you also
>         need extra RAM to give the garbage collector room.
>         
>         Maybe it is possible to lower the memory requirements by
>         modifying the
>         ocaml runtime (e.g. make the bytecode more compact at the cost
>         of extra
>         decoding steps, remove unneeded parts like the
>         compactor, ...), but I
>         doubt you'll be able to hit the mentioned limits.
>         
>         Gerd
>         
>         
>         >
>         >
>         > 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
>         >
>         >
>         
>         
>         --
>         ------------------------------------------------------------
>         Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>         Creator of GODI and camlcity.org.
>         Contact details:        http://www.camlcity.org/contact.html
>         Company homepage:       http://www.gerd-stolpmann.de
>         ------------------------------------------------------------
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Jonathan Kimmitt]

It is perfectly possible to run OCAML on an ARM with 196K of memory. For this
purpose the code density will only be a bit worse than a C compiler for the
same complexity of algorithm. The ocapic distribution achieves some of its
savings by using primitives that access the hardware directly. So this saves
quite a bit in library code. However what you propose to do is to implement
the bytecode toplevel on the ARM. This can not be done with less than about 2
megs of RAM, and some features would have to be left out. The primary
functions that need the space are to do with parsing and compiling your input
to bytecode and linking it incrementally with the provided libraries, all of
which takes significant space. If you want something non-trivial to run you
need to allow decent amounts of space for heap objects and garbage collection
efficiency.

If you only want a fixed program to run this is more realistic for 192K and in
theory the Ocaml code could be flashed. You still need to tweak things I would
guess if the garbage collector has to work in 196K or potentially 20K. If you
use native code generation the interpreter can be omitted which will save
quite a bit. Be prepared to write the vast of libraries yourself such as
anything to do with I/O. Standard libraries for list manipulation would not
need to be changed. A certain style of OCaml when written will save you quite
a bit of memory, especially if you use it to write device drivers and such
like where it is important not to continually allocate objects.

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Goswin von Brederlow]

On Fri, Sep 20, 2013 at 09:13:26AM -0500, Dwight Schauer wrote:
> Hi,
> 
> I'm looking at the feasibility of targetting a couple ARM processeors in a
> similar manner to ocapic at its core.
>... 
> 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

I'm looking at the same, but for seriously different specs.

My interest would be to run ocaml apps on a Raspberry PI baremetal.
Basically what openmirage does for the cloud (x86 VMs) but for
Raspberry PI and similar dimensioned arm boards.

So targets would be ARMv6 / ARMv7 cpus with 128MB - 2GB ram, USB,
HDMI, ethernet (often via USB), serial and an SD card.

I'm familiar with the hardware side, how to boot, how to initialize
the devices, how to get a picture to show on the HDMI and so on. What
I lack is knowledge in creating a new runtime library for ocaml that
runs directly on the hardware, or with just a verry thin hardware
abstraction layer.

Any pointers for how to do that?

MfG
	Goswin

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Anil Madhavapeddy]

On 23 Sep 2013, at 08:30, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> On Fri, Sep 20, 2013 at 09:13:26AM -0500, Dwight Schauer wrote:
>> Hi,
>> 
>> I'm looking at the feasibility of targetting a couple ARM processeors in a
>> similar manner to ocapic at its core.
>> ... 
>> 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
> 
> I'm looking at the same, but for seriously different specs.
> 
> My interest would be to run ocaml apps on a Raspberry PI baremetal.
> Basically what openmirage does for the cloud (x86 VMs) but for
> Raspberry PI and similar dimensioned arm boards.

Mirage is just a collection of libraries that implement useful
kernel functionality (e.g. a TCP/IP stack), so you can quite easily
retarget it to bare metal rPis with a suitable mini operating system.

There are several such available (or just start from uBoot), and
then get a basic console working to get some output.  Dave Scott
has written a VNC library in OCaml that's available from his Github,
so you could work on some framebuffer rasterization after that.

The essential approach is to start in small steps: get serial console
working, then basic timer integration, and then hook in higher level
libraries from those.

(We're working on a Xen/ARM Mirage backend at the moment, but only
because we can't be bothered to write all the physical device drivers
that an rPi would need -- I'd be happy to merge in a "bare-metal"
ARM backend for the rPi as well).

> I'm familiar with the hardware side, how to boot, how to initialize
> the devices, how to get a picture to show on the HDMI and so on. What
> I lack is knowledge in creating a new runtime library for ocaml that
> runs directly on the hardware, or with just a verry thin hardware
> abstraction layer.

You don't really need a new runtime library; just a barebones C library.
Gabor Pali has a variant of Mirage that compiles into a FreeBSD kernel
module, for example, which operates in a similar "baremetal" environment.

-anil

Re: [Caml-list] Ocaml on an embedded arm system (no linux)

[Goswin von Brederlow]

On Mon, Sep 23, 2013 at 05:10:12PM -0400, Anil Madhavapeddy wrote:
> (We're working on a Xen/ARM Mirage backend at the moment, but only
> because we can't be bothered to write all the physical device drivers
> that an rPi would need -- I'd be happy to merge in a "bare-metal"
> ARM backend for the rPi as well).

Url?

MfG
	Goswin