Re: [Caml-list] Native compiler support for m68k?

Re: [Caml-list] Native compiler support for m68k?

[Xavier Leroy]

> I recently got interested into OCaml and thought about
> resurrecting the native m68k compiler for m68k, is the old
> bitrotten code available somewhere?

Yes, you can find it in release 2.04 (the last stable release before
m68k support was deprecated):
http://caml.inria.fr/distrib/ocaml-2.04/ocaml-2.04.tar.gz

Have fun,

- Xavier Leroy

-------------------
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 compiler support for m68k?

[Gleb N. Semenov]

Xavier Leroy wrote:
> 
> > I recently got interested into OCaml and thought about
> > resurrecting the native m68k compiler for m68k, is the old
> > bitrotten code available somewhere?
> 
> Yes, you can find it in release 2.04 (the last stable release before
> m68k support was deprecated):
> http://caml.inria.fr/distrib/ocaml-2.04/ocaml-2.04.tar.gz
> 
> Have fun,
> 
> - Xavier Leroy
> 

In such case what about ocaml port for palm pilot?

Regards!
GNS


-- 
Gleb N. Semenov		111621, Muromskaya St. 21, apt. 2, Moscow, Russia 
gleb@ahome.ru        	phone: +7(095)700.0172

-------------------
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 compiler support for m68k?

[Xavier Leroy]

> In such case what about ocaml port for palm pilot?

François Rouaix did a Palm port of Caml Light (the "lean and mean"
ancestor of OCaml) a long time ago.  

The main problem was that the data segment of a Palm OS program had to
fit in 64K, which is quite tight for Caml Light and definitely not
enough for OCaml.  (The remainder of the RAM was either read-only code
blocks, or PalmOS "databases" that must be accessed through system calls.)
I don't know if this limitation was lifted in later versions of PalmOS.

Problem number 2 is that text-only apps aren't very usable on a
handheld, so you'd need to interface a large chunk of the GUI toolkit.

- Xavier Leroy

-------------------
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 compiler support for m68k?

