Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Ville-Pertti Keinonen <will@exomi.com>
To: Jonathan Roewen <jonathan.roewen@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Using OCaml in a kernel
Date: Mon, 06 Dec 2004 10:09:12 +0200	[thread overview]
Message-ID: <1102320552.663.45.camel@localhost> (raw)
In-Reply-To: <ad8cfe7e04120516485e090a7f@mail.gmail.com>

On Mon, 2004-12-06 at 13:48 +1300, Jonathan Roewen wrote:

> I'm developing an operating system, and I want to write as much of it
> as possible in OCaml. I had hoped to use the ocamlopt compiler, and
> have it target i586-elf, like my gcc (3.4.1) cross-compiler. I'm using
> newlib with my cross-compiler, so I have a C library available.
> 
> However, I'm lost at how to get OCaml into the mix. Anyone able to
> offer some suggestions of the sorts of things I could try?

You should familiarize yourself with how OCaml works in detail before
you even start to plan the capabilities; it isn't going to "just work".
OCaml is going to place a lot of restrictions on what you can and can't
do (e.g. if you want to make the system pre-emptible, multithreaded or
SMP-capable you either need to make significant changes to the OCaml
runtime or exercise unusual discipline - no sharing of data except
through non-OCaml objects).

Note that you don't necessarily need to set up OCaml as a
cross-compiler.  The simplest way to start would probably be to use the
native OCaml compiler on your development platform (assuming it's also
i586-elf) to compile the OCaml parts.  The part you need to build
against newlib is the OCaml runtime (libasmrun.a) - you can do that
manually.  You can then use the -output-obj option of ocamlopt to
produce a single OCaml object, which you can link against your C
objects, newlib and your manually built libasmrun.a.

There are some changes that you're definitely going to want to make if
you're serious - rip out the signal handling and I/O altogether, modify
the memory allocation interfaces etc. - but if you have something
sufficiently functional that you can get newlib to build and work, then
you might be able to get started without doing these at first.



  parent reply	other threads:[~2004-12-06  8:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-06  0:48 Jonathan Roewen
2004-12-06  1:03 ` [Caml-list] " Sachin Shah
2004-12-06  8:09 ` Ville-Pertti Keinonen [this message]
2004-12-10 21:26   ` Jonathan Roewen
2004-12-10 23:00     ` Jacques Garrigue
2004-12-14  1:43       ` Jonathan Roewen
2004-12-14  9:09         ` Ville-Pertti Keinonen
2004-12-14 18:10           ` Jonathan Roewen
2004-12-15  2:03             ` skaller
2004-12-28 22:35       ` Jonathan Roewen
2004-12-06  9:08 ` Vincenzo Ciancia
2004-12-06 10:00 ` Frédéric Gava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1102320552.663.45.camel@localhost \
    --to=will@exomi.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jonathan.roewen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox