[opensuse-programming] Which assembler ?
Which assembler do I pick for i386 and x86_64 ? I see a few different ones out there - nasm, gas, yasm, lzasm, fasm, probably many others too. I am a long-time TASM user, and very familiar with it, and I have a lot of code around written for TASM. yasm is supposed to be able to mimick tasm, but last I tried it didn't work very well or support was very limited. If it wasn't for TASMs obvious lack of support for anything that happened after 1998, I would still be using that, but I really need a modern assembler. If I have to learn new format, so be it. Any recommendations? I've been taking some baby steps with nasm, but I'm not overly impressed with it sofar. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Wed, Dec 30, 2009 at 07:01:28PM +0100, Per Jessen wrote:
Which assembler do I pick for i386 and x86_64 ? I see a few different ones out there - nasm, gas, yasm, lzasm, fasm, probably many others too. I am a long-time TASM user, and very familiar with it, and I have a lot of code around written for TASM. yasm is supposed to be able to mimick tasm, but last I tried it didn't work very well or support was very limited. If it wasn't for TASMs obvious lack of support for anything that happened after 1998, I would still be using that, but I really need a modern assembler. If I have to learn new format, so be it. Any recommendations? I've been taking some baby steps with nasm, but I'm not overly impressed with it sofar.
I'm not really familiar with yasm, lzasm or fasm, but I personally use this rule of thumb: (i) If I have bunch of Intel-syntax assembler source I need to compile, or I need to do something very raw, I use nasm. (ii) Otherwise, I use gas. I think these two projects are most likely to never fall out of maintenance and continue gaining support for whatever new architectures and instructions coming by (especially gas is virtually guaranteed to stay alive as long as GNU/Linux does), and they are usually installed on any Linux with a development toolchain, so I wonder what compelling advantages the other assemblers have. gas uses very different syntax from what the Intel assembly hackers are used to, but it's worth learning it - you will gain access to assembly of pretty much any architecture out there, you can use the integrated assembly support in gcc, you can read gdb's disass output, etc etc. -- Petr "Pasky" Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Petr Baudis wrote:
On Wed, Dec 30, 2009 at 07:01:28PM +0100, Per Jessen wrote:
Which assembler do I pick for i386 and x86_64 ? [snip]
I'm not really familiar with yasm, lzasm or fasm, but I personally use this rule of thumb:
(i) If I have bunch of Intel-syntax assembler source I need to compile, or I need to do something very raw, I use nasm.
(ii) Otherwise, I use gas.
I think these two projects are most likely to never fall out of maintenance and continue gaining support for whatever new architectures and instructions coming by (especially gas is virtually guaranteed to stay alive as long as GNU/Linux does),
Continued support and in particular development would be important for my decision too, yes.
and they are usually installed on any Linux with a development toolchain, so I wonder what compelling advantages the other assemblers have.
I have not yet gathered sufficient experience with any of the others, only TASM (for the i386 platform), but because I might be rewriting many tens-of-thousands lines of code, productivity is important, i.e. I want an assembler that supports more than just the odd function written in assembler.
gas uses very different syntax from what the Intel assembly hackers are used to, but it's worth learning it - you will gain access to assembly of pretty much any architecture out there, you can use the integrated assembly support in gcc, you can read gdb's disass output, etc etc.
Okay, thanks. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 12/30/2009 02:45 PM, Per Jessen wrote:
Petr Baudis wrote:
On Wed, Dec 30, 2009 at 07:01:28PM +0100, Per Jessen wrote:
Which assembler do I pick for i386 and x86_64 ?
[snip]
I'm not really familiar with yasm, lzasm or fasm, but I personally use this rule of thumb:
(i) If I have bunch of Intel-syntax assembler source I need to compile, or I need to do something very raw, I use nasm.
(ii) Otherwise, I use gas.
I think these two projects are most likely to never fall out of maintenance and continue gaining support for whatever new architectures and instructions coming by (especially gas is virtually guaranteed to stay alive as long as GNU/Linux does),
Continued support and in particular development would be important for my decision too, yes.
and they are usually installed on any Linux with a development toolchain, so I wonder what compelling advantages the other assemblers have.
I have not yet gathered sufficient experience with any of the others, only TASM (for the i386 platform), but because I might be rewriting many tens-of-thousands lines of code, productivity is important, i.e. I want an assembler that supports more than just the odd function written in assembler.
gas uses very different syntax from what the Intel assembly hackers are used to, but it's worth learning it - you will gain access to assembly of pretty much any architecture out there, you can use the integrated assembly support in gcc, you can read gdb's disass output, etc etc.
Based on your comment about having to rewrite, I would recommend trying to find an assembler that support the macros and syntax you already have. I wouild probably also recommend gas because it is tightly bound to GCC. Would it be possible to convert some of those modules to C. Most C compilers support the ASM() directive. While there are certainly some very good reasons to write in assembler, with today's chips the need is much less. (Thankfully you don't have to convert it to IA64 assembler). -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
Jerry Feldman wrote:
Based on your comment about having to rewrite, I would recommend trying to find an assembler that support the macros and syntax you already have. I wouild probably also recommend gas because it is tightly bound to GCC.
I completely appreciate the gas argument, my only issue is that the gas syntax isn't exactly much like the TASM syntax :-(
Would it be possible to convert some of those modules to C. Most C compilers support the ASM() directive.
Certainly possible, but what would I gain? AFAICT, I'd still have a major rewrite to do. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 01/01/2010 08:49 AM, Per Jessen wrote:
Jerry Feldman wrote:
Based on your comment about having to rewrite, I would recommend trying to find an assembler that support the macros and syntax you already have. I wouild probably also recommend gas because it is tightly bound to GCC.
I completely appreciate the gas argument, my only issue is that the gas syntax isn't exactly much like the TASM syntax :-(
Would it be possible to convert some of those modules to C. Most C compilers support the ASM() directive.
Certainly possible, but what would I gain? AFAICT, I'd still have a major rewrite to do.
Fortunately, my assembler background is on IBM 370, Digital Alpha (I cowrote the assembler for NT and Unix), Motorola 68000, PDP-8, PDP-11, and IA64. The advantage of converting as much as you can to a higher level language is (1) improved readability and maintainability, (2) portability to other chips (i386/i686/x86_64, and others). Basically, if you have to go through the effort writing to C is probably a better way to go because the language is much more standard than assemblers as well as more portable. Certainly the effort needed to rewrite your TASM code is going to be significant especially as the chips continue to change and add more features/instructions. I think that NASM is probably your best bet for TASM compatibility to reduce the effort, but using a higher level language will allow you to take more advantage of the newer chip features. Assembly code is essentially locked into a chip's feature set, especially on the x86 family of chips morphing from the 16-bit 8086 to the 286->386->586->686->x86_64. Certainly code designed for i386 will run on the higher level CPUs. So, in any case, you have a major rewrite, but consider where you want this code to go. Assuming that the code does not have to be written in assembler, then try to ascertain the effort to rewrite in NASM (relatively low) vs. GAS (relatively high), C (based on the code could in the same region as GAS). Another possibility is to write a TASM to GAS translator :-). BTW: One advantage of NASM is that it is open source, so at least if it is no longer maintained, you could own the source. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
Hello, On Fri, 01 Jan 2010, Jerry Feldman wrote:
On 01/01/2010 08:49 AM, Per Jessen wrote:
Jerry Feldman wrote:
Based on your comment about having to rewrite, I would recommend trying to find an assembler that support the macros and syntax you already have. I wouild probably also recommend gas because it is tightly bound to GCC.
I completely appreciate the gas argument, my only issue is that the gas syntax isn't exactly much like the TASM syntax :-(
Would it be possible to convert some of those modules to C. Most C compilers support the ASM() directive.
Certainly possible, but what would I gain? AFAICT, I'd still have a major rewrite to do.
Fortunately, my assembler background is on IBM 370, Digital Alpha (I cowrote the assembler for NT and Unix), Motorola 68000, PDP-8, PDP-11, and IA64. The advantage of converting as much as you can to a higher level language is (1) improved readability and maintainability, (2) portability to other chips (i386/i686/x86_64, and others). Basically, if you have to go through the effort writing to C is probably a better way to go because the language is much more standard than assemblers as well as more portable. Certainly the effort needed to rewrite your TASM code is going to be significant especially as the chips continue to change and add more features/instructions. I think that NASM is probably your best bet for TASM compatibility to reduce the effort, but using a higher level language will allow you to take more advantage of the newer chip features. Assembly code is essentially locked into a chip's feature set, especially on the x86 family of chips morphing from the 16-bit 8086 to the 286->386->586->686->x86_64. Certainly code designed for i386 will run on the higher level CPUs. So, in any case, you have a major rewrite, but consider where you want this code to go. Assuming that the code does not have to be written in assembler, then try to ascertain the effort to rewrite in NASM (relatively low) vs. GAS (relatively high), C (based on the code could in the same region as GAS). Another possibility is to write a TASM to GAS translator :-). BTW: One advantage of NASM is that it is open source, so at least if it is no longer maintained, you could own the source.
I stumbled today over yasm, first mentioned here, then upon wanting to compile a current x264 lib. Grabbed the packman src.rpm[1], adapted the spec to my ancient SUSE 6.2 based system, and there we go (except my binutils being just not quite updated enough anyhow for x264, 2.16 is < 2.17, 6.2 shipped 2.10, various versions (2.14 as rpm) in between sulk in various nooks and crannies of the system. Oh well. ;) Oh, and I barely read few basic (Intel) assembler statements (e.g. for 'debug.com' on DOS ;) Anyway. I'd take YASM. Simply because it supports recent CPUs and NASM and GAS syntax. Read yourself[0]: http://www.tortall.net/projects/yasm/ Yasm is a complete rewrite of the NASM assembler [..] # Nearly feature-complete lexing and parsing of NASM syntax. # Basic support for TASM syntax. # Nearly feature-complete lexing and parsing of GAS (GNU assembler) syntax. Seems to me, to be a good "inbetween" to use while migrating ... And if it proves worthy ... No harm to keep using it, eh? And no, no "output asm in $dialect" feature. No help converting. But comparing the source of yasm's input-parsers might help solving problems. on the off chance: HTH, -dnh [0] Disclaimer: I'm no assembler guy. I know little more than to even _READ_ mov, push, pop, call, int and a few more in one or so dialects. [1] it's available in other OBS-Repos too -- Breathing in a full grown eucalyptus tree is something worth watching. Attaching inhalers to eucalyptus trees achieves little and annoys the trees. -- Geoff Lane in the SDM -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Fri, 1 Jan 2010 16:05:00 +0100, you wrote:
[1] it's available in other OBS-Repos too
Yeah, most prominently in its devel repo devel:tools:compiler/yasm and guess who maintains that repo? ;-))) But thanks for the indirect reminder. I've just updated yasm to the latest version 0.8.0 with the update for factory pending approval. Philipp -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Jerry Feldman wrote:
On 01/01/2010 08:49 AM, Per Jessen wrote:
Would it be possible to convert some of those modules to C. Most C compilers support the ASM() directive.
Certainly possible, but what would I gain? AFAICT, I'd still have a major rewrite to do.
Fortunately, my assembler background is on IBM 370,
Mine too. (MVS and TPF).
The advantage of converting as much as you can to a higher level language is (1) improved readability and maintainability, (2) portability to other chips (i386/i686/x86_64, and others).
Ah, yes, I agree (of course) - I thought you meant just wrapping the assembler code in C-functions, which didn't seem to give me much. A complete rewrite in C is not an option - the vast majority of this code does math and such, and is highly optimized/specialized/tweaked (no pipeline stalls etc).
Certainly the effort needed to rewrite your TASM code is going to be significant especially as the chips continue to change and add more features/instructions. I think that NASM is probably your best bet for TASM compatibility to reduce the effort, but using a higher level language will allow you to take more advantage of the newer chip features.
It seems to me that it's really the other way around? If I want to use e.g. SSEx efficiently, I have to use assembler. Anyway, I have in fact been playing quite a bit with NASM, and I am slowly warming to it. I'm just not so keen on the nasm core idea of simplicity, which is why I started researching the others.
Another possibility is to write a TASM to GAS translator :-).
Yeah, similar thoughts have in fact crossed my mind. yasm also has a new tasm-compatibility module, which I have very seriously considered working on/with. Thanks for your input. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Fri, Jan 01, 2010 at 07:27:49PM +0100, Per Jessen wrote:
A complete rewrite in C is not an option - the vast majority of this code does math and such, and is highly optimized/specialized/tweaked (no pipeline stalls etc).
Are you _sure_ that what was highly optimized in pentium times will perform better than C code optimized for a current processor? I suggest that you pick few routines and try to compare performance. Petr "Pasky" Baudis -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Petr Baudis wrote:
On Fri, Jan 01, 2010 at 07:27:49PM +0100, Per Jessen wrote:
A complete rewrite in C is not an option - the vast majority of this code does math and such, and is highly optimized/specialized/tweaked (no pipeline stalls etc).
Are you _sure_ that what was highly optimized in pentium times will
It has been kept up-to-date with modern architectures - we've stuck to tasm for as long as possible, and also 'enhanced' it with a few macros for support of newer instructions. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 01/01/2010 01:27 PM, Per Jessen wrote:
Ah, yes, I agree (of course) - I thought you meant just wrapping the assembler code in C-functions, which didn't seem to give me much.
A complete rewrite in C is not an option - the vast majority of this code does math and such, and is highly optimized/specialized/tweaked (no pipeline stalls etc). On 01/02/2010 04:11 AM, Per Jessen wrote: Petr Baudis wrote:
On Fri, Jan 01, 2010 at 07:27:49PM +0100, Per Jessen wrote:
A complete rewrite in C is not an option - the vast majority of this code does math and such, and is highly optimized/specialized/tweaked (no pipeline stalls etc).
Are you _sure_ that what was highly optimized in pentium times will
It has been kept up-to-date with modern architectures - we've stuck to tasm for as long as possible, and also 'enhanced' it with a few macros for support of newer instructions.
For the x86 series that strategy is ok, but you are running into dead ends. Hopefully, yasm will fill your needs. I would actually consider using FORTRAN. FORTRAN compilers today provide very good optimizations where C is more difficult to optimize. One possible test is to take a reletively small module, recode it in FORTRAN and C, aggressively optimize it and run some benchmark tests. While GCC is a good compiler, other commercial compilers, like Intel, take the same factors into account, such as latency and pipeline stalls. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
participants (5)
-
David Haller -
Jerry Feldman -
Per Jessen -
Petr Baudis -
Philipp Thomas