On Nov 13, 2006, at 6:54 AM, Simon Marlow wrote:
Peter Tanski wrote:
... to both MASM and IAS (Intel ASsembler), with some special
attention to linker differences between the two.
There are other free assemblers that we can use, e.g. NASM.
Before I replied, I looked into NASM and--especially considering that
some of the assembler manuals I had been reading were written for
NASM--was disappointed to find the generally low level of development
or support for NASM of late: the most recent update to NASM was in
January 2005 and some apparently serious bugs have sat on the task
list since that time. Other free assemblers that might be useful are
* High Level Assembler (HLA), at <http://webster.cs.ucr.edu/AsmTools/
HLA/index.html>, which seems to have enough "high level" constructs
to upgrade the nativeGen optimisations without developing a MD-Cmm
language;
* Flat Assembler (FASM), at <http://flatassembler.net/>, which is
reputed to be very fast with a minimum of command line options; and,
* YASM, at <http://www.tortall.net/projects/yasm/>, a rewrite of NASM
with a BSD license, nearly complete support for parsing GNU AS (GAS)
syntax, and support for COFF, Win32 and Win64 object formats, among
others.
Do you have any ideas as to which one you would like to target most,
or would you prefer a "portable" assembler syntax in the NCG and
change which actual assembler you use in the driver (possibly as a
command-line option)?
* Task point 4: modifications to driver, build system, etc.
I was referring to the driver that is now part of GHC itself;
basically the code that invokes the various external processes that
form part of the compilation pipeline.
Quite right. I mentioned Perl because I was considering parts of
Windows that would require external support, absent minGW or cygwin
tools.
build system: small but pervasive modifications for compiler
dependencies, etc.; as a general cleanup matter it might be nice
to organise these sorts of dependencies to add other compilers
later.
The main issue I see is getting the RTS built. We already build it
using GHC as the compiler, but we'll certainly need to feed it
different flags when GHC is invoking CL.EXE. Also there's the .obj
vs. .o issue. Some work will be required in Cabal, too - assuming
that by the time we get around to doing this the libraries will be
building using Cabal.
Definitely. At least Cabal is already good at handling Windows
directories.
... cross-compiler option
Ideally I'd like to refactor the native code generator to separate
out all the architecture-specific stuff into separate files, and
make it possible to compile in more than one backend at the same
time (we might even compile in all of them by default).
That would be great. Task #989's modifications to the x86 portion of
the code alone would seem to require multiple versions simultaneously
(without chopping the rest out during preprocessing), so it might be
a good idea to refactor as a preliminary step.
By the way, I made some of my notes readable and general, as a start
to the new Commentary NCG page. There are more to come...
Cheers,
Peter Tanski
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