[Daniel M. Albro]

	It is doable, though.  Look at LispMe (http://www.lispme.de), a
Scheme interpreter for PalmOS.  The author got around the memory 
problems by finding a way to use databases as the memory space of the 
interpreter.  Also, the newer ARM-based Palm devices should have fewer 
limitations.  Moreover, since the LispMe source is available, most 
likely any GUI code you wanted could be lifted from that.  I'm not 
volunteering, of course, but I think it would be doable (I've looked at 
the problem in connection with thinking about writing a Prolog 
interpreter for PalmOS).

							- Dan Albro

Xavier Leroy wrote:

>>In such case what about ocaml port for palm pilot?
> 
> 
> François Rouaix did a Palm port of Caml Light (the "lean and mean"
> ancestor of OCaml) a long time ago.  
> 
> The main problem was that the data segment of a Palm OS program had to
> fit in 64K, which is quite tight for Caml Light and definitely not
> enough for OCaml.  (The remainder of the RAM was either read-only code
> blocks, or PalmOS "databases" that must be accessed through system calls.)
> I don't know if this limitation was lifted in later versions of PalmOS.
> 
> Problem number 2 is that text-only apps aren't very usable on a
> handheld, so you'd need to interface a large chunk of the GUI toolkit.
> 
> - Xavier Leroy
> 
> -------------------
> 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
> 

-------------------
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 compiler support for m68k?

[Richard Zidlicky]

On Wed, Aug 20, 2003 at 02:32:38PM +0200, Xavier Leroy wrote:
> > I recently got interested into OCaml and thought about
> > resurrecting the native m68k compiler for m68k, is the old
> > bitrotten code available somewhere?
> 
> Yes, you can find it in release 2.04 (the last stable release before
> m68k support was deprecated):
> http://caml.inria.fr/distrib/ocaml-2.04/ocaml-2.04.tar.gz

ok, I got 2.0.4 working for m68k-linux, not very hard.
Speed is quite impressive, fib is faster than gcc code ?!

One thing that I need to verify is the interaction of the native
compiler and the strange m68k-linux ABI which is different from
SUN or BSD. The unusual part of m68k-linux ABI is that functions
returning pointer return their value in register a0, while integer
types are retuned in d0.

How does the code generated by the native compiler interact
with c-ABI functions?

Richard

-------------------
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 compiler support for m68k?

[Xavier Leroy]

> ok, I got 2.0.4 working for m68k-linux, not very hard.
> Speed is quite impressive, fib is faster than gcc code ?!

Sure: gcc passes all parameters on the stack, ocamlopt passes the
first ones in registers.

> One thing that I need to verify is the interaction of the native
> compiler and the strange m68k-linux ABI which is different from
> SUN or BSD. The unusual part of m68k-linux ABI is that functions
> returning pointer return their value in register a0, while integer
> types are retuned in d0.
> 
> How does the code generated by the native compiler interact
> with c-ABI functions?

C functions that can be called by Caml code must be declared with
return type "value", which is "long".  So, the C compiler will arrange
for the result to be in D0, which is where ocamlopt-generated code
expects to find it.

- Xavier Leroy

-------------------
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 compiler support for m68k?

[Richard Zidlicky]

Hi,

a short update, adapting to 3.06 was not very difficult but
somehow triggered a few bugs in the code.

Simple examples like "fib" work fine, ocamlc.opt crashes in
parsing/linenum.ml so I am slowly adding debugging support to
code generation to find out details.

One of the bugs had to do with register reloading, pseudos
that was allocated hard register in previous version ended
up as stack slots (somehow a0 often isn't used for allocation
where it previously was). Emitting code didn't take this
possibility into account in some places generating assembly
code.. most likely the register constraints aren't good enough.

Does anyone have a test suite? What kind of problems had other
architectures between 2.04 and 3.06?

Richard

-------------------
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 compiler support for m68k?

[Richard Zidlicky]

Hi,

I have had some progress recently, ocamlc.opt works and
even produces working code now.

The remaining problem is a bit tougher though, not quite
deterministic it appears: running 
	./ocamlopt.opt -I stdlib fib.ml
segfaults in either 
  Queue__take_87
  Cmmgen__transl_all_functions_1418
*or*
  Reload__fundecl_338
  Asmgen__regalloc_175

80% of the time it crashes in fundecl.

What could be the source of such indeterministic behaviour?
gc?

Richard

-------------------
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 compiler support for m68k?

[Byron Hale]

Processor overheating could cause random behavior. Apparently some 
processors operate marginally and will overheat on long, tight loops.

Byron

At 11:58 PM 9/5/2003 +0200, you wrote:
>Hi,
>
>I have had some progress recently, ocamlc.opt works and
>even produces working code now.
>
>The remaining problem is a bit tougher though, not quite
>deterministic it appears: running
>     ./ocamlopt.opt -I stdlib fib.ml
>segfaults in either
>   Queue__take_87
>   Cmmgen__transl_all_functions_1418
>*or*
>   Reload__fundecl_338
>   Asmgen__regalloc_175
>
>80% of the time it crashes in fundecl.
>
>What could be the source of such indeterministic behaviour?
>gc?
>
>Richard


-------------------
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 compiler support for m68k?

[Benjamin Geer]

Richard Zidlicky wrote:
> What could be the source of such indeterministic behaviour?

There's some useful information here on how to find out whether you have 
a hardware problem:

http://www-106.ibm.com/developerworks/library/l-hw1/
http://www.bitwizard.nl/sig11/

Ben

-------------------
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 compiler support for m68k?

[David MENTRE]

Richard Zidlicky <rz@linux-m68k.org> writes:

> What could be the source of such indeterministic behaviour?
> gc?

I would guess it is related to GC or bad memory allocation (in case of C
code).

As far as I remember, OCaml GC is using usual libc malloc and free, so
you could activate libc checks to help find the bug (see mcheck(), there
is also an environment variable I don't remember). You could also take a
look at libefence.

Other things that might help is to zeroing data structures before
releasing them to free(). Sometimes, you reuse a datastructure that is
has been freed.

To make the port, what have you modified? Only Caml code or also C code?

My .2 euros,
Yours,
d.
-- 
 David Mentré <dmentre@linux-france.org>
   http://www.linux-france.org/~dmentre/david-mentre-public-key.asc
 GnuPG key fingerprint: A7CD 7357 3EC4 1163 745B  7FD3 FB3E AD7C 2A18 BE9E

-------------------
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 compiler support for m68k?

[Damien Doligez]

On Friday, September 5, 2003, at 11:58 PM, Richard Zidlicky wrote:

> What could be the source of such indeterministic behaviour?

There is at least one source of nondeterminism in the compiler:
the generation of temporary file names.  And it can be influenced
by the contents of the /tmp directory, especially when a previous
compiler run has crashed and left its temporary files there...
There may be other sources of nondeterminism, but I can't think
of any off the top of my head.

> gc?

No, the GC is completely deterministic (thank God).

-- Damien

-------------------
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] GC Question

[Christophe Raffalli]

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


in the following kind code :

let l = ... a function building a long list ... in
let l' = List.map fn l in (* or fold or anything similar *)
... no more reference to l ...

Once the beginning of l has been read to compute l' (assuming List.map 
starts from the beginning of l) is the GC able to collect the beginning 
of l ?

