[Caml-list] native code toplevel

[Caml-list] native code toplevel

[Oleg]

Hi

I found the same question in the archives, but with no answers: why isn't 
there a native code toplevel? Sometimes I need high performance and 
interactivity (CMUCL can do it, why not O'Caml?)

Oleg

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

Re: [Caml-list] native code toplevel

[malc]

On Sat, 16 Nov 2002, Oleg wrote:

> Hi
> 
> I found the same question in the archives, but with no answers: why isn't 
> there a native code toplevel? Sometimes I need high performance and 
> interactivity (CMUCL can do it, why not O'Caml?)

Let's see. We have following obstacles:
a) Ocaml relies on external tools to generate native code (assembler, 
   linker)
b) Ocaml has no way to dynamically load .cmx or .cmxa

And here is a real show stoper - no way to pick suitable name for the 
executable, i mean, ocaml - toplevel, ocamlc - compiler, ocamlopt - 
"optimizing" compiler. Quite simply, there is no space for such a beast.

-- 
mailto:malc@pulsesoft.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

Re: [Caml-list] native code toplevel

[Oleg]

On Saturday 16 November 2002 06:16 pm, malc wrote:
> On Sat, 16 Nov 2002, Oleg wrote:
> > Hi
> >
> > I found the same question in the archives, but with no answers: why isn't
> > there a native code toplevel? Sometimes I need high performance and
> > interactivity (CMUCL can do it, why not O'Caml?)
>
> Let's see. We have following obstacles:
> a) Ocaml relies on external tools to generate native code (assembler,
>    linker)

It could call those external tools. Why not?

> b) Ocaml has no way to dynamically load .cmx or .cmxa

I don't know about other platforms, but Solaris and Linux have dlopen, dlsym 
and dlclose. Couldn't it use those?

> And here is a real show stoper - no way to pick suitable name for the
> executable, i mean, ocaml - toplevel, ocamlc - compiler, ocamlopt -
> "optimizing" compiler. Quite simply, there is no space for such a beast.

I would readily give up bytecode for native code. Alternatively, I would 
settle for pretty much any name.

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

Re: [Caml-list] native code toplevel

[Sven Luther]

On Sat, Nov 16, 2002 at 09:24:10PM -0500, Oleg wrote:
> On Saturday 16 November 2002 06:16 pm, malc wrote:
> > On Sat, 16 Nov 2002, Oleg wrote:
> > > Hi
> > >
> > > I found the same question in the archives, but with no answers: why isn't
> > > there a native code toplevel? Sometimes I need high performance and
> > > interactivity (CMUCL can do it, why not O'Caml?)
> >
> > Let's see. We have following obstacles:
> > a) Ocaml relies on external tools to generate native code (assembler,
> >    linker)
> 
> It could call those external tools. Why not?

Because you have to have them installed in order to use it, as well as
the ocamlopt compilers also.

> > b) Ocaml has no way to dynamically load .cmx or .cmxa
> 
> I don't know about other platforms, but Solaris and Linux have dlopen, dlsym 
> and dlclose. Couldn't it use those?
> 
> > And here is a real show stoper - no way to pick suitable name for the
> > executable, i mean, ocaml - toplevel, ocamlc - compiler, ocamlopt -
> > "optimizing" compiler. Quite simply, there is no space for such a beast.
> 
> I would readily give up bytecode for native code. Alternatively, I would 

Until you begin working on linux/hppa or linux/s390 for example, which has no
native code compiler.

Friendly,

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

Re: [Caml-list] native code toplevel

[Oleg]

On Sunday 17 November 2002 02:41 am, Sven Luther wrote:
> On Sat, Nov 16, 2002 at 09:24:10PM -0500, Oleg wrote:
> > On Saturday 16 November 2002 06:16 pm, malc wrote:
> > > On Sat, 16 Nov 2002, Oleg wrote:
> > > > Hi
> > > >
> > > > I found the same question in the archives, but with no answers: why
> > > > isn't there a native code toplevel? Sometimes I need high performance
> > > > and interactivity (CMUCL can do it, why not O'Caml?)
> > >
> > > Let's see. We have following obstacles:
> > > a) Ocaml relies on external tools to generate native code (assembler,
> > >    linker)
> >
> > It could call those external tools. Why not?
>
> Because you have to have them installed in order to use it, as well as
> the ocamlopt compilers also.

I have them installed.

> > > b) Ocaml has no way to dynamically load .cmx or .cmxa
> >
> > I don't know about other platforms, but Solaris and Linux have dlopen,
> > dlsym and dlclose. Couldn't it use those?
> >
> > > And here is a real show stoper - no way to pick suitable name for the
> > > executable, i mean, ocaml - toplevel, ocamlc - compiler, ocamlopt -
> > > "optimizing" compiler. Quite simply, there is no space for such a
> > > beast.
> >
> > I would readily give up bytecode for native code. Alternatively, I would
>
> Until you begin working on linux/hppa or linux/s390 for example, which has
> no native code compiler.

