Peter Tanski wrote:
On Dec 14, 2006, at 6:19 AM, Simon Marlow wrote:
Peter Tanski wrote:
I tracked down the cause of the problem with the .comment section.
It was not caused by Yasm and will not cause a problem with the MS
tools.
This all looks good, thanks for investigating Peter. The Windows
native port gets a step closer!
The latest build of Yasm, yasm-r1712 is patched and works fine with
ghc. For the record, here is the download link:
http://cvs.tortall.net/projects/yasm/snapshots/r1712/ (use yasm-
r1712-dos ; yasm-r1712 crashes--looking into it.)
As part of testing Yasm, I looked at the next step for the Windows
native port: building and testing GHC using Yasm as the assembler,
which may benefit from changing the option flags in compiler/main/
DriverPipeline.hs and compiler/main/DynFlags.hs . I would like to
change the flags to:
(1) move the hard-coded option parameters for 'runPhase As ...' in
DriverPipeline.hs into separate option sets in DynFlags.hs --that way
you only have to look in one place to change the hard-coded options
(or, in this case, to code them conditionally under a preprocessor
define USE_YASM);
(2) include parameters for Yasm ("-ax86", "-pgas", "-fwin32"); and,
(3) include Yasm as a configuration option (--enable-yasm).
An alternative implementation would be to add a special command line
option, --yasm, to enable use of yasm, although this would require
Makefile changes both for building and testing, in the same way as
using --pgma, --opta ... to use Yasm as is. What do you think?
For the native Windows port, we should have a new target, probably
i386-unknown-win32 or i386-unknown-windows. Then we can have an option in
config.mk to control whether YASM is used, $(UseYASM), which would be on by
default for windows_TARGET_OS. Later we might want to make it a configure
option, but for now I'd leave it as a build.mk option.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