If not how to write the code to ensure this behaviour of the GC ?


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] GC Question

[Pierre Weis]

> in the following kind code :
> 
> let l = ... a function building a long list ... in
> let l' = List.map fn l in (* or fold or anything similar *)
> ... no more reference to l ...
> 
> Once the beginning of l has been read to compute l' (assuming List.map 
> starts from the beginning of l) is the GC able to collect the beginning 
> of l ?

No it cannot since, AFAIK, l is not freed (i.e. assigned to 0) into
the stack (or local environment) before you leave the block where your
code occurs (normally the activation block of the function where it
appears in).

> If not how to write the code to ensure this behaviour of the GC ?
>
> Christophe Raffalli

Do not use let bindings, write function applications or function
compositions instead.
 (Instead of writing
  let l1 = f l0 in
  let l2 = g l1 in
  h l2
  write
  let i l = h (g (f l)) in
  i l0)

Alternatively, use explicit references to lists and free them
explicitely in your code ! This is tractable when the flow of control
of the code is simple enough (for instance in the case of a
clear succession of passes where data from previous passes are clearly
unused in the following steps).

Hope this helps,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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] GC Question

[Christophe Raffalli]

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

Pierre Weis wrote:
>>in the following kind code :
>>
>>let l = ... a function building a long list ... in
>>let l' = List.map fn l in (* or fold or anything similar *)
>>... no more reference to l ...
>>
>>Once the beginning of l has been read to compute l' (assuming List.map 
>>starts from the beginning of l) is the GC able to collect the beginning 
>>of l ?

And

let l' =
   let l = ...   a function building a long list ... in
   List.map fn l
in

should work then (it is simpler to read than composition) ?


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] GC Question

[Xavier Leroy]

> in the following kind code :
> 
> let l = ... a function building a long list ... in
> let l' = List.map fn l in (* or fold or anything similar *)
> ... no more reference to l ...
> 
> Once the beginning of l has been read to compute l' (assuming List.map 
> starts from the beginning of l) is the GC able to collect the beginning 
> of l ?

Short answer: with ocamlc, no.  With ocamlopt, yes.

Longer answer: in the bytecoded implementation, every value in the VM
stack is a GC root.  "let x = e in e'" pushes the value of e on the
stack just before evaluating e', and pops it at the end of e'.  So,
the value of e remains a live GC root throughout the evaluation of e'.

In the native-code implementation, not all machine stack entries are
GC roots, but only the stack slots that hold a variable of type
address that is live at the point where the GC is called.  ("Live"
here is in the sense of liveness analysis of local variables.)
In your example, "l" is not live across the call to "List.map fn l".

> If not how to write the code to ensure this behaviour of the GC ?

As other mentioned, removing the outer "let" gives the desired GC
behavior even in bytecode:

        List.map fn l (... list builder ...)

In the OCaml sources, you can find this strange-looking idiom:

      let (++) x f = f x

      Pparse.file ppf inputfile Parse.implementation ast_impl_magic_number
      ++ print_if ppf Clflags.dump_parsetree Printast.implementation
      ++ Typemod.type_implementation sourcefile prefixname modulename env
      ++ Translmod.transl_implementation modulename
      ++ print_if ppf Clflags.dump_rawlambda Printlambda.lambda
      ++ Simplif.simplify_lambda
      ++ print_if ppf Clflags.dump_lambda Printlambda.lambda
      ++ Bytegen.compile_implementation modulename
      ++ print_if ppf Clflags.dump_instr Printinstr.instrlist
      ++ Emitcode.to_file oc modulename;

which is a nicer way of writing

      Emitcode.to_file oc modulename
        (print_if ....
          (Bytegen.compile_implementation ...
             (print_if ...
                (...
                ))))

and gives better GC behavior than the obvious:

      let x1 = Pparse.file ppf inputfile Parse.implementation ast_impl_magic_number in
      let x2 = print_if ppf Clflags.dump_parsetree Printast.implementation p x1 in
      let x3 = Typemod.type_implementation sourcefile prefixname modulename env x2 in
      ...

- Xavier Leroy

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

GC question

[dmitry grebeniuk]

Hello, caml-list.

  I have some objects (custom blocks with method suite attached)
which can be referenced from caml heap.  How to ensure that
finalisation function is called for all non-referenced objects?
I know, call to caml_gc_full_major(Val_unit) will do this work,
but it can be costly when there are many values on the heap
(or not?).  Are there any quicker solution?  (I can make no
assumptions about "age" (young/old) of allocated custom blocks
and about current GC state)

-- 
WBR,
 dmitry                          mailto:gds-mlsts@moldavcable.com

Re: [Caml-list] GC question

[Jean-Christophe Filliatre]

dmitry grebeniuk writes:
 > 
 >   I have some objects (custom blocks with method suite attached)
 > which can be referenced from caml heap.  How to ensure that
 > finalisation function is called for all non-referenced objects?
 > I know, call to caml_gc_full_major(Val_unit) will do this work,
 > but it can be costly when there are many values on the heap
 > (or not?).  Are there any quicker solution?  (I can make no
 > assumptions about "age" (young/old) of allocated custom blocks
 > and about current GC state)

The two integer parameters "used" and "max" passed to alloc_custom are
controlling how fast the custom blocks are reclaimed by the GC, as
explained in section 18.9.2 of the manual
(see http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html).

I don't think that calling caml_gc_full_major by yourself is a good
idea. You should trust the GC; it will eventually reclaim any block
that is not referenced anymore.

Hope this helps,
-- 
Jean-Christophe

GC question.

[MATTHEW HAMMER]

Is there more documentation on the stuff in the Obj module?
What I see/know-about is here:

  http://caml.inria.fr/pub/docs/manual-ocaml/libref/Obj.html

I'm very interested in getting (write) access to GC-information on
ocaml values.

Thanks,
Matt

On Mon, Oct 24, 2005 at 05:51:54PM +0900, Keiko Nakata wrote:
> Hello.
> 
> Why I cannot have *any types* in signatures of functor arguments?
> Concretely, the following F is not typable.
> 
> module F(X:sig type t = [`A of _ ] val f : t -> int end) = 
>   struct
>     let f = function `A x as a -> X.f a | `B -> 0
>   end
> 
> The above F could be made typable as in
> 
> module F(X:sig type s type t = [`A of s ] val f : t -> int end) = 
>   struct
>     let f = function `A x as a -> X.f a | `B -> 0
>   end
> 
> However, this change requires me to add the type component s
> to every module to which F are going to be applied.
> This is not very nice...
> 
> Regards,
> Keiko Nakata
> 
> 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] GC question.

[Damien Doligez]

On Oct 24, 2005, at 19:53, MATTHEW HAMMER wrote:

> Is there more documentation on the stuff in the Obj module?
> What I see/know-about is here:
>
>   http://caml.inria.fr/pub/docs/manual-ocaml/libref/Obj.html
>
> I'm very interested in getting (write) access to GC-information on
> ocaml values.

What kind of GC information do you want to modify?

-- Damien

Re: [Caml-list] GC question.

[MATTHEW HAMMER]

I'm not certain what style of garbage collection is done in the ocaml
runtime environment, but if its generational for example, I'd like to
move certain values into the 'oldest' generation, so that the garbage
collector doesn't waste time on them.

The running program in question has a large datastructure that is very
persistent which takes a lot of GC time if it is transversed too
often.

So I suppose what I'm asking is: is there a way to give the GC'er
'hints' through the Obj module, or any other method?

Thanks,
Matt

On Tue, Oct 25, 2005 at 08:41:34PM +0200, Damien Doligez wrote:
> 
> On Oct 24, 2005, at 19:53, MATTHEW HAMMER wrote:
> 
> >Is there more documentation on the stuff in the Obj module?
> >What I see/know-about is here:
> >
> >  http://caml.inria.fr/pub/docs/manual-ocaml/libref/Obj.html
> >
> >I'm very interested in getting (write) access to GC-information on
> >ocaml values.
> 
> What kind of GC information do you want to modify?
> 
> -- Damien
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] GC question.

[Damien Doligez]

On Oct 25, 2005, at 21:20, MATTHEW HAMMER wrote:

> I'm not certain what style of garbage collection is done in the ocaml
> runtime environment,

Generational with two generations, and incremental for the old
generation.

> but if its generational for example, I'd like to
> move certain values into the 'oldest' generation, so that the garbage
> collector doesn't waste time on them.

The only way to do that is to call Gc.minor, but it won't save any time.

> The running program in question has a large datastructure that is very
> persistent which takes a lot of GC time if it is transversed too
> often.

If it's large, it's going to be in the major heap anyway.  If you
don't want the GC to traverse it, you'll have to put it outside the
heap, but it might will require a lot of work.  For example, bigarrays
are outside the heap.  Or you could write some C code to build your
structure out of malloc blocks, but I'd count that as a desperate
measure.

> So I suppose what I'm asking is: is there a way to give the GC'er
> 'hints' through the Obj module, or any other method?

You can control some parameters with the Gc module, but there's
no way to give hints about a specific piece of data.

-- Damien