Why should a hypothetical possibility of working on an obscure system make me 
suffer now that I'm using Linux/x86?

So they don't have ocamlopt either. Does this mean I must not use it?

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

Re: [Caml-list] native code toplevel

[malc]

On Sat, 16 Nov 2002, Oleg wrote:

> On Saturday 16 November 2002 06:16 pm, malc wrote:
> > On Sat, 16 Nov 2002, Oleg wrote:
> > > Hi
> > >
> > > I found the same question in the archives, but with no answers: why isn't
> > > there a native code toplevel? Sometimes I need high performance and
> > > interactivity (CMUCL can do it, why not O'Caml?)
> >
> > Let's see. We have following obstacles:
> > a) Ocaml relies on external tools to generate native code (assembler,
> >    linker)
> 
> It could call those external tools. Why not?
Because its hell to implement?
 
> > b) Ocaml has no way to dynamically load .cmx or .cmxa
> 
> I don't know about other platforms, but Solaris and Linux have dlopen, dlsym 
> and dlclose. Couldn't it use those?
Plese take my word, its far more complicated than just calling dlfcn.h 
functions.

> 
> > And here is a real show stoper - no way to pick suitable name for the
> > executable, i mean, ocaml - toplevel, ocamlc - compiler, ocamlopt -
> > "optimizing" compiler. Quite simply, there is no space for such a beast.
> 
> I would readily give up bytecode for native code. Alternatively, I would 
> settle for pretty much any name.
Uh-oh

-- 
mailto:malc@pulsesoft.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

Re: [Caml-list] native code toplevel

[Stefano Zacchiroli]

On Sun, Nov 17, 2002 at 02:16:57AM +0300, malc wrote:
> b) Ocaml has no way to dynamically load .cmx or .cmxa

We have lived for a long time with ocamlmktop, we can also live with
building of native code toplevels.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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

Re: [Caml-list] native code toplevel

[Jacques Garrigue]

From: Stefano Zacchiroli <zack@cs.unibo.it>
> On Sun, Nov 17, 2002 at 02:16:57AM +0300, malc wrote:
> > b) Ocaml has no way to dynamically load .cmx or .cmxa
> 
> We have lived for a long time with ocamlmktop, we can also live with
> building of native code toplevels.

I have a strong feeling that what people are really asking for is the
ability to mix bytecode and native code.

The real difficulty with a native code toplevel is not to build the
toplevel itself, but the fact that every line you input to the
toplevel is a small program which must be dynamically compiled, linked
and run. With bytecode this is easy (a bit of meta glue), but with
pure native code this would be complicated and slow.  The ideal would
be to use native code libraries inside a toplevel compiling to
bytecode.

IIRC Fabrice le Feissant had some way to do it, by writing a bytecode
interpreter in ocaml itself, but I don't know how hard it would be to
adapt the toplevel to this approach (knowing that there is a fair bit
of magic in the way the toplevel links with itself).

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

Re: [Caml-list] native code toplevel

[Walid Taha]

On Mon, 18 Nov 2002, Jacques Garrigue wrote:

|From: Stefano Zacchiroli <zack@cs.unibo.it>
|> On Sun, Nov 17, 2002 at 02:16:57AM +0300, malc wrote:
|> > b) Ocaml has no way to dynamically load .cmx or .cmxa
|>
|> We have lived for a long time with ocamlmktop, we can also live with
|> building of native code toplevels.
|
|I have a strong feeling that what people are really asking for is the
|ability to mix bytecode and native code.
|
|The real difficulty with a native code toplevel is not to build the
|toplevel itself, but the fact that every line you input to the
|toplevel is a small program which must be dynamically compiled, linked
|and run. With bytecode this is easy (a bit of meta glue), but with
|pure native code this would be complicated and slow.  The ideal would
|be to use native code libraries inside a toplevel compiling to
|bytecode.
|
|IIRC Fabrice le Feissant had some way to do it, by writing a bytecode
|interpreter in ocaml itself, but I don't know how hard it would be to
|adapt the toplevel to this approach (knowing that there is a fair bit
|of magic in the way the toplevel links with itself).

I don't quite see how that could solve this problem, unless (native code
compiled) OCaml had multi-stage constructs like those of MetaOCaml.  But
MetaOCaml is currently only available in the bytecode form, because we
can't quite figure out how to call the compiler at runtime on a piece of
code that we've generated dynamicaly (which is the core problem you point
to in the paragraph above) *and* then load into the parent runtime.
Sure, calling the native code compiler at runtime expensive, but the
generated (native) code is also faster than the byte code.  It's a
tradeoff that I'd like the programmer to have access to.  If someone has
insights/experience calling the compiler at runtime and then loading the
generated code into the same runtime system, I would would be very
interested in hearing from them.

Walid.

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

Re: [Caml-list] native code toplevel

[Chris Hecker]

>generated (native) code is also faster than the byte code.

