Re: Registerised x86_64 port: test version available
Hi Simon, this is just to let you know that I successfully compiled the lastest snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks! Cheers, Ralf PS: Just curious: is the gcc route easier than the NCG? To me it seems much more fragile. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Registerised x86_64 port: test version available
On 09 March 2005 10:14, Ralf Hinze wrote: this is just to let you know that I successfully compiled the lastest snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks! Cheers, Ralf PS: Just curious: is the gcc route easier than the NCG? To me it seems much more fragile. It's initially easier to get going, but yes it's more fragile. Currently we can't go it alone with the NCG because the NCG isn't quite capable of compiling the hand-written .cmm files in the runtime. At some point we'll fix this. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FW: RE: x86_64 port
On 07 March 2005 18:01, Kurt Roeckx wrote:
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
I get the same with both gcc-3.3 and gcc-3.4. They generate
identical code.
Note that the assignment to the global variable R1 has been lost. It
works fine on x86 though: change the register variable to %esi and
try it.
It looks to me like it's using eax/rax instead of r13 to me.
It's probably doing some optimizing it shouldn't, but on the
other hand isn't wrong.
...
Anyway, as summary:
- It's using a movl where it should use a movq
- It's probably doing some optimizations it shouldn't, but
they're not wrong in this testcase and probably can't be
avoided because of the way gcc works.
Those happen on both i386 and amd64.
The question of whether this behaviour is wrong or not is interesting.
On the face of it, the generated code is incorrect because it doesn't
implement the semantics of the original program.
However, we have to be clear about what the semantics of the original
program *is*. The register annotation is just an annotation, and
therefore doesn't affect the semantics. But the gcc manual has this to
say about computed goto:
You may not use this mechanism to jump to code in a different
function.
So, perhaps the example program relies on undefined behaviour. But, you
can change the example program so that gcc has no idea where it's
jumping to, and gcc will still generate incorrect code. So in fact it
has nothing to do with the jump destination being outside the current
function.
It's a bug.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Registerised x86_64 port: test version available
I've put up an x86_64/Linux registerised build for testing here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux .tar.bz2 This is a binary distribution: ./configure make -k install. The -k is necessary because it doesn't have all the docs. It was built on Fedora FC3. Note it claims version 6.4, but actually it's 6.4.20050308. Still no GHCi, no foreign export dynamic, no native code gen. But it seems to work (this is a stage 3 build). Enjoy! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Registerised x86_64 port: test version available
On Tue, 2005-03-08 at 15:16 +, Simon Marlow wrote: I've put up an x86_64/Linux registerised build for testing here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux .tar.bz2 This is a binary distribution: ./configure make -k install. The -k is necessary because it doesn't have all the docs. It was built on Fedora FC3. Note it claims version 6.4, but actually it's 6.4.20050308. Still no GHCi, no foreign export dynamic, no native code gen. But it seems to work (this is a stage 3 build). For someone with an amd64 and some spare time: So the burning question is: do all those extra registers help? Does Haskell code run faster in 64bit mode or 32bit mode? Performance graphs on a postcard to the usual address... Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Registerised x86_64 port: test version available
On 08 March 2005 15:59, Duncan Coutts wrote: On Tue, 2005-03-08 at 15:16 +, Simon Marlow wrote: I've put up an x86_64/Linux registerised build for testing here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux .tar.bz2 This is a binary distribution: ./configure make -k install. The -k is necessary because it doesn't have all the docs. It was built on Fedora FC3. Note it claims version 6.4, but actually it's 6.4.20050308. Still no GHCi, no foreign export dynamic, no native code gen. But it seems to work (this is a stage 3 build). For someone with an amd64 and some spare time: So the burning question is: do all those extra registers help? Does Haskell code run faster in 64bit mode or 32bit mode? Performance graphs on a postcard to the usual address... I haven't really made full use of the extra registers yet. The register mapping is certainly sub-optimal: I didn't use any of the call-clobbered regs, but almost certainly it will be a good idea to do so. So far I've only assigned a single argument register, the same as x86. Upshot: you're unlikely to get much better performance than the plain x86 registerised build at the moment. When I've got some time I'll play around with more aggressive register assignments (or anyone else is welcome... just fiddle with the settings in ghc/includes/MachRegs.h, and don't forget to set the appropriate CALLER_SAVES macro if you pinch a call-clobbered reg). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Registerised x86_64 port: test version available
Simon Marlow ([EMAIL PROTECTED]) wrote: Hi Simon! I've put up an x86_64/Linux registerised build for testing here: Thank you very much. This is a binary distribution: ./configure make -k install. The -k is necessary because it doesn't have all the docs. It was built on Fedora FC3. Note it claims version 6.4, but actually it's 6.4.20050308. darcs compiles fine :-)) Still no GHCi, no foreign export dynamic, no native code gen. But it seems to work (this is a stage 3 build). Hope we'll see the rest soon ;-) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Fri, Mar 04, 2005 at 11:13:28AM -0600, John Goerzen wrote: Do any of you know if this is a known problem? - Forwarded message from Simon Marlow [EMAIL PROTECTED] - From: Simon Marlow [EMAIL PROTECTED] Date: Fri, 4 Mar 2005 17:03:31 - To: John Goerzen [EMAIL PROTECTED] Cc: glasgow-haskell-users@haskell.org Subject: RE: x86_64 port On 04 March 2005 16:59, John Goerzen wrote: On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) I have no idea what ghc has too do with gcc, or what the problem exactly is. We have very little problems with gcc for the debian amd64 port. Our default compiler is still 3.3. This builds almost everything without problems, however we build a few mozilla packages with gcc-3.4. All I can tell is that ghc6 seems to be working on debian amd64. It can build itself and things like that. Can someone please give a test case (and show what to do) to see what is wrong? Out current default compiler in debian is: gcc version 3.3.5 (Debian 1:3.3.5-8) The gcc 3.4 version is: gcc version 3.4.4 20050203 (prerelease) (Debian 3.4.3-9) And ghc6 is at version 6.2.2-3. Kurt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 17:48, Wolfgang Thaller wrote: On 4-Mar-05, at 11:57 AM, Simon Marlow wrote: Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). So maybe this will be the first NCG-only port of GHC :-). Death to the Mangler! Yes, the same thought occurred to me... Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FW: RE: x86_64 port
On 04 March 2005 17:32, Kurt Roeckx wrote:
I have no idea what ghc has too do with gcc,
A bit of background: GHC uses gcc as a backend compiler. GHC generates
C code that is compiled using gcc (we also have a native code generator
for some platforms; but not for x86_64 yet).
or what the problem exactly is.
The problem is that gcc generates incorrect code for C code that uses
global register variables. You won't have noticed this, because most
programs don't use global register variables. GHC uses global register
variables to speed up the generated code.
We have very little problems with gcc for the debian
amd64 port. Our default compiler is still 3.3. This builds
almost everything without problems, however we build a few
mozilla packages with gcc-3.4.
All I can tell is that ghc6 seems to be working on debian amd64.
It can build itself and things like that.
That build of ghc6 is what we call unregisterised: it doesn't make use
of register variables to speed up the generated code. IOW, it generates
plain ANSI C code, which gcc compiles fine.
Can someone please give a test case (and show what to do) to see
what is wrong?
Ok, here's a really simple example:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
Note that the assignment to the global variable R1 has been lost. It
works fine on x86 though: change the register variable to %esi and try
it.
Out current default compiler in debian is:
gcc version 3.3.5 (Debian 1:3.3.5-8)
The gcc 3.4 version is:
gcc version 3.4.4 20050203 (prerelease) (Debian 3.4.3-9)
And ghc6 is at version 6.2.2-3.
I'm going to try with different versions of gcc. I've just submitted
this bug report to the gcc guys.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 22:54, Donald Bruce Stewart wrote: simonmar: On 04 March 2005 16:59, John Goerzen wrote: On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) I note that the GCC 4.0 branch is now being stabilised -- maybe that's something to check. They claim it works with 4.0.0. Here's the bug I submitted: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
Note that the assignment to the global variable R1 has been lost. It
works fine on x86 though: change the register variable to %esi and try
it.
Hmm. On gcc 3.3.5 that I have, it discards the assignment on x86 as well.
Dave
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FW: RE: x86_64 port
On 07 March 2005 16:18, David Brown wrote:
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
Note that the assignment to the global variable R1 has been lost. It
works fine on x86 though: change the register variable to %esi and
try it.
Hmm. On gcc 3.3.5 that I have, it discards the assignment on x86 as
well.
Yes, looks like it fails with 3.4.1 and 3.4.3 I have here, but 3.2.2
works.
Now I'm quite surpised that this hasn't affected us on x86. Very
strange.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FW: RE: x86_64 port
On 07 March 2005 16:40, Simon Marlow wrote:
On 07 March 2005 16:18, David Brown wrote:
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
Note that the assignment to the global variable R1 has been lost.
It works fine on x86 though: change the register variable to %esi
and try it.
Hmm. On gcc 3.3.5 that I have, it discards the assignment on x86 as
well.
Yes, looks like it fails with 3.4.1 and 3.4.3 I have here, but 3.2.2
works.
Now I'm quite surpised that this hasn't affected us on x86. Very
strange.
The mystery as to why this doesn't affect us on x86 is solved: on x86 we
generate slightly different C code, including a dummy function call:
extern void g(void);
static void f(void) {
R1 = g;
dummy();
goto *R1;
}
the call to dummy() (which we filter out from the assembly later) is
enough to force gcc to emit the assignment to R1. That dummy function
call has been there for ever, and the original reason for it has been
lost in the mists of time... comments in the source code seemed to
indicate that it was probably not necessary any more, so for x86_64 I
removed it. It looks like I'll have to reinstate it to work around this
bug, though.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Mon, Mar 07, 2005 at 04:59:38PM -, Simon Marlow wrote:
The mystery as to why this doesn't affect us on x86 is solved: on x86 we
generate slightly different C code, including a dummy function call:
extern void g(void);
static void f(void) {
R1 = g;
dummy();
goto *R1;
}
the call to dummy() (which we filter out from the assembly later) is
enough to force gcc to emit the assignment to R1. That dummy function
call has been there for ever, and the original reason for it has been
lost in the mists of time... comments in the source code seemed to
indicate that it was probably not necessary any more, so for x86_64 I
removed it. It looks like I'll have to reinstate it to work around this
bug, though.
gcc 3.3.4 on AMD64 appears to generate correct code when the dummy call is
present. Ick.
Dave
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
In message [EMAIL PROTECTED] David Brown
[EMAIL PROTECTED] writes:
On Mon, Mar 07, 2005 at 04:59:38PM -, Simon Marlow wrote:
The mystery as to why this doesn't affect us on x86 is solved: on x86 we
generate slightly different C code, including a dummy function call:
extern void g(void);
static void f(void) {
R1 = g;
dummy();
goto *R1;
}
the call to dummy() (which we filter out from the assembly later) is
enough to force gcc to emit the assignment to R1. That dummy function
call has been there for ever, and the original reason for it has been
lost in the mists of time... comments in the source code seemed to
indicate that it was probably not necessary any more, so for x86_64 I
removed it. It looks like I'll have to reinstate it to work around this
bug, though.
This all appears to be the same for Sparc. With:
register void * R1 __asm__(%g7);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
(BTW I have no idea if register g7 is a sensible choice here! So this test may
be meaningless!)
We get:
sethi %hi(g), %g1
jmp %g1+%lo(g)
nop
While with the dummy() call inserted:
sethi %hi(g), %g1
calldummy, 0
or %g1, %lo(g), %g7
jmp %g7
nop
we actually get any mention of %g7 at all.
This is with gcc 3.3.5 on Sparc Linux (Gentoo).
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote:
$ cat bug.c
register void * R1 __asm__(%r13);
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -S -O bug.c
$
And take a look at the generated assembly for the function f:
f:
.LFB2:
movl$g, %eax
jmp *%rax
I get the same with both gcc-3.3 and gcc-3.4. They generate
identical code.
Note that the assignment to the global variable R1 has been lost. It
works fine on x86 though: change the register variable to %esi and try
it.
It looks to me like it's using eax/rax instead of r13 to me.
It's probably doing some optimizing it shouldn't, but on the
other hand isn't wrong.
Also, it should be a movq $g, %rax instead of movl.
Without -O I get:
f:
pushq %rbp
movq%rsp, %rbp
movl$g, %r13d
movq%r13, %rax
jmp *%rax
(Note that the first 2 instructions are now a stack frame,
disabled with -O)
It still is using an movl instead of a movq, which is wrong.
esi (or rsi) give the following warning:
bug.c:1: warning: call-clobbered register used for global register variable
And doesn't change a thing. It's still the same code.
Using %ebp or %rbp with -O gives:
movl$g, %ebp
jmp *%rbp
Which gives the same movl/movq problem, but now got the right
register.
Doing the same on i386 generates this:
f:
pushl %ebp
movl%esp, %ebp
movl$g, %eax
jmp *%eax
Using -fomit-frame-pointer you get:
f:
movl$g, %eax
jmp *%eax
Which seems to be exactly the same thing, except it got the size
right now.
The weird thing is that r13 doesn't exist on i386, and it didn't
complain about it.
Anyway, as summary:
- It's using a movl where it should use a movq
- It's probably doing some optimizations it shouldn't, but
they're not wrong in this testcase and probably can't be
avoided because of the way gcc works.
Those happen on both i386 and amd64.
Kurt
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Mon, Mar 07, 2005 at 09:15:01AM -0800, David Brown wrote: gcc 3.3.4 on AMD64 appears to generate correct code when the dummy call is present. Ick. It generates the following code here: subq$8, %rsp movl$g, %r13d movl$0, %eax calldummy jmp *%r13 Which still has the movl vs movq problem. Kurt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: RE: x86_64 port
On Mon, Mar 07, 2005 at 07:01:16PM +0100, Kurt Roeckx wrote: Also, it should be a movq $g, %rax instead of movl. The default x86_64 model on gcc is -mcmodel=small, which assumes that all symbols are within the first 2GB. If you compile it with -mcmodel=medium it'll generate: movabsq $g, %r13 Dave ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 02 March 2005 14:15, John Goerzen wrote: Kip Macy kip.macy at gmail.com writes: I've followed the instructions to the letter. Debian has had a working amd64 package of ghc for some time now. It is built out of the standard source base for it. You can find that at: http://ftp.debian.org/debian/pool/main/g/ghc6 You'll want to grab the orig.tar.gz and the diff.gz files. If you want to grab an amd64 .deb to try, go to: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/ Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
Simon Marlow ([EMAIL PROTECTED]) wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... :- As soon as you have some pre-alpha release, I'm ready to test ;) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... That would be great! I just assembled an amd64 box and I am mssing ghci badly. Let me know if I can be of any help (testing ..). Cheers, Ralf ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
On Fri, Mar 04, 2005 at 09:38:47AM -, Simon Marlow wrote: Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 14:04, John Goerzen wrote: On Fri, Mar 04, 2005 at 09:38:47AM -, Simon Marlow wrote: Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). I don't know if I can work around it yet. We'll see. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64 port
On 04 March 2005 16:59, John Goerzen wrote: On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: On 04 March 2005 14:04, John Goerzen wrote: My amd64 hardware arrived yesterday, shouldn't be too long before we have a registerised port of GHC, and possibly a native code generator... burns excellent /burns Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). Which version of gcc? gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
On 4-Mar-05, at 11:57 AM, Simon Marlow wrote: Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). So maybe this will be the first NCG-only port of GHC :-). Death to the Mangler! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
Kip Macy kip.macy at gmail.com writes: I've followed the instructions to the letter. Debian has had a working amd64 package of ghc for some time now. It is built out of the standard source base for it. You can find that at: http://ftp.debian.org/debian/pool/main/g/ghc6 You'll want to grab the orig.tar.gz and the diff.gz files. If you want to grab an amd64 .deb to try, go to: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/ Even if you're not running Debian, there are tools available to convert a .deb to a RPM or tgz package. Or, you can easily unpack a deb using only ar(1) and tar(1). -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
Much of this is done already. Simon Marlow's done the register mapping (ghc/includes/MachRegs.h) and done other registerisation work. There was a bug in gcc-3.3x that halted things for a while, but this has been fixed in 6.4 All the files mentioned except for the Adjustor appear to have x86_64 bits. If you felt up to it, it would be a good way to learn about ghc internals. Feel free to ask questions on the mailing list, we'll help as much as possible. Sounds interesting, at the moment I just want to get an unregistered build going. I've followed the instructions to the letter. After adding an x86_64-* entry to config.sub in gmp I get the following on the target: copying ./mpn/generic/gcdext.c to mpn/gcdext.c copying ./mpn/generic/tdiv_qr.c to mpn/tdiv_qr.c copying ./mpn/generic/bz_divrem_n.c to mpn/bz_divrem_n.c copying ./mpn/generic/sb_divrem_mn.c to mpn/sb_divrem_mn.c copying ./mpn/generic/jacbase.c to mpn/jacbase.c copying ./mpn/generic/gmp-mparam.h to gmp-mparam.h gmake: *** No rule to make target `AutoApply.hc', needed by `depend'. Stop. gmake: Leaving directory `/home/kmacy/ghc-6.2.2/ghc/rts' The makefile indicates that genapply is called for, but it isn't there, oddly enough the one on the host failed initially: [EMAIL PROTECTED] ./ghc/utils/genapply/genapply genapply: internal error: stg_ap_v_ret Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ but when I rebuilt it it worked - I then copied that over - Then I got complaints about all the *_hsc.c files missing in the libraries - hoping that the compiler itself didn't need them I just touched those files so the build could continue - the same occurred for .o files under base/control ... Am I way off track or is building an unregistered target just really unfriendly? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
x86_64 port
Sorry if this is a RTFM type question - but what is the status of the x86_64 port? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
kip.macy: Sorry if this is a RTFM type question - but what is the status of the x86_64 port? As it says on http://www.haskell.org/ghc/docs/latest/html/building/sec-port-info.html it currently works unregisterised (and is available in binary form on a number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. I'm new to Haskell but not to assembler - is the work required something that someone in my position could contribute to? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
kip.macy: number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. I'm new to Haskell but not to assembler - is the work required something that someone in my position could contribute to? Certainly. Not much Haskell is required at all, and only some assembler. The porting guide contains a list of what needs to be done: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html Much of this is done already. Simon Marlow's done the register mapping (ghc/includes/MachRegs.h) and done other registerisation work. There was a bug in gcc-3.3x that halted things for a while, but this has been fixed in 6.4 Most stuff can be figured out by looking at the code for other archs already in the relevant files. The FFI for example just requires a few dozen lines of assembly. If you felt up to it, it would be a good way to learn about ghc internals. Feel free to ask questions on the mailing list, we'll help as much as possible. Cheers, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
