Caml on intel-OSX

Caml on intel-OSX

[John Skaller]

A friend of mine reports he can't build Ocaml on one of those
new Mac machines running Intel processor.

However, he also reports:

> Luckily, I found a binary
> distro of ocaml for powerpc os x and installed that (it runs in an emulation
> layer). 

which is kind of funny.. he's running a bytecode version of the
Felix compiler on an Intel OSX system under an emulator to generate
C++ code which is compiled natively by gcc to produce 
an OSX/Intel binary .. :)

Anyone know about existing or planned support for OSX/Intel?

And a dumb question .. will a bytecode Ocaml program
just run on any machine provided a single binary,
ocamlrun, is installed and accessible?

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Agustín Valverde]

Hi

Perhaps, Steven Jobs can answer you :-)   http://www.apple.com/ 
quicktime/qtv/wwdc05/

Here is the news about the transition of apple to intel chips.   
http://www.macworld.com/news/2005/06/06/powerpcintel/index.php

Agustín

> A friend of mine reports he can't build Ocaml on one of those
> new Mac machines running Intel processor.
>
> However, he also reports:
>
>
>> Luckily, I found a binary
>> distro of ocaml for powerpc os x and installed that (it runs in an  
>> emulation
>> layer).
>>
>
> which is kind of funny.. he's running a bytecode version of the
> Felix compiler on an Intel OSX system under an emulator to generate
> C++ code which is compiled natively by gcc to produce
> an OSX/Intel binary .. :)
>
> Anyone know about existing or planned support for OSX/Intel?
>
> And a dumb question .. will a bytecode Ocaml program
> just run on any machine provided a single binary,
> ocamlrun, is installed and accessible?

Re: [Caml-list] Caml on intel-OSX

[james woodyatt]

On 08 Jun 2005, at 22:33, John Skaller wrote:
>
> And a dumb question .. will a bytecode Ocaml program
> just run on any machine provided a single binary,
> ocamlrun, is installed and accessible?

You probably want all the ocaml tools to be built as universal binaries 
and you probably also want the ocamlopt compiler to be able to produce 
universal binaries.  I would expect that will require some effort from 
the Caml Team at INRIA.

I wouldn't get impatient just yet.  Even inside Apple, most of the 
software engineers don't have Intel development machines.  The first 
Intel CPU Macintosh products won't be on the market until sometime 
around Q2 next year, and even then, the PowerPC machines will probably 
still be the high throughput hotness machines.  There's plenny time to 
spare.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Thu, 2005-06-09 at 07:00 -0700, james woodyatt wrote:
> On 08 Jun 2005, at 22:33, John Skaller wrote:
> >
> > And a dumb question .. will a bytecode Ocaml program
> > just run on any machine provided a single binary,
> > ocamlrun, is installed and accessible?
> 
> You probably want all the ocaml tools to be built as universal binaries 
> and you probably also want the ocamlopt compiler to be able to produce 
> universal binaries.  I would expect that will require some effort from 
> the Caml Team at INRIA.

Lol! no, it is a simple question. Can I make a bytecode program
and just ship it an expect it to run? No. So what else is required?

>  Even inside Apple, most of the 
> software engineers don't have Intel development machines. 

My friend is in San Francisco right now and does.
It was he that asked "Why not have a bytecode version
of the Felix compiler, so we don't have to install
Ocaml on every platform?"

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[padiolea]

> On Thu, 2005-06-09 at 07:00 -0700, james woodyatt wrote:
>> On 08 Jun 2005, at 22:33, John Skaller wrote:
>> >
>> > And a dumb question .. will a bytecode Ocaml program
>> > just run on any machine provided a single binary,
>> > ocamlrun, is installed and accessible?
>>
>> You probably want all the ocaml tools to be built as universal binaries
>> and you probably also want the ocamlopt compiler to be able to produce
>> universal binaries.  I would expect that will require some effort from
>> the Caml Team at INRIA.
>
> Lol! no, it is a simple question. Can I make a bytecode program
> and just ship it an expect it to run? No. So what else is required?

