Yasm within MPIR

[Jean-Pierre Flori]

Dear all,

I'm currently working on some pieces of the build system.
I must admit I don't really like the fact that MPIR ships a modified yasm source tree.
I think it would be cleaner, and easier to maintain, to ship a tarball and untar it, or to the least a vanilla source tree, possibly patch it and  then configure/build it if needed (i already added options to use a system-wide or user-provided yasm, when autotools are used at least).
A little like what we do in Sage when we patch upstream software (like MPIR!).

Do you really need to pass specific options to yasm? or a "generic" (./configure && make) build would do?
That's important because the main modification I see is to let the autotools stuff recognize options given to MPIr and automatically passed to yasm.

My other question is about the VS builds because I never tried them and feel completely incompetent.
With VS, is yasm always built? Is it possible to let VS untar something? or does yasm directory have to be uncompressed?

Best,
JP

[Jean-Pierre Flori]

Bonus question: what are the differences betwen the x86 and x86w dirs (and subdirs) (and x86_64 and x86_64w dirs (and subdirs))?

On plain x86, is it only the asm syntax?
So that YASM gets used everywhere for the x86w dir, whereas GNU as gets also used for the x86 dir?
(And for x86_64w I guess the very nice idea of having different ABI on Linux and Windows also comes into play...)

I could have a look myself, but I'm sure some of you can give a very nice explanation!

Thanks in advance,
Best,

JP

Additional bonus question: among the mingw flavours, which are supported (or known to work)? I mean among legacy mingw(32), i686-w64-mingw and x86_64-w64-mingw?
From very quick testing, I'd say the latter (kind of) work, the middle one does not, and I did not test the first one (Ubuntu does not want to install both falvours at the same time! it seems that Debian is nicer though).

[Bill Hart]

On 31 July 2013 18:24, Jean-Pierre Flori <jpf...@gmail.com> wrote:

Dear all,

I'm currently working on some pieces of the build system.
I must admit I don't really like the fact that MPIR ships a modified yasm source tree.
I think it would be cleaner, and easier to maintain, to ship a tarball and untar it, or to the least a vanilla source tree, possibly patch it and  then configure/build it if needed (i already added options to use a system-wide or user-provided yasm, when autotools are used at least).

This should be possible. As far as I know the Windows MSVC build uses a precompiled yasm, not the one in the tree, so everything should be fine if yasm is built separately.

The downside is that GMP builds out-of-the-box without requiring one to download a separate assembler. I would abandon yasm for *nix if it were not for the fact that it is much easier for Brian Gladman to convert *nix assembler to Windows format if it is already in Yasm format (Intel format assembler is much more popular that AT&T format on Windows, I believe).

 

A little like what we do in Sage when we patch upstream software (like MPIR!).

Do you really need to pass specific options to yasm? or a "generic" (./configure && make) build would do?

I believe some options are necessarily passed to Yasm.

 

That's important because the main modification I see is to let the autotools stuff recognize options given to MPIr and automatically passed to yasm.

I think the options are not the same as the ones passed to MPIR. But it is such a long time since I worked on this, I don't recall the details.

 

My other question is about the VS builds because I never tried them and feel completely incompetent.
With VS, is yasm always built?

As far as I recall, the user downloads a special version of Yasm maintained by Peter Tortall, installs that in a certain location on their Windows, then builds MPIR in Visual Studio.

Bill.

Is it possible to let VS untar something? or does yasm directory have to be uncompressed?

Best,
JP

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
To post to this group, send email to mpir-...@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bill Hart]

On 31 July 2013 21:06, Jean-Pierre Flori <jpf...@gmail.com> wrote:

Bonus question: what are the differences betwen the x86 and x86w dirs (and subdirs) (and x86_64 and x86_64w dirs (and subdirs))?

The w is for Windows. The ABI is different, so all the assembly needs to be rewritten.

 

On plain x86, is it only the asm syntax?

I don't recall. I doubt it.

 

So that YASM gets used everywhere for the x86w dir, whereas GNU as gets also used for the x86 dir?

Yes.

 

(And for x86_64w I guess the very nice idea of having different ABI on Linux and Windows also comes into play...)

Yes.

 

I could have a look myself, but I'm sure some of you can give a very nice explanation!

Thanks in advance,
Best,

JP

Additional bonus question: among the mingw flavours, which are supported (or known to work)? I mean among legacy mingw(32), i686-w64-mingw and x86_64-w64-mingw?
From very quick testing, I'd say the latter (kind of) work, the middle one does not, and I did not test the first one (Ubuntu does not want to install both falvours at the same time! it seems that Debian is nicer though).

None are supported or known to work. They keep breaking it, every single version.

Bill.

[Jean-Pierre Flori]

On Wednesday, July 31, 2013 11:28:02 PM UTC+2, Bill Hart wrote:

On 31 July 2013 21:06, Jean-Pierre Flori <jpf...@gmail.com> wrote:

Bonus question: what are the differences betwen the x86 and x86w dirs (and subdirs) (and x86_64 and x86_64w dirs (and subdirs))?

The w is for Windows.

Yup I got that :)

The ABI is different, so all the assembly needs to be rewritten.

 

On plain x86, is it only the asm syntax?

I don't recall. I doubt it.

 

From the very few things I read, it seemed the x86 syntax was similar (or you could choose a common one at least among the several available ones...), but I may be wrong obviously...
 

So that YASM gets used everywhere for the x86w dir, whereas GNU as gets also used for the x86 dir?

Yes.

 

(And for x86_64w I guess the very nice idea of having different ABI on Linux and Windows also comes into play...)

Yes.

 

I could have a look myself, but I'm sure some of you can give a very nice explanation!

Thanks in advance,
Best,

JP

Additional bonus question: among the mingw flavours, which are supported (or known to work)? I mean among legacy mingw(32), i686-w64-mingw and x86_64-w64-mingw?
From very quick testing, I'd say the latter (kind of) work, the middle one does not, and I did not test the first one (Ubuntu does not want to install both falvours at the same time! it seems that Debian is nicer though).

None are supported or known to work. They keep breaking it, every single version.

Ok, that's clear.

So you should be happy to now that building a 64 bits MPIR with mingw64 seems to produced something usable!

[Jean-Pierre Flori]

On Wednesday, July 31, 2013 11:26:04 PM UTC+2, Bill Hart wrote:

On 31 July 2013 18:24, Jean-Pierre Flori <jpf...@gmail.com> wrote:

Dear all,

I'm currently working on some pieces of the build system.
I must admit I don't really like the fact that MPIR ships a modified yasm source tree.
I think it would be cleaner, and easier to maintain, to ship a tarball and untar it, or to the least a vanilla source tree, possibly patch it and  then configure/build it if needed (i already added options to use a system-wide or user-provided yasm, when autotools are used at least).

This should be possible. As far as I know the Windows MSVC build uses a precompiled yasm, not the one in the tree, so everything should be fine if yasm is built separately.

The downside is that GMP builds out-of-the-box without requiring one to download a separate assembler. I would abandon yasm for *nix if it were not for the fact that it is much easier for Brian Gladman to convert *nix assembler to Windows format if it is already in Yasm format (Intel format assembler is much more popular that AT&T format on Windows, I believe).

I didnot mean to not ship Yasm anymore, rather to ship a vanilla one, either through a tarball or through a source tree (as of now, but without modification if possible).
Then updating Yasm would be trivial (ok, you might have to rename a tarball/directory, or modify a string somewhere).
 

 

A little like what we do in Sage when we patch upstream software (like MPIR!).

Do you really need to pass specific options to yasm? or a "generic" (./configure && make) build would do?

I believe some options are necessarily passed to Yasm.

With the current setup everything is passed verbatim ... whence the need to modify yasm build system, because the vanilla build system will error out if unrecognized option (let's say --enable-gmpcompat) are passed.

It's possible to make it so that the top level configure option are discarded when going into a subdir.
It's more of an hack than a real option of autotools but should avoid to modify yasm build system.
That's what I had in mind and why I was asking if there were situation where option passed to the main configure script were really relevant to yasm (from what I've seen it's not the case, on the contrary we have to modify yasm so that it lives with MPIR superfluous options).

 

That's important because the main modification I see is to let the autotools stuff recognize options given to MPIr and automatically passed to yasm.

I think the options are not the same as the ones passed to MPIR. But it is such a long time since I worked on this, I don't recall the details.

 

My other question is about the VS builds because I never tried them and feel completely incompetent.
With VS, is yasm always built?

As far as I recall, the user downloads a special version of Yasm maintained by Peter Tortall, installs that in a certain location on their Windows, then builds MPIR in Visual Studio.

That would be good news for me!
(Though it seems that building MPIR under VS is harder than on Linux!)
 

[degski]

"Though it seems that building MPIR under VS is harder than on Linux!"

I'll try and help you out.

0. Install VS.

1. Install yasm following the instructions on the yasm home-page.

3. Goto MPIR-homepage and download tar-ball.

4. Get 7zip, install and extract tar-ball in convenient location.

5. Fire-up VS.

6. Open sln-file in build folder of MPIR-source.

7. Select config you would like, debug/release, Win32, x64.

8. Build, wait 1 minute.

9. Enjoy.

It hardly can get any easier than that.

Thanks Brian for all your hard work!

--

Sign the petition: https://optin.stopwatching.us/

[Brian Gladman]

As Bill has said, I can confirm that YASM is not a part of MPIR on
Windows. The user has to download and install VSYASM from the YASM site
in order to build MPIR on Windows.

The source code routines in the x86w and x86_64w directories are either
original code or translations of the routines in x86 and x86_64. These
routines are designed to work using the full Windows ABI including the
Windows x64 exception handling specification, which YASM fully supports.

Brian Gladman

[Jean-Pierre Flori]

On Thursday, August 1, 2013 8:39:12 AM UTC+2, degski wrote:

"Though it seems that building MPIR under VS is harder than on Linux!"

I'll try and help you out.

0. Install VS.

1. Install yasm following the instructions on the yasm home-page.

3. Goto MPIR-homepage and download tar-ball.

4. Get 7zip, install and extract tar-ball in convenient location.

5. Fire-up VS.

6. Open sln-file in build folder of MPIR-source.

7. Select config you would like, debug/release, Win32, x64.

8. Build, wait 1 minute.

9. Enjoy.

It hardly can get any easier than that.

No harm meant, I was just kidding "you have to download two files rather than one".

[Jean-Pierre Flori]

On Thursday, August 1, 2013 8:56:38 AM UTC+2, Cactus wrote:

On 31/07/2013 18:24, Jean-Pierre Flori wrote:
> Dear all,
>
> I'm currently working on some pieces of the build system.
> I must admit I don't really like the fact that MPIR ships a modified yasm
> source tree.
> I think it would be cleaner, and easier to maintain, to ship a tarball and
> untar it, or to the least a vanilla source tree, possibly patch it and  
> then configure/build it if needed (i already added options to use a
> system-wide or user-provided yasm, when autotools are used at least).
> A little like what we do in Sage when we patch upstream software (like
> MPIR!).
>
> Do you really need to pass specific options to yasm? or a "generic"
> (./configure && make) build would do?
> That's important because the main modification I see is to let the
> autotools stuff recognize options given to MPIr and automatically passed to
> yasm.
>
> My other question is about the VS builds because I never tried them and
> feel completely incompetent.
> With VS, is yasm always built? Is it possible to let VS untar something? or
> does yasm directory have to be uncompressed?

As Bill has said, I can confirm that YASM is not a part of MPIR on
Windows.  The user has to download and install VSYASM from the YASM site
in order to build MPIR on Windows.

Good news!
That will simplify things.
 

The source code routines in the x86w and x86_64w directories are either
original code or translations of the routines in x86 and x86_64.  These
routines are designed to work using the full Windows ABI including the
Windows x64 exception handling specification, which YASM fully supports.

I didn't think at first of the exception handling mechanism, thanks for the hint!
Is there anything similar on x86?

Best,
JP

[Brian Gladman]

I am afraid that I can't off much help on x86 exception handling as I
haven't used it for some time now.

However the x64 model was a radical departure from what went before it
and was designed to provide much more reliable stack reconstruction
after both intended and unintended exceptions. It also requires that
more complex functions that use the stack do so in a closely defined way
with specific prologue and epilogue code sections that are registered as
meta data in the executable.

This makes x64 assembler code for Windows significantly different to
that on Unix/Linux when support for exception handling is implemented.
The Visual Studio/YASM combination fully supports this but I don't know
what the situation is with mingw64 (its possible that it does).

Brian