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