I guess that if your bytecode program require some external libraries,
such as for instance if you do a "open Dbm"  then you must
have too this library.
I think that ocamlrun only include code to handle the Pervasive
library.

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote:

> > Lol! no, it is a simple question. Can I make a bytecode program
> > and just ship it an expect it to run? No. So what else is required?
> 
> I guess that if your bytecode program require some external libraries,
> such as for instance if you do a "open Dbm"  then you must
> have too this library.
> I think that ocamlrun only include code to handle the Pervasive
> library.

The code uses only (a) the standard library (Hashtbl and so on),
(b) the Unix library, and (c) Bignums. Therefore the bytecode
only requires support to be found in the standard distribution.

I have a suspicion that one needs to '-custom' link somehow,
to make a suitable single bytecode interpreter. The desire
here is to *avoid* building Ocaml from source on the
target platform, instead to use pre-built binaries,
or, at worst, build these binaries from source,
excluding the full Ocaml toolkit -- the compiler isn't
required since the program is already compiled
to bytecode.

Both myself and my friend are trying to build the Felix
system on diverse platforms, and make it available easily
to potential users: this includes not only Unix like systems,
but also Windows, Apple, and IBM platforms. At present, he 
has got his hands on an Intel/Mac platform for a very limited time,
(at the actual release conference) previously we worked
on an IBM PPC64/Linux platform, G4 and G5 OSX platforms,
and I'm trying to make the system build on native 
Windows Win32 (XP) without Cygwin, using  MSVC++ compiler 
and prebuilt Ocaml .. as well as trying to make both
a Godi and Debian packages ... I wait with dread the release
of 64 bit XP ..

So we're looking at ways to get the system up and running
on new and weird platforms with the minimum of fuss.
Both for ourselves as developers, and for end users.

Whilst I personally prefer the ocaml native code compiler,
at present I can't use it on my AMD64 as there appears
to be a code generation bug in it for that platform --
so I'm using bytecode even for core development,
(and it's a real pain for the Debian packaging .. since
the system autodetects the native code compiler and tries
to use it even though it doesn't work: there is no 
opportunity to intervene manually in Debian autobuilds)

So we're looking at ways to get the system up and running
on new and weird platforms with the minimum of fuss.
Both for ourselves as developers, and for end users.
Solving this problem 'satisfactorily' seems harder
than writing a compiler :)

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Jonathan Bryant]

I have OCaml 3.08.3 up an running on an AMD64 box running Mandrake
10.0.  It compiled beautifully under GODI (ocamlc. ocamlc.opt, ocamlopt,
ocamlopt.opt, etc...).  It might be a Debian bug...

--Jonathan

