Sven Moritz Hallberg
Mon, 29 Apr 2002 18:23:52 +0200
On Sun, Apr 28, 2002 at 07:10:35PM +0200, Wolfgang Thaller wrote:
> >I see there is already working support for Darwin. What will have to be
> >adjusted to get from powerpc-apple-darwin to powerpc-unknown-linux?
> Well, the first step should be to build an "unregistered" version -
Yes, I thought so, what does "unregistered" (or wasn't it
unregisterized?) mean exactly? That the intermediate C code doesn't
mention machine registers?
> if there has ever been a working LinuxPPC port (I don't know about
> any), this is easy.
No, there has not been a working port to LinuxPPC, as far as I can see.
But the mailing list archives showed some mails from 2000 or 2001 from
someone who was thinking of doing it.
> If not, you will need the intermediate .hc files
> generated by a working version of GHC on some other platform. I don't
> know how to do this, but there are people on this list who know more.
Good, this part is what I'm most interested in, because I don't think
I'll be able to create the port myself (I forgot to mention that I have
not only not much clue about PPC machine code, but assembly language in
general), but there might be others more knowledgable who could profit
from the availability of the information. And I'm curious.
> Basic unregistered support should be "relatively easy" to get to
> work, as LinuxPPC should not be too different from Linux/i386.
> Other things that [might] require porting are:
> createAdjustor: the implementation for foreign export dynamic. The
> Darwin/MacOS X implementation might work unchanged, that is, if
> LinuxPPC uses the same calling conventions.
No idea about LinuxPPC's calling convention. Where do I get an
authoritative answer? Kernel source (or docs) I guess...
> At this point we would have a fully functional haskell compiler that
> generates slow-running binaries.
> ghc-mangle: A hideous Perl script that does really bad things to
> assembly code in order to make it run faster :-). While I don't think
> that we can use the same code for Darwin and LinuxPPC, a lot of what
> I found out for the Darwin port can also be applied to Linux, so I'll
> be happy to share information.
OK, keep it to you for now, I probably wouldn't know what to make of
much of it.
> ghc-split: A smaller, but still evil Perl script that splits one
> assembly language file into many. This is not required, but it can
> make compiled programs smaller (unless I've misunderstood something).
> I haven't yet ported this for Darwin, as Apple's strange dynamic
> Linker makes things difficult. A port for LinuxPPC might be easier.
I would have to dive into assembly/machine language for that... not
enough time, I'm afraid.
> ghci: I think this requires a) a dynamic loader, and b) some haskell
> code to generate a few instructions of PPC machine language.
> There is already an ELF loader for x86, and b) is easy compared to a), IMHO.
Oh, too much machine-level for me! Dynamic loading: never looked under
the hood of that. A few instructions of PPC machine language: Erm, well,
currently I wouldn't know how to do anything in PPC assembly. But, while
you're at it, if you can point me someplace where I might learn it,
I'll still be glad to know.
> native code generator: not necessary except for improving compilation
> speed. A lot of work, but the same code can be used for Linux and
> Darwin. However, I don't think it is really worth the time...
> These are all parts that I know about. Building an unregistered
> version is most important, but I don't know enough to help with that.
Thank you for your time,
"Would the All-Seeing Eye please look in my direction?"
[ PGP KeyID: 0xC297FEAB ]