Re: [Caml-list] Ocaml and C--

Re: [Caml-list] Ocaml and C--

[David Gurr]

> I had many interesting discussions with Simon PJ and Norman Ramsey
> when they started to design their intermediate language.  Simon liked
> the name "C--" and kindly asked permission to re-use the name.

It is apparently very popular.  searching for C-- on google returns "about
52,000,000" pages.  But it is less popular than .net which returns
"about 122,000,000" pages or COM which is so popular google does not
even include in searches. -D
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml and C--

[Xavier Leroy]

> Supposing that QC-- will deliver it promises (but Norman Ramsey, Simon
> Peyton Jones and Christian Lindig are impressively serious and clever
> guys), will Ocaml switch to target C-- or will Ocaml continue to
> natively target the usual architectures (x86, Alpha, Sparc, ia64,
> x86-64...)?

The x86-64 generator is in the works, but not there yet -- mostly
because the hardware is not there yet either :-)

To answer your question, switching to C-- will be an option when C--
has code generators for all the platforms of interest for OCaml, and
is sufficiently better than the hand-written OCaml code generators
(e.g. in performance or portability).  OCaml is already at a stage
where it has decent code generators for many platforms, so the effort
of switching to a new framework must be compensated by other
advantages.

The situation is very different for new compilers, or existing
compilers that do not (yet) have good native-code generators; in this
case, C-- is a lot more interesting.

> What is the relation between C-- and Ocaml (apart a mutual respect of
> the leading developers in each team)?

I think I'm the one who coined the name "C--" to refer to a low-level,
weakly-typed intermediate code with operations corresponding roughly
to machine instructions, and minimal support for exact garbage
collection and exceptions.  See my POPL 1992 paper describing the
experimental Gallium compiler.  Such an intermediate code is still in
use in the ocamlopt compiler.

I had many interesting discussions with Simon PJ and Norman Ramsey
when they started to design their intermediate language.  Simon liked
the name "C--" and kindly asked permission to re-use the name.

However, C-- is more general than the intermediate code used by
ocamlopt, since it is designed to accommodate the needs of many source
languages, and present a clean, abstract interface to the GC and
run-time system.  The ocamlopt intermediate code is somewhat
specialized for the needs of Caml and for the particular GC we use.

At any rate, I think C-- is an excellent design and I wish the C--
team the best of luck in implementing and popularizing it.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml and C--

[reig]

Norman Ramsey wrote:
> 
>  > Supposing that QC-- will deliver it promises...
>  > will Ocaml switch to target C-- or will Ocaml continue to
>  > natively target the usual architectures (x86, Alpha, Sparc, ia64,
>  > x86-64...)?
> 
> It's way too early to ask anyone to make this decision, because C-- is
> a long way away from being good enough and reliable enough to support
> a production compiler.  Having said that, Fermin Reig has been doing
> some very interesting experiments with OCaml and C--, which I hope he
> will comment on here.

I have modified ocamlopt to emit C-- instead of Mach code (Mach is
ocamlopt's intermediate language of abstract machine
instructions). The C-- backend produces code that is slightly slower
than the native ocamlopt backend (alpha/linux). I have identified
several reasons for this slowdown:

1. Memory allocation.

ocamlopt combines several allocations in the same basic block into one
that requests a larger chunk of memory. This is done in the Mach
internal representation, so we lose this optimization in the C--
backend. OCaml programs contain many individual allocations and each
allocation translates into a conditional branch, which is not cheap in
modern RISC proessors.

2. Instruction scheduling

ocamlopt does better instruction scheduling inside basic blocks than
the C-- compiler.

3. Garbage collection

The C-- compiler reports GC roots to the garbage collector that may
not be live at the point of the collection (the collector is still
type-accurate, but not liveness-accurate). This prevents some garbage
from being reclaimed and can make each collection to take longer.

Other minor issues that may slowdown garbage collection (email me if
you want to know the details).

4. Exception handling

It's a little bit more costly via C--, but so little that it should go
unnoticed (though I haven't measured it).


Fermin

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml and C--

[Hao-yang Wang]

If you search on the ocaml source code with the string "C--", you will 
see that it is already used by ocamlopt. :-)

(Seriously, how closely this Cmm code corresponds to the proposed C--? 
Thanks.)

Hao-yang Wang
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml and C--

[Norman Ramsey]

 > Supposing that QC-- will deliver it promises...
 > will Ocaml switch to target C-- or will Ocaml continue to
 > natively target the usual architectures (x86, Alpha, Sparc, ia64,
 > x86-64...)?

It's way too early to ask anyone to make this decision, because C-- is
a long way away from being good enough and reliable enough to support
a production compiler.  Having said that, Fermin Reig has been doing
some very interesting experiments with OCaml and C--, which I hope he
will comment on here.


Norman
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Ocaml and C--

[STARYNKEVITCH Basile]

Hello All and particularily the core Ocaml team,

C-- (see "http://www.cminusminus.org/") is an effort to define a low
level langage (sort of portable assembler) -better than C- to be used
as a common target for (functional languages) compilers. C-- offers
things that are missing in C (notably tail recursion) and useful to
compiler implementors. QickC-- (qc--) is an opensource compiler from
C-- to machine code. Currently it is not yet completed but aims to
target several usual architectures (eg x86, Alpha, etc...). Qc-- will
probably be useable (according to their web page) at end of year 2001.

Qc-- is written -as a literate program- in Ocaml and I believe it is
(or will become) a good example of real useful Ocaml code.

I believe that there have beeen a proof of concept port of Ocaml to
target C--. Is it really so? 

Supposing that QC-- will deliver it promises (but Norman Ramsey, Simon
Peyton Jones and Christian Lindig are impressively serious and clever
guys), will Ocaml switch to target C-- or will Ocaml continue to
natively target the usual architectures (x86, Alpha, Sparc, ia64,
x86-64...)?

What is the relation between C-- and Ocaml (apart a mutual respect of
the leading developers in each team)?

Regards

N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile point Starynkevitch at wanadoo point fr 
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr