Port to gas
Jan Kratochvil
currently on GNU/Linux i686 + x86_64 libvpx requires yasm to build its
optimized code.
The code can be built using standard installed gas (part of the GNU Toolchain
/ binutils / GCC). yasm build dependency would require active maintenance of
yasm during ongoing executable file format changes (for example DWARF4).
Tried to import the branch to Gerrit but it can handle only a single patch.
These rename and global replace changes are better seen in a branch:
git clone git://dyn.jankratochvil.net/libvpx.git libvpx-gas
master-gas = master with this conversion
master-verify = master (on yasm) for correctness verification
Attached also as .patch.bz2.
The port is verified as safe (exactly matching `objdump -dr'). As yasm
creates in several cases longer instructions than the equivalent ones chosen
by gas master-verify is a master branch with few adjustments to produce
gas-like output while still being built by yasm.
Other i686 + x86_64 platforms are MS-Windows and Mac, gas should be available
on both and it seems to me libvpx already requires the GNU Toolchain there
anyway. I can fixup the port on these platforms (although volunteers are
welcome as I do not know these platforms).
There are many open questions how such port could be made. Currently I have
converted it only for GNU/Linux i686 + x86_64 keeping the Intel opcodes syntax
(gas -msyntax=intel -mnaked-reg) while using the gas mnemonics.
Some more cleanups could be done to make the code more native gas code
removing several #defines for yasm -> gas compatibility there now.
The code would be converted to the AT&T syntax (instr %src, %dest) to no
longer have to use -msyntax=intel -mnaked-reg. In such case it could be yasm
compatible again (not tested) but that probably would no longer be needed.
yasm -p gas -r cpp -f elf${bits}
Thanks for an opinion,
Jan
John Koleszar
<jan.kra...@redhat.com> wrote:
> Hi,
>
> currently on GNU/Linux i686 + x86_64 libvpx requires yasm to build its
> optimized code.
>
> The code can be built using standard installed gas (part of the GNU Toolchain
> / binutils / GCC). yasm build dependency would require active maintenance of
> yasm during ongoing executable file format changes (for example DWARF4).
>
If you have a new enough version of binutils. I don't fully understand
their versioning scheme, but it looks like support for the intel
syntax didn't land until 2.19.50, and 2.20 was first released in late
2009. Installing a standalone assembler is a lighter dependency than
having to upgrade binutils, so it's more advisable to support multiple
assemblers than cutting over wholesale. Also, visual studio support
(see below).
> Tried to import the branch to Gerrit but it can handle only a single patch.
> These rename and global replace changes are better seen in a branch:
> git clone git://dyn.jankratochvil.net/libvpx.git libvpx-gas
> master-gas = master with this conversion
> master-verify = master (on yasm) for correctness verification
> Attached also as .patch.bz2.
>
That's not exactly true. The gerrit model is you polish your patches
into logical changes, rather than applying fixups on top of fixups. If
you do regular small commits, you'd squash them into a logical change.
You can push a string of several dependent changes, it just means
getting familiar with rebase -i if you need to incorporate comments on
something earlier in the chain.
> The port is verified as safe (exactly matching `objdump -dr'). As yasm
> creates in several cases longer instructions than the equivalent ones chosen
> by gas master-verify is a master branch with few adjustments to produce
> gas-like output while still being built by yasm.
>
> Other i686 + x86_64 platforms are MS-Windows and Mac, gas should be available
> on both and it seems to me libvpx already requires the GNU Toolchain there
> anyway. I can fixup the port on these platforms (although volunteers are
> welcome as I do not know these platforms).
>
The GNU toolchain (gcc+binutils) isn't required on Windows. Visual
Studio is a supported compiler, though I curse it every day. GNU make,
bash, and similar coreutils are required for building from git, but
release snapshots can be built without any additional tools.
> There are many open questions how such port could be made. Currently I have
> converted it only for GNU/Linux i686 + x86_64 keeping the Intel opcodes syntax
> (gas -msyntax=intel -mnaked-reg) while using the gas mnemonics.
>
> Some more cleanups could be done to make the code more native gas code
> removing several #defines for yasm -> gas compatibility there now.
>
The goal of supporting multiple assemblers is a good one, so any port
should be done with an eye towards that rather than trying to become
the One True Assembler. Currently there are people using NASM instead
of YASM, and we should probably add support for this since it's so
trivial. Others are using MASM by preprocessing the YASM source and
there's something to be said for doing something like that upstream
for the Visual Studio crowd.
For supporting gas on x86, we could do something similar to what we do
on the ARM, where we preprocess the RVCT-style assembly into something
gas will accept. That might be an option since most of the assembly
makes little use of the preprocessor, perhaps duplicating
x86_abi_support for a gas version, or better yet moving some of the
yasm built-in definitions up into the build system, which should allow
the preprocessor usage to be simplified enough to be easily translated
from one syntax to the other.
Having a test script to verify the disassembly matches would probably
be a good thing to have, if we're going to start supporting multiple
assemblers. Sounds like you may have this already.
> The code would be converted to the AT&T syntax (instr %src, %dest) to no
> longer have to use -msyntax=intel -mnaked-reg. In such case it could be yasm
> compatible again (not tested) but that probably would no longer be needed.
> yasm -p gas -r cpp -f elf${bits}
>
>
Keeping the intel syntax is valuable since that's what most of the
people working on this code are most comfortable with, and it opens up
the door to using NASM and MASM. I don't think there's any
substantial advantage to changing to the AT&T syntax.
John
Jan Kratochvil
> If you have a new enough version of binutils. I don't fully understand
> their versioning scheme, but it looks like support for the intel
> syntax didn't land until 2.19.50, and 2.20 was first released in late
> 2009.
X.Y are official FSF GDB releases. X.Y.Z are unofficial (but mostly
considered as official) H.J.Lu's (currently in Intel) snapshots.
> The goal of supporting multiple assemblers is a good one, so any port
> should be done with an eye towards that rather than trying to become
> the One True Assembler.
OK. It probably does not make sense to continue trying to push the One True
GAS. Therefore going to adjust the patch to be multi-assembler capable.
> For supporting gas on x86, we could do something similar to what we do
> on the ARM, where we preprocess the RVCT-style assembly into something
> gas will accept.
I have seen it there but ...
> moving some of the yasm built-in definitions up into the build system, which
> should allow the preprocessor usage to be simplified enough to be easily
> translated from one syntax to the other.
... I had more this possibility on mind for the multi-assembler variant.
> Having a test script to verify the disassembly matches would probably
> be a good thing to have, if we're going to start supporting multiple
> assemblers. Sounds like you may have this already.
Yes, just a local hack, attached. I will possibly try to include it.
> I don't think there's any substantial advantage to changing to the AT&T
> syntax.
OK, understood, it depends on what the people are used to.
Thanks,
Jan
Timothy B. Terriberry
>> moving some of the yasm built-in definitions up into the build system, which
>> should allow the preprocessor usage to be simplified enough to be easily
>> translated from one syntax to the other.
>
> ... I had more this possibility on mind for the multi-assembler variant.
FWIW, we use a simple x86_abi_support_win32.asm to replace the default
x86_abi_support.asm when compiling for MASM:
http://hg.mozilla.org/mozilla-central/file/default/media/libvpx/vpx_ports/x86_abi_support_win32.asm
That combined with the yasm2masm scripts at
http://hg.mozilla.org/mozilla-central/file/default/media/libvpx is all
that's needed to compile for masm. Chris Pearce may be able to give you
more details on the process.
ch...@pearce.org.nz
This is a temporary solution until YASM is fixed and we can use YASM on Win32.
Chris P.
On Wed 23/06/10 5:50 AM , "Timothy B. Terriberry" tterr...@mozilla.com sent:
> --
> You received this message because you are subscribed to the Google Groups
> "Codec Developers" group.To post to this group, send email to c
> odec-...@webmproject.org.To unsubscribe from this group, send email to codec-devel+u
> nsubs...@webmproject.org.For more options, visit this group at http://groups.google.com/a/webmproject.org/group/codec-devel/?h
> l=en.
>
>
>
Dave Yeo
> Currently there are people using NASM instead
> of YASM, and we should probably add support for this since it's so
> trivial.
It would be nice if libvpx officially supported nasm as well as yasm as
there are platforms that only have nasm support.
Dave