Asmdynlink (Fabrice's bytecode interpreter for native programs) has a JIT 
in it, that apparently "mostly works".  This is a good compromise for the 
speed problem, if it works.

You can search the list archives for more information (pros and cons) of 
asmdynlink, and posts related to mixing bytecode and native code.

Chris

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

Re: [Caml-list] native code toplevel

[Oliver Bandel]

Hi,

On Mon, Nov 18, 2002 at 08:59:58AM +0900, Jacques Garrigue wrote:
> From: Stefano Zacchiroli <zack@cs.unibo.it>
> > On Sun, Nov 17, 2002 at 02:16:57AM +0300, malc wrote:
> > > b) Ocaml has no way to dynamically load .cmx or .cmxa
> > 
> > We have lived for a long time with ocamlmktop, we can also live with
> > building of native code toplevels.
> 
> I have a strong feeling that what people are really asking for is the
> ability to mix bytecode and native code.
[...]

Yes, it would be good to load bytecode and native code
with a #load command from within the toplevel, even if
new code - entered from the toplevel - only will be
compiled to bytecode.

But as far as I experienced in my experiments (I tried
some things with ocamlnet, and the compilation does
not compile all libs to bytecode AND nativecode; some
files were compiled to bytecode, others to native code
and I didn't know, how to use this stuff and suspended
any Ocaml-action since then), it was not possible
to use native code from the toplevel.
No #require command has helped in loading native
code, and compilation failed, as I tried to mix
some of these libs.


Ciao,
   Oliver


P.S.: Now I'm exploring OpenGL, and I do it with C-Programming,
      because, when using Ocaml for this purpose (this is a
      common Ocaml-problem, not only related to OpenGL),
      you have to have the knowledge of using it (OpenGL,
      or any other similar library, like Tk-stuff or other
      things) with C!
      If you are not familiar with a library,
      you will not have good chances to start with it while
      starting with OCaml too: There are no books and there are
      no good documentations.
      That's a reason, why OCaml will be less used for longer
      time.
      If there would be books for using OCaml for often needed
      libraries (Ocaml, Tk, ...) or books on algorithms for
      OCaml (there are a lot of versions of "Numerical Recipes",
      but I did not heard of one for OCaml), then it would be
      more easy to see a way, when ocaml gets widespread,
      instead of ghosting around in ivory tower only.


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

[Caml-list] native code toplevel

[Basile STARYNKEVITCH]

>>>>> "Oleg" == Oleg  <oleg_inconnu@myrealbox.com> writes:

    Oleg> Hi I found the same question in the archives, but with no
    Oleg> answers: why isn't there a native code toplevel? Sometimes I
    Oleg> need high performance and interactivity (CMUCL can do it,
    Oleg> why not O'Caml?)

I also share the same wishes. And actually, the toplevel might
(suboptimally) dynamically translate the bytecode to machine code
(i.e. do Just In Time compilation).


There are tools, in particular Ian Piumarta's CCG (Ian Piumarta is
also at Inria but on another project) or GNU lightning tools that
could help.

CCG is a set of clever C macros to generate x86 (or Sparc) machine
code. Basically, with CCG you code in some kind of assembler syntax
which produces C code generating it. CCG is plateform specific.

Lightning uses CCG to abstract a RISC machine with few registers. You
code in this RISC machine and get a C code generating code for several
plateform.

The only tricky point is to get tail recursive calls compiled
properly.

Perhaps in a not-too-remote future Ocaml might generate C-- code (see
www.cminusminus.org) and the QuickC-- (coded in Ocaml) compiler might
generate machine code either in memory or in shared objects (.so
files) which could be opened with dlopen/dlclose/dlsym at runtime.

For information, the TCC compiler generate code in memory (on x86).

Of course there are several plateforms (ie Linux/s390 or Linux/HPPA)
which might not have these tools available.

References:

C-- = http://www.cminusminus.org/

Lightning = http://www.gnu.org/software/lightning/

TCC = http://fabrice.bellard.free.fr/tcc/

As a selfish x86 coder, I would be delighted with a JIT OCaml, and
even more with a library able to dynamically load code at runtime.


Regards.
-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
-------------------
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

Re: [Caml-list] native code toplevel

[Sven Luther]

On Sun, Nov 17, 2002 at 09:16:52AM +0100, Basile STARYNKEVITCH wrote:
> >>>>> "Oleg" == Oleg  <oleg_inconnu@myrealbox.com> writes:
> 
>     Oleg> Hi I found the same question in the archives, but with no
>     Oleg> answers: why isn't there a native code toplevel? Sometimes I
>     Oleg> need high performance and interactivity (CMUCL can do it,
>     Oleg> why not O'Caml?)
> 
> I also share the same wishes. And actually, the toplevel might
> (suboptimally) dynamically translate the bytecode to machine code
> (i.e. do Just In Time compilation).

I think the last time this subject came up on the list, it was said that
the bytecode does not contain as much information as is needed by the
native code compiler, in particular, i think the bytecode does not
contain any kind of type information.

That said, i guess you could store some kind of intermediary
representation instead, and compile from that, but it is worth it ?

Friendly,

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