On Thu, 2005-06-09 at 18:51, John Skaller wrote:
> On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote:
> 
> > > Lol! no, it is a simple question. Can I make a bytecode program
> > > and just ship it an expect it to run? No. So what else is required?
> > 
> > I guess that if your bytecode program require some external libraries,
> > such as for instance if you do a "open Dbm"  then you must
> > have too this library.
> > I think that ocamlrun only include code to handle the Pervasive
> > library.
> 
> The code uses only (a) the standard library (Hashtbl and so on),
> (b) the Unix library, and (c) Bignums. Therefore the bytecode
> only requires support to be found in the standard distribution.
> 
> I have a suspicion that one needs to '-custom' link somehow,
> to make a suitable single bytecode interpreter. The desire
> here is to *avoid* building Ocaml from source on the
> target platform, instead to use pre-built binaries,
> or, at worst, build these binaries from source,
> excluding the full Ocaml toolkit -- the compiler isn't
> required since the program is already compiled
> to bytecode.
> 
> Both myself and my friend are trying to build the Felix
> system on diverse platforms, and make it available easily
> to potential users: this includes not only Unix like systems,
> but also Windows, Apple, and IBM platforms. At present, he 
> has got his hands on an Intel/Mac platform for a very limited time,
> (at the actual release conference) previously we worked
> on an IBM PPC64/Linux platform, G4 and G5 OSX platforms,
> and I'm trying to make the system build on native 
> Windows Win32 (XP) without Cygwin, using  MSVC++ compiler 
> and prebuilt Ocaml .. as well as trying to make both
> a Godi and Debian packages ... I wait with dread the release
> of 64 bit XP ..
> 
> So we're looking at ways to get the system up and running
> on new and weird platforms with the minimum of fuss.
> Both for ourselves as developers, and for end users.
> 
> Whilst I personally prefer the ocaml native code compiler,
> at present I can't use it on my AMD64 as there appears
> to be a code generation bug in it for that platform --
> so I'm using bytecode even for core development,
> (and it's a real pain for the Debian packaging .. since
> the system autodetects the native code compiler and tries
> to use it even though it doesn't work: there is no 
> opportunity to intervene manually in Debian autobuilds)
> 
> So we're looking at ways to get the system up and running
> on new and weird platforms with the minimum of fuss.
> Both for ourselves as developers, and for end users.
> Solving this problem 'satisfactorily' seems harder
> than writing a compiler :)
> 
> -- 
> John Skaller, skaller at users.sf.net
> PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
> Download Felix here: http://felix.sf.net
> 
> _______________________________________________
> 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] Caml on intel-OSX

[John Skaller]

On Thu, 2005-06-09 at 20:02 -0400, Jonathan Bryant wrote:
> I have OCaml 3.08.3 up an running on an AMD64 box running Mandrake
> 10.0.  It compiled beautifully under GODI (ocamlc. ocamlc.opt, ocamlopt,
> ocamlopt.opt, etc...).  It might be a Debian bug...

I doubt it is a Debian bug. I'm actually running Ubuntu,
and the bug occurs in my local compiled from source
version 3.08.3 and also in the installed binary package,
which is 3.08.2.

It also only manifests in one program, and it causes
a segfault in that program in the exact same place
independently of the input, provided that place
is actually executed.

No other Ocaml programs I have built on the box exhibit
this problem. However, the code works fine as bytecode
and also works on the x86 with native code compiler.
Increasing stack size from 8M to 16M has no effect,
and I don't expect the stack to be deep at the point
in the source the error occurs.

The error actually occurs calling a function with
a lot of arguments from inside a list iteration,
and that function immediately calls another function
by simply dropping some arguments .. a perfect candidate
for optimisation. My guess is the backend code generator
has screwed up keeping track of which registers hold what
data .. a problem which won't occur on the x86 simply
because there aren't enough registers... :)

I have verified this, approximately, by adding
debugging prints at various points -- if the print
is added just early enough the bug goes away.

Presumably the extra call is causing a correct
routine in the backend code generator 
to load/save registers or whatever,
because the call is disabling a faulty optimisation/
register allocation. Any other interesting theory
appreciated ..

The segfault occurs in 'caml_apply5()' somewhere.

If anyone would like to test it on another AMD64 based
system I would be most happy:

wget http://felix.sf.net/flx_1.0.25_src.tgz
tar -zxvf flx_1.0.25.tgz
cd flx_1.0.25
./configure
make

[all the test program compiles segfault ..]

This big is logged in the bug tracker,
but i forget the PR and it's hard to find again,
since i don't know what the disposition is ;(

If someone else can reproduce it/fail to
reproduce it, that would be valuable data,
since the package is quite large (160K LOC),
and I have no idea how to isolate the problem.


-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Florian Hars]

John Skaller wrote:
> This big is logged in the bug tracker,
> but i forget the PR and it's hard to find again,
> since i don't know what the disposition is ;(

If you search the BTS for the regexp "skaller", is is one of the
tree incoming bugs the system finds:

http://pauillac.inria.fr/bin/caml-bugs/incoming?id=3640

Yours, Florian.

