Peter Tanski wrote:
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)?
I like the look of YASM. In fact, using YASM we wouldn't have to make many
changes to the NCG pretty printer, because it understands GAS syntax, right? At
the least, this shortens the path to getting something working, even if it isn't
the final solution.
* 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.
Windows-native GHC won't require Perl, because it is using the NCG only. Perl
would only be required for the splitter, but I imagine we'll be generating DLLs
so splitting won't be an issue.
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...
Thanks, I took a quick look and it looks great!
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