Re: [Caml-list] Caml on intel-OSX

[Jacques Garrigue]

From: John Skaller <skaller@users.sourceforge.net>
> On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote:
> 
> > > Lol! no, it is a simple question. Can I make a bytecode program
> > > and just ship it an expect it to run? No. So what else is required?
> > 
> > I guess that if your bytecode program require some external libraries,
> > such as for instance if you do a "open Dbm"  then you must
> > have too this library.
> > I think that ocamlrun only include code to handle the Pervasive
> > library.
> 
> The code uses only (a) the standard library (Hashtbl and so on),
> (b) the Unix library, and (c) Bignums. Therefore the bytecode
> only requires support to be found in the standard distribution.
> 
> I have a suspicion that one needs to '-custom' link somehow,
> to make a suitable single bytecode interpreter. The desire
> here is to *avoid* building Ocaml from source on the
> target platform, instead to use pre-built binaries,
> or, at worst, build these binaries from source,
> excluding the full Ocaml toolkit -- the compiler isn't
> required since the program is already compiled
> to bytecode.

In theory, it should be enough to have ocamlrun, and the dlls in
stublibs.
The an ocaml bytecode executable, linked _without_ -custom, could be
executed as:
  $ setenv CAML_LD_LIBRARY_PATH /path/to/stublibs
  $ ocamlrun myprogram
(Of course you need everything to be compiled from the same ocaml
distribution.)

The problem is that there is no support to compile only bits and
pieces of the ocaml distribution. And there is little point to do
that: once you've compiled the ocamlrun, all the ocaml tools will
compile without a glitch.
This said, you can try to do this by hand. On Unix, ocamlmklib is
required, so this would be:
  $ ./configure
  $ make coldstart
  $ (cd tools; make ocamlmklib)
  $ (cd otherlibs/unix; make libunix.a)
  $ (cd otherlibs/num; make libnums.a)
Then copy ocamlrun, dllunix.so and dllnums.so to public places.

On windows/msvc, the process is even shorter as ocamlmklib is not
used (but I didn't check):
  $ make -f Makefile.nt runtime
  $ cd otherlibs/unix; make -f Makefile.nt dllunix.dll
  $ cd ../nums; make -f Makefile.nt dllnums.dll
However there is little point, as binaries are available:
Just get an ocaml binary distribution, and only keep ocamlrun and all
the dlls (including ocamlrun.dll).

> Both myself and my friend are trying to build the Felix
> system on diverse platforms, and make it available easily
> to potential users: this includes not only Unix like systems,
> but also Windows, Apple, and IBM platforms. At present, he 
> has got his hands on an Intel/Mac platform for a very limited time,
> (at the actual release conference) previously we worked
> on an IBM PPC64/Linux platform, G4 and G5 OSX platforms,
> and I'm trying to make the system build on native 
> Windows Win32 (XP) without Cygwin, using  MSVC++ compiler 
> and prebuilt Ocaml .. as well as trying to make both
> a Godi and Debian packages ... I wait with dread the release
> of 64 bit XP ..

What you're trying to say is not completely clear to me, especially
as you mix "sane" unix systems with "insane" msvc++.
But the whole point is that, if you're satisfied with bytecode, you
only need ocamlrun and the dlls to run any ocaml bytecode executable.
No need to recompile anything on the target platform. There is only
one exception to that: I believe that executable for windows should
link with the windows version of unix.cma. Ideally you would be
able to do that even on a unix system, but unfortunately ocamlc checks
that no external functions are missing at link time, which makes this
impossible (we need a flag to disable that check...) So for the time
being, an unix executable will run on any unix platform, and a windows
executable will run on any windows platform (including 64-bit XP, when
it will be supported). Also it should be possible to link on windows objects
produced on unix (and vice-versa). To do that you only need ocamlc
and all the cma's.

Actually it might be a good idea to provide such minimal binary
platforms for a variety of systems.

Jacques Garrigue

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Fri, 2005-06-10 at 09:41 +0900, Jacques Garrigue wrote:
> From: John Skaller <skaller@users.sourceforge.net>

> What you're trying to say is not completely clear to me, especially
> as you mix "sane" unix systems with "insane" msvc++.

Since when is market driven technology 'sane'?? :)

> But the whole point is that, if you're satisfied with bytecode, you
> only need ocamlrun and the dlls to run any ocaml bytecode executable.

Ok. Good. 

<hehe .. BSD the source, GPL the bytecode, and charge
corporations for native code .. :->

> Actually it might be a good idea to provide such minimal binary
> platforms for a variety of systems.

This would make my friend happy, and probably some other
Ocaml developers too.

"Write once, run anywhere" for Ocaml sounds good to me --

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Sven Luther]

On Fri, Jun 10, 2005 at 09:41:51AM +0900, Jacques Garrigue wrote:
> From: John Skaller <skaller@users.sourceforge.net>
> > On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote:
> > 
> > > > Lol! no, it is a simple question. Can I make a bytecode program
> > > > and just ship it an expect it to run? No. So what else is required?
> > > 
> > > I guess that if your bytecode program require some external libraries,
> > > such as for instance if you do a "open Dbm"  then you must
> > > have too this library.
> > > I think that ocamlrun only include code to handle the Pervasive
> > > library.
> > 
> > The code uses only (a) the standard library (Hashtbl and so on),
> > (b) the Unix library, and (c) Bignums. Therefore the bytecode
> > only requires support to be found in the standard distribution.
> > 
> > I have a suspicion that one needs to '-custom' link somehow,
> > to make a suitable single bytecode interpreter. The desire
> > here is to *avoid* building Ocaml from source on the
> > target platform, instead to use pre-built binaries,
> > or, at worst, build these binaries from source,
> > excluding the full Ocaml toolkit -- the compiler isn't
> > required since the program is already compiled
> > to bytecode.
> 
> In theory, it should be enough to have ocamlrun, and the dlls in
> stublibs.
> The an ocaml bytecode executable, linked _without_ -custom, could be
> executed as:
>   $ setenv CAML_LD_LIBRARY_PATH /path/to/stublibs
>   $ ocamlrun myprogram
> (Of course you need everything to be compiled from the same ocaml
> distribution.)
> 
> The problem is that there is no support to compile only bits and
> pieces of the ocaml distribution. And there is little point to do

Works fine with a binary distribution like debian though, we ship the ocamlrun
and sublibs separatedly, and only those packages are needed to run a bytecode
package using them.

Friendly,

Sven Luther

Re: [Caml-list] Caml on intel-OSX

[Stefano Zacchiroli]

On Fri, Jun 10, 2005 at 08:51:40AM +1000, John Skaller wrote:
> (and it's a real pain for the Debian packaging .. since
> the system autodetects the native code compiler and tries
> to use it even though it doesn't work: there is no 
> opportunity to intervene manually in Debian autobuilds)

This is not true.

Debian autobuilds simply invoke a make file (debian/rules) written by
the package, which usually invokes upstream Makefile.  Since you are the
packager, if you really want the autobuilds not to build native code,
then you can change either debian/rules or Makefile so that native code
compilation is not enforced.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Fri, 2005-06-10 at 08:35 +0200, Stefano Zacchiroli wrote:
> On Fri, Jun 10, 2005 at 08:51:40AM +1000, John Skaller wrote:
> > (and it's a real pain for the Debian packaging .. since
> > the system autodetects the native code compiler and tries
> > to use it even though it doesn't work: there is no 
> > opportunity to intervene manually in Debian autobuilds)
> 
> This is not true.
> 
> Debian autobuilds simply invoke a make file (debian/rules) written by
> the package, which usually invokes upstream Makefile.  Since you are the
> packager, if you really want the autobuilds not to build native code,
> then you can change either debian/rules or Makefile so that native code
> compilation is not enforced.

I could include a special piece of logic 
in the debian rules, which checks for AMD64 and
disables the native code compiler in that case...

.. or I could change the config script (since I'm 
also the upstream author).

But that isn't *manual* intervention. 

BTW: the packages are available in the directory

http://felix.sf.net/debian

There is a dependence on ocaml,
but none on the native code package.. if you happen to have
it installed the native code compiler will be used to
build the binary package, otherwise you'll get bytecode.

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Jon Harrop]

On Thursday 09 June 2005 23:51, John Skaller wrote:
> Whilst I personally prefer the ocaml native code compiler,
> at present I can't use it on my AMD64 as there appears
> to be a code generation bug in it for that platform --

Yipes! I'm about to release some commercial software for x86 and AMD64 and I 
really didn't want to hear this!

I've been experiencing segfaults on all platforms but I think this is a bug in 
lablGL rather than ocamlopt.

Do you think I shouldn't release for AMD64? How confident are you that this is 
a codegen bug? Does your code use only OCaml's theoretically safe subset?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Sat, 2005-06-11 at 00:39 +0100, Jon Harrop wrote:
> On Thursday 09 June 2005 23:51, John Skaller wrote:
> > Whilst I personally prefer the ocaml native code compiler,
> > at present I can't use it on my AMD64 as there appears

> Do you think I shouldn't release for AMD64? 

See PR#3640 (in Incoming in the Bug Tracker) first:

My guess is if you code works it works... the bug
is fairly rare and only triggered in unusual
circumstances .. but that is just a guess.

> How confident are you that this is 
> a codegen bug? 

It would help if someone tried to replicate the problem,
to be sure it exists -- if could just be my machine.

Try to build Felix:

/http://felix.sourceforge.net/flx_1.0.25_src.tgz

on my box it segfaults in every test.

I can only guess it is a backend code generator bug
from the following data:

(a) it goes way if a print_endline " .. " is introduced
in certain places but not others.

(b) Using that technique I have isolated the problem
to a few lines of Ocaml code

(c) Something like 50 regression tests and tutorial
examples all fail in the same place

(d) gdb indicates a problem in caml_apply5()

(e) The code runs on x86 with native code compiler
and all architectures with bytecode compiler.

(f) changing stack size from 8M to 16M makes no
difference

(g) The problem only occurs in one program in one
place, other programs don't fail.

(h) It fails on both my personal build from sourcecode
of 3.08.3 and also a 3.08.2(ubuntu) binary package
(which I guess is a copy of the Debian package).

I would be a lot more confident if someone reproduced
the bug and someone from INRIA said they'd found it :)
I'm only guessing. I am not an expert on the internals
of Ocaml.

> Does your code use only OCaml's theoretically safe subset?

Yes. The code also runs on x86 native code and bytecode.
It does use Unix, Big_int, and Ocamlyacc/Ocamllex
it might be a C compiler problem, but the location
of the crash isn't using any of that and it isn't 
a random error but repeatable and consistent.

However there is no Obj.magic, and no C, and no
other third party code such as from Extlib that might
use it: everything comes from the standard distro.
[Actually ocs_scheme is linked in and might, but it
isn't being called]

There lots of things I could experiment with,
for example it might be my linker, C compiler,
or even Linux kernel... or it could be a bug
in the Felix source which luckily didn't cause
a problem in other situations (eg, a tail-recursion
that isn't handled on one processor but is on another).

But a simple bug in register allocation in the back
end seems most likely to me at this time.


-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] Caml on intel-OSX

[Jon Harrop]

On Saturday 11 June 2005 19:39, John Skaller wrote:
> It would help if someone tried to replicate the problem,
> to be sure it exists -- if could just be my machine.

Sorry, I forgot to say that I did what you asked on my AMD64 and got a 
segfault. I haven't checked to see if it is a stack overflow though.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Caml on intel-OSX

[John Skaller]

On Sat, 2005-06-11 at 20:03 +0100, Jon Harrop wrote:
> On Saturday 11 June 2005 19:39, John Skaller wrote:
> > It would help if someone tried to replicate the problem,
> > to be sure it exists -- if could just be my machine.
> 
> Sorry, I forgot to say that I did what you asked on my AMD64 and got a 
> segfault. I haven't checked to see if it is a stack overflow though.

OK, so you replicated the problem. If you set

NATIVE_CODE_COMPILER=0

in the file

config/ocaml_config.py

and rebuild by something like

make virgin
./configure
make

you'll be running the bytecode version, and it should
all work, indicating the problem isn't a source code bug.

I tried to build the CVS Ocaml under Godi, but the build
fails at the moment (I should try direct CVS build next).

It is a bit of a pain for me because I'm trying to build
a Debian package, and there is a dependency on Ocaml,
but not native code compiler package. However, that
should be a 'build-recommends', and if installed,
as it is on my box, the native code compiler is automatically
detected and used. Debian knows the platform architecture,
but the configure script is Python, and supposed to work
on all platforms, and I have no idea of how to discover
the platform architecture in general.

-------------------------------------------------
We have this code where the
error occurs, and according the PR#3640, if the process_function
debug print is included, the segfault goes away .. 

.. it looks to me like adding debug prints changes inlining
behaviour (adding the debug print prevents inlining) and somehow
after inlining the result triggers the code generation bug.

I would guess inlining is higher level than code generation,
so it isn't the inlining algorithm that is the problem.
The AMD64 code generator sounds more likely, and this
assumption is also supported by the fact it is newer code.

Of course these are all GUESSES on my part. 
---------------------------------------------------------
and process_function syms bbdfns hvarmap ref_insts1 index sr argtypes ret exes
ts =
  (*
  print_endline ("Process function " ^ si index);
  *)
  process_exes syms bbdfns ref_insts1 ts hvarmap e



and process_exes syms bbdfns ref_insts1 ts hvarmap exes = 
  (*
     put some debug print here too ..
  *)
  iter (process_exe syms bbdfns ref_insts1 ts hvarmap) exes


and process_exe syms bbdfns ref_insts1 ts hvarmap (exe:bexe_t) =
  let ue sr e = process_expr syms bbdfns ref_insts1 hvarmap sr e in
  let uis i ts = add_inst syms ref_insts1 (i,ts) in
  let ui i = uis i ts in
  (*
  print_endline ("processing exe " ^ string_of_bexe syms.dfns 0 exe);
A
  *)
.....


-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] AMD64 ocamlopt bug

[Xavier Leroy]

> > > Whilst I personally prefer the ocaml native code compiler,
> > > at present I can't use it on my AMD64 as there appears
> 
> > Do you think I shouldn't release for AMD64? 
> 
> See PR#3640 (in Incoming in the Bug Tracker) first:
> 
> My guess is if you code works it works... the bug
> is fairly rare and only triggered in unusual
> circumstances .. but that is just a guess.

Yes, PR#3640 is an AMD64-specific code generation bug.  It occurs in
the uncommon case where a leaf function (a function that doesn't call
other functions except as a tail-call) accesses a parameter passed on
the stack (not in registers).  As a rule of thumb, if your tail
functions have fewer than 9 arguments, you're safe.

The bug is fixed in the CVS repository, 3.08 bug-fix branch.

- Xavier Leroy

Re: [Caml-list] AMD64 ocamlopt bug

[John Skaller]

On Mon, 2005-06-13 at 21:19 +0200, Xavier Leroy wrote:
> > > > Whilst I personally prefer the ocaml native code compiler,
> > > > at present I can't use it on my AMD64 as there appears
> > 
> > > Do you think I shouldn't release for AMD64? 
> > 
> > See PR#3640 (in Incoming in the Bug Tracker) first:
> > 
> > My guess is if you code works it works... the bug
> > is fairly rare and only triggered in unusual
> > circumstances .. but that is just a guess.
> 
> Yes, PR#3640 is an AMD64-specific code generation bug.  It occurs in
> the uncommon case where a leaf function (a function that doesn't call
> other functions except as a tail-call) accesses a parameter passed on
> the stack (not in registers).  As a rule of thumb, if your tail
> functions have fewer than 9 arguments, you're safe.
> 
> The bug is fixed in the CVS repository, 3.08 bug-fix branch.

Thanks! Nice work finding it! And dumb question: does that mean
the main CVS branch is also fixed? (or will the bug fixed branch
be merged in when 3.09 is released?)

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] AMD64 ocamlopt bug

[Damien Doligez]

On Jun 13, 2005, at 21:32, John Skaller wrote:

> Thanks! Nice work finding it! And dumb question: does that mean
> the main CVS branch is also fixed? (or will the bug fixed branch
> be merged in when 3.09 is released?)

The bugfix branch will be merged when we release 3.08.4 (or 3.09 if
that comes first).

-- Damien

Re: [Caml-list] AMD64 ocamlopt bug

[John Skaller]

On Tue, 2005-06-14 at 05:32 +1000, John Skaller wrote:
> On Mon, 2005-06-13 at 21:19 +0200, Xavier Leroy wrote:

> > The bug is fixed in the CVS repository, 3.08 bug-fix branch.

in particular:

cvs update -r release308

fetches the 'bugfix' branch. I confirm, with this version,
which is '3.0.8.3+3' <lol> the segfault goes away.

> Thanks! Nice work finding it! And dumb question: does that mean
> the main CVS branch is also fixed? 

[I tried .. answer is no, the main branch isn't fixed yet]

-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net

Re: [Caml-list] AMD64 ocamlopt bug

[Anil Madhavapeddy]

On 13 Jun 2005, at 21:27, John Skaller wrote:

>
>> Thanks! Nice work finding it! And dumb question: does that mean
>> the main CVS branch is also fixed?
>>
>
> [I tried .. answer is no, the main branch isn't fixed yet]


You can just answer this for yourself by looking at the public OCaml  
anoncvs repository.  It even has a web interface, you just need to  
know some rudimentary French to parse the logs :-)

http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/asmcomp/amd64/emit.mlp

Anil

Re: [Caml-list] Caml on intel-OSX

[Jonathan Bryant]

ocamlc with the "-custon" flag makes standalone bytecode programs (it
embeds a copy of the ZAM, which it generates a slighly larger
executable).  But, like was was said earlier, any external libraries
referenced (Dbm, etc.) would have to be included.  I think they can be
linked in using a flag, but I don't know.  I do know that any external
non-caml libraries (.a & .so files) are not linked in.  I almost
exclusively use the native code compiler and may be mistaken, so check
the documentation.  Check out the O'Really [sic] OCaml book ("Developing
Applications with OCaml") on the OCaml website: it has a pretty decently
good discussion of this.

--Jonathan

On Thu, 2005-06-09 at 12:20, padiolea@irisa.fr wrote:
> > On Thu, 2005-06-09 at 07:00 -0700, james woodyatt wrote:
> >> On 08 Jun 2005, at 22:33, John Skaller wrote:
> >> >
> >> > And a dumb question .. will a bytecode Ocaml program
> >> > just run on any machine provided a single binary,
> >> > ocamlrun, is installed and accessible?
> >>
> >> You probably want all the ocaml tools to be built as universal binaries
> >> and you probably also want the ocamlopt compiler to be able to produce
> >> universal binaries.  I would expect that will require some effort from
> >> the Caml Team at INRIA.
> >
> > Lol! no, it is a simple question. Can I make a bytecode program
> > and just ship it an expect it to run? No. So what else is required?
> 
> I guess that if your bytecode program require some external libraries,
> such as for instance if you do a "open Dbm"  then you must
> have too this library.
> I think that ocamlrun only include code to handle the Pervasive
> library.
> 
> 
> 
> _______________________________________________
> 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