From samuel.thibault at ens-lyon.org Fri Oct 3 12:24:05 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Fri, 3 Oct 2008 21:24:05 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: <20081001003532.GF4623@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> Message-ID: <20081003192405.GA4595@implementation.famille.thibault.fr> Hello, Resending the mail, as it looks like the big patch didn't get through... Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : > Attached is a first revision of patch that adds TASM support to yasm. I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > It does so by adding a tasm frontend which accepts tasm compatible > options and set the tasm_compatible_mode flag, which activates a lot > of extensions, notably: > > - case insensitive symbols and filenames, > - support for segment and size of labels, which permits to avoid giving > them on each memory dereference, > - support for data reservation (i.e. e.g. "var dd ?"), > - support for multiples (i.e. e.g. "var dd 1 dup 10"), > - little endian string integer constants, > - additional expression operators: shl, shr, and, or, low, high, > - additional offset keyword, > - additional fword and df, > - support for doubled quotes within quotes, > - support for array-like and structure-like notations: t[eax] and > [var].field, > - support for tasm directives: macro, rept, irp, locals, proc, struc, > segment, assume. > > Notes: > > - almost all extensions are only effective when tasm_compatible_mode is > set, so we should have very reduced possible breakage. > > - Because e.g. the "and" keyword can be an expression operator and an > instruction name, I had to make the data pseudo-instructions explicitely > switch the lexer state to INSTRUCTION state to fix the ambiguity. > > - For now, exe support is just through a hack in the tasm frontend, > using the bin objfmt to actually do the long work. Should I rather > create a dosfmt module that does the same? There's also an issue of the > bin-objfmt performing an fseek() which would overwrite what my exe code > outputs as exe header, thus the ugly hack which of course shouldn't get > commited as such. I'm not sure how I should handle that. > > - We already discussed a bit some time ago: in gen_x86_insn.py, I'm > making the lds & such and lea relaxed. The reason is that in the case > of tasm, the size of the actual pointed data is passed up to there, and > thus any type of data should be accepted. > > With all of this, loadlin can be compiled by yasm with quite reduced > modifications. Samuel From peter at tortall.net Fri Oct 3 13:15:50 2008 From: peter at tortall.net (Peter Johnson) Date: Fri, 3 Oct 2008 13:15:50 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081003192405.GA4595@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: This is a truly amazing amount of work! Thank you! It will take me a little while to read through the whole patch. I've only done a quick glance-through, but a couple minor improvements: - Add a "tasm" parser keyword by adding a yasm_tasm_LTX_parser structure and related functions to nasm-parser.c (or add a new tasm-parser.c which does; naturally the init function should set tasm_compatible_mode). In the long term it may make more sense to separate out the two parsers completely, although I know there's a lot of shared code. But ideally I'd like "yasm -p tasm" to work in addition to just "tasm". - Add a modules/parsers/tasm/tests directory with some small demonstration tests (I'm sure you have these as you've been writing this, so it'd be good to get them into the regression test suite). - Let me know what the key changes you made to the frontend code for the "tasm" frontend. I'd like to refactor out a lot of the common code shared between yasm and tasm frontends. - I should be able to fix the lds thing more directly. Thanks for mentioning it. - Yes, a dosfmt output format would be the best approach. The lightestweight way to do this would be to add the bits to objfmts/bin and add a yasm_dosfmt_LTX_objfmt structure w/unique init function. See objfmts/elf for an example of how to do this (e.g. elf/elf32/elf64 are all implemented as separate structures). Again, thank you for all this work! Great job! Peter On Fri, 3 Oct 2008, Samuel Thibault wrote: > Resending the mail, as it looks like the big patch didn't get through... > > Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : >> Attached is a first revision of patch that adds TASM support to yasm. > > I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > >> It does so by adding a tasm frontend which accepts tasm compatible >> options and set the tasm_compatible_mode flag, which activates a lot >> of extensions, notably: >> >> - case insensitive symbols and filenames, >> - support for segment and size of labels, which permits to avoid giving >> them on each memory dereference, >> - support for data reservation (i.e. e.g. "var dd ?"), >> - support for multiples (i.e. e.g. "var dd 1 dup 10"), >> - little endian string integer constants, >> - additional expression operators: shl, shr, and, or, low, high, >> - additional offset keyword, >> - additional fword and df, >> - support for doubled quotes within quotes, >> - support for array-like and structure-like notations: t[eax] and >> [var].field, >> - support for tasm directives: macro, rept, irp, locals, proc, struc, >> segment, assume. >> >> Notes: >> >> - almost all extensions are only effective when tasm_compatible_mode is >> set, so we should have very reduced possible breakage. >> >> - Because e.g. the "and" keyword can be an expression operator and an >> instruction name, I had to make the data pseudo-instructions explicitely >> switch the lexer state to INSTRUCTION state to fix the ambiguity. >> >> - For now, exe support is just through a hack in the tasm frontend, >> using the bin objfmt to actually do the long work. Should I rather >> create a dosfmt module that does the same? There's also an issue of the >> bin-objfmt performing an fseek() which would overwrite what my exe code >> outputs as exe header, thus the ugly hack which of course shouldn't get >> commited as such. I'm not sure how I should handle that. >> >> - We already discussed a bit some time ago: in gen_x86_insn.py, I'm >> making the lds & such and lea relaxed. The reason is that in the case >> of tasm, the size of the actual pointed data is passed up to there, and >> thus any type of data should be accepted. >> >> With all of this, loadlin can be compiled by yasm with quite reduced >> modifications. > > Samuel > _______________________________________________ > yasm-devel mailing list > yasm-devel at tortall.net > http://cvs.tortall.net/mailman/listinfo/yasm-devel > From peter at tortall.net Fri Oct 3 16:00:36 2008 From: peter at tortall.net (Peter Johnson) Date: Fri, 3 Oct 2008 16:00:36 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081003192405.GA4595@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: A few more comments, should be relatively minor cleanups, all related to trying to move tasm_compatible_mode checks out of other parts of yasm: - In the symtab changes, can we instead add a case-sensitivity flag to symtab, set it in tasm mode, and then use that flag in the various functions instead of looking directly at tasm_compatible_mode? I'd prefer to make things like this more generic and not look directly at tasm_compatible_mode. - In the same vein, I don't think it's necessary to conditionalize the change in insn.c; shouldn't ea->data_len=0 in non-tasm mode anyway? - In intnum.c can we put the new code in a new function (e.g. yasm_intnum_create_charconst_tasm) instead of if'ing in the existing _nasm version? (and then call the appropriate version in the parser). - I need to think about how to do the change to x86bc.c more cleanly. Can this lookup be performed by the parser after this function returns so x86 doesn't have to look at tasm_compatible_mode? yasm_arch_ea_create is only called from two places in nasm-parse.c; and a helper function could be added locally there to do this (note yasm_x86__parse_check_regtmod is also available as yasm_arch_parse_check_regtmod from the parser). Ignore my earlier comment about frontends/nasm; it looks like the code is more independent than I first thought. Thanks, Peter On Fri, 3 Oct 2008, Samuel Thibault wrote: > Hello, > > Resending the mail, as it looks like the big patch didn't get through... > > Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : >> Attached is a first revision of patch that adds TASM support to yasm. > > I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > >> It does so by adding a tasm frontend which accepts tasm compatible >> options and set the tasm_compatible_mode flag, which activates a lot >> of extensions, notably: >> >> - case insensitive symbols and filenames, >> - support for segment and size of labels, which permits to avoid giving >> them on each memory dereference, >> - support for data reservation (i.e. e.g. "var dd ?"), >> - support for multiples (i.e. e.g. "var dd 1 dup 10"), >> - little endian string integer constants, >> - additional expression operators: shl, shr, and, or, low, high, >> - additional offset keyword, >> - additional fword and df, >> - support for doubled quotes within quotes, >> - support for array-like and structure-like notations: t[eax] and >> [var].field, >> - support for tasm directives: macro, rept, irp, locals, proc, struc, >> segment, assume. >> >> Notes: >> >> - almost all extensions are only effective when tasm_compatible_mode is >> set, so we should have very reduced possible breakage. >> >> - Because e.g. the "and" keyword can be an expression operator and an >> instruction name, I had to make the data pseudo-instructions explicitely >> switch the lexer state to INSTRUCTION state to fix the ambiguity. >> >> - For now, exe support is just through a hack in the tasm frontend, >> using the bin objfmt to actually do the long work. Should I rather >> create a dosfmt module that does the same? There's also an issue of the >> bin-objfmt performing an fseek() which would overwrite what my exe code >> outputs as exe header, thus the ugly hack which of course shouldn't get >> commited as such. I'm not sure how I should handle that. >> >> - We already discussed a bit some time ago: in gen_x86_insn.py, I'm >> making the lds & such and lea relaxed. The reason is that in the case >> of tasm, the size of the actual pointed data is passed up to there, and >> thus any type of data should be accepted. >> >> With all of this, loadlin can be compiled by yasm with quite reduced >> modifications. > > Samuel > _______________________________________________ > yasm-devel mailing list > yasm-devel at tortall.net > http://cvs.tortall.net/mailman/listinfo/yasm-devel > From samuel.thibault at ens-lyon.org Sat Oct 4 18:16:46 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 03:16:46 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: <20081005011646.GQ11612@const.famille.thibault.fr> Hello, Thanks for the prompt quick review! I have updated the patch on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm to address your proposed cleanups. As for the test cases, actually I have just tested with my old programs and loadlin. I'll try to extract the few relevant bits. About adding a "tasm" parser, that will require adding it to quite a lot of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it ok? Samuel From peter at tortall.net Sat Oct 4 23:43:50 2008 From: peter at tortall.net (Peter Johnson) Date: Sat, 4 Oct 2008 23:43:50 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005011646.GQ11612@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have updated the patch on > http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > to address your proposed cleanups. Thanks, much improved! Comments on this version: 1) Should the double-quote thing in string constants be legal in NASM syntax as well? That's the way it's currently written, but I've not tested NASM recently to see if it handles this in the same way. 2) In x86expr.c, instead of using tasm_compatible_mode, add a new YASM_WARN flag for this (errwarn.h), default it to enabled (errwarn.c), and disable it in the tasm parser, and then use it for this warning instead of YASM_WARN_GENERAL. 3) This is a big task, so I'm not asking you to do it (it's more of an observation), but in the long run might it be better for the tasm preproc to be separate (or maybe tightly integrated with the tasm parser?), rather than a thin vaneer over the nasm preproc? > As for the test cases, actually I have just tested with my old programs > and loadlin. I'll try to extract the few relevant bits. Great. Note you'll want to add a "-p tasm" to that execution line, as out_test.sh always runs the "yasm" frontend. > About adding a "tasm" parser, that will require adding it to quite a lot > of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it > ok? There's a lot lower impact way to do this: - Add X86_PARSER_TASM to the enum in x86arch.h (line 83) - Setting it in x86arch.c (line 74 or so) for the "tasm" parser. - Update the switch statement in x86id.c (~line 1733) to use the nasm find function. While you could update the "invalid displacement size" warning to use this flag in x86expr.c, this is fairly high impact (as currently x86_effaddr doesn't know about the parser setting). A better option is my #2 above. I think this is getting really close to committable. Great job! Thanks, Peter From peter at tortall.net Sat Oct 4 23:50:37 2008 From: peter at tortall.net (Peter Johnson) Date: Sat, 4 Oct 2008 23:50:37 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: On Sat, 4 Oct 2008, Peter Johnson wrote: > On Sun, 5 Oct 2008, Samuel Thibault wrote: >> About adding a "tasm" parser, that will require adding it to quite a lot >> of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it >> ok? > > There's a lot lower impact way to do this: > - Add X86_PARSER_TASM to the enum in x86arch.h (line 83) > - Setting it in x86arch.c (line 74 or so) for the "tasm" parser. > - Update the switch statement in x86id.c (~line 1733) to use the nasm find > function. To clarify the last bullet: add a X86_PARSER_TASM case to that switch which acts the same as the X86_PARSER_NASM case (e.g. calls the nasm find function). Peter From samuel.thibault at ens-lyon.org Sun Oct 5 05:50:22 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 14:50:22 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: <20081005125022.GJ4808@const.famille.thibault.fr> Peter Johnson, le Sat 04 Oct 2008 23:43:50 -0700, a ?crit : > There's a lot lower impact way to do this: Ah, that's much simpler indeed :) I have updated the patch on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm I'm now working on extracting the test cases. Samuel From peter at tortall.net Sun Oct 5 11:01:53 2008 From: peter at tortall.net (Peter Johnson) Date: Sun, 5 Oct 2008 11:01:53 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005125022.GJ4808@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> <20081005125022.GJ4808@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have updated the patch on > http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > > I'm now working on extracting the test cases. Also, it looks like the patch doesn't have tasmlib.c/h in it (maybe you didn't svn add these?). With the exception of the tasm_compatible_mode check in section.c (which could get moved up another level to the frontend, or maybe a yasm_symtab_set_case_sensitive function could be added and called from the tasm parser), I think libyasm itself now doesn't have any tasm_compatible_mode checks, so we may be able to localize that variable (which I believe is all tasmlib.c/h adds?) to the parser/preproc? Thanks, Peter From samuel.thibault at ens-lyon.org Sun Oct 5 14:13:18 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 23:13:18 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: <20081005211318.GE4982@const.famille.thibault.fr> I have dropped tasmlib indeed, and added some testcases, again on http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm Samuel From peter at tortall.net Sun Oct 5 22:11:08 2008 From: peter at tortall.net (Peter Johnson) Date: Sun, 5 Oct 2008 22:11:08 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005211318.GE4982@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have dropped tasmlib indeed, and added some testcases, again on > http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm Looks great! Anything else you want to take care of before I commit this? Peter From samuel.thibault at ens-lyon.org Mon Oct 6 00:56:31 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 6 Oct 2008 09:56:31 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> Message-ID: <20081006075631.GA5713@const.bordeaux.inria.fr> Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : > On Sun, 5 Oct 2008, Samuel Thibault wrote: > >I have dropped tasmlib indeed, and added some testcases, again on > >http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm > > Looks great! Anything else you want to take care of before I commit this? It's fine for me. Samuel From samuel.thibault at ens-lyon.org Mon Oct 6 13:51:25 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 6 Oct 2008 22:51:25 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: <20081006075631.GA5713@const.bordeaux.inria.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: <20081006205125.GD5898@const.famille.thibault.fr> Samuel Thibault, le Mon 06 Oct 2008 09:56:31 +0200, a ?crit : > Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : > > On Sun, 5 Oct 2008, Samuel Thibault wrote: > > >I have dropped tasmlib indeed, and added some testcases, again on > > >http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > > > > Looks great! Anything else you want to take care of before I commit this? > > It's fine for me. Note: I've updated the patch to drop a useless hunk and fix comments about big/little endian charconsts. Samuel From peter at tortall.net Wed Oct 8 21:47:14 2008 From: peter at tortall.net (Peter Johnson) Date: Wed, 8 Oct 2008 21:47:14 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081006075631.GA5713@const.bordeaux.inria.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: On Mon, 6 Oct 2008, Samuel Thibault wrote: > Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : >> Looks great! Anything else you want to take care of before I commit this? > > It's fine for me. Just to close out this thread; the patch was committed in r2030, with various minor fixups committed thereafter. Thanks for all your hard work on this! Any future plans? -Peter From samuel.thibault at ens-lyon.org Wed Oct 8 23:35:04 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Thu, 9 Oct 2008 08:35:04 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: <20081009063504.GA4909@const.bordeaux.inria.fr> Peter Johnson, le Wed 08 Oct 2008 21:47:14 -0700, a ?crit : > Just to close out this thread; the patch was committed in r2030, with > various minor fixups committed thereafter. I have seen that, thanks! > Any future plans? Release Lenny, for now :) But there are a few things that I'd like to fix in the future, notably mov a,1 a db 1 which currently doesn't work because at the point of mov we don't know yet whether `a' is a label or an equ. Samuel From peter at tortall.net Thu Oct 9 00:01:25 2008 From: peter at tortall.net (Peter Johnson) Date: Thu, 9 Oct 2008 00:01:25 -0700 (PDT) Subject: ANNC: Yasm 0.7.2 Message-ID: I'm pleased to announce the availability of Yasm 0.7.2. This is primarily a bugfix release. Note: The recently committed TASM basic syntax support and frontend contributed by Samuel Thibault is not in this release; it will be in the 0.8.0 feature release. Please download a recent snapshot if you want to try it out (bug reports welcome!). Changes from 0.7.1 to 0.7.2 include: - Add PIC support to 64-bit Mach-O (#141). - Add --prefix and --suffix options for naming globals (#132). - Make "rel foo wrt ..gotpc" generate GOTPCREL in elf64 (alias for "rel foo wrt ..gotpcrel"). - Add support for newly specified AVX/AES instructions not in original spec (VAES* and 256-bit VMOVNT{PS,PD,DQ}). - Remove invalid 256-bit form of VPBLENDVB. - Optimize non-strict push with 66h override to byte size if possible. - Fix address printing in bin map file. - Fix GAS syntax handling of no section flags (#148). - Name the absolute symbol in coff/win32/win64 output (#153). - Miscellaneous other fixes. Changes from 0.7.0 to 0.7.1 included: - AVX instruction bugfixes (0.7.0 errata) - Build fixes (crashes on some machines) - Minor CPU flags fixes Changes from 0.6.2 to 0.7.0 included: - Intel Advanced Vector Extensions (AVX) instruction support. - Multi-section binary support in the NASM style (see #71, #99, [2010]). - Add support for ELF32 and ELF64 TLS (thread local storage) relocations. - Allow use of 0X in addition to 0x to prefix hex constants (#127). - Allow underscores in hex, binary, and octal constants (e.g. 0111_1111b) - Fix memory sizes on SSE/SSE2 instructions (#119). - Allow standalone prefixes (#122). - Simplify new varieties of sym-sym values (#124). - Support SAFESEH directive for win32 SEH handlers (#130). - Enable sym at FOO constructs in GAS parser. - SSE5 condition code support. - Other bugfixes. Known issues with this release can be found in the Yasm Trac ticket system. Release Notes for 0.7.2: http://www.tortall.net/projects/yasm/wiki/Release0.7.2 Downloads from the Yasm website include .tar.gz source (for Unix systems) and Win64, Win32, CygWin, and DOS executables: http://www.tortall.net/projects/yasm/wiki/Download Please download, test, and tinker, and most importantly, send comments and bug reports! Thanks to all those who submitted bug reports and contributed code for this release. Special thanks go to Mark Charney of Intel for AVX review. More developers are always welcome to join us. Thanks, Peter Johnson and the other Yasm developers From samuel.thibault at ens-lyon.org Fri Oct 3 12:24:05 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Fri, 3 Oct 2008 21:24:05 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: <20081001003532.GF4623@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> Message-ID: <20081003192405.GA4595@implementation.famille.thibault.fr> Hello, Resending the mail, as it looks like the big patch didn't get through... Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : > Attached is a first revision of patch that adds TASM support to yasm. I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > It does so by adding a tasm frontend which accepts tasm compatible > options and set the tasm_compatible_mode flag, which activates a lot > of extensions, notably: > > - case insensitive symbols and filenames, > - support for segment and size of labels, which permits to avoid giving > them on each memory dereference, > - support for data reservation (i.e. e.g. "var dd ?"), > - support for multiples (i.e. e.g. "var dd 1 dup 10"), > - little endian string integer constants, > - additional expression operators: shl, shr, and, or, low, high, > - additional offset keyword, > - additional fword and df, > - support for doubled quotes within quotes, > - support for array-like and structure-like notations: t[eax] and > [var].field, > - support for tasm directives: macro, rept, irp, locals, proc, struc, > segment, assume. > > Notes: > > - almost all extensions are only effective when tasm_compatible_mode is > set, so we should have very reduced possible breakage. > > - Because e.g. the "and" keyword can be an expression operator and an > instruction name, I had to make the data pseudo-instructions explicitely > switch the lexer state to INSTRUCTION state to fix the ambiguity. > > - For now, exe support is just through a hack in the tasm frontend, > using the bin objfmt to actually do the long work. Should I rather > create a dosfmt module that does the same? There's also an issue of the > bin-objfmt performing an fseek() which would overwrite what my exe code > outputs as exe header, thus the ugly hack which of course shouldn't get > commited as such. I'm not sure how I should handle that. > > - We already discussed a bit some time ago: in gen_x86_insn.py, I'm > making the lds & such and lea relaxed. The reason is that in the case > of tasm, the size of the actual pointed data is passed up to there, and > thus any type of data should be accepted. > > With all of this, loadlin can be compiled by yasm with quite reduced > modifications. Samuel From peter at tortall.net Fri Oct 3 13:15:50 2008 From: peter at tortall.net (Peter Johnson) Date: Fri, 3 Oct 2008 13:15:50 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081003192405.GA4595@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: This is a truly amazing amount of work! Thank you! It will take me a little while to read through the whole patch. I've only done a quick glance-through, but a couple minor improvements: - Add a "tasm" parser keyword by adding a yasm_tasm_LTX_parser structure and related functions to nasm-parser.c (or add a new tasm-parser.c which does; naturally the init function should set tasm_compatible_mode). In the long term it may make more sense to separate out the two parsers completely, although I know there's a lot of shared code. But ideally I'd like "yasm -p tasm" to work in addition to just "tasm". - Add a modules/parsers/tasm/tests directory with some small demonstration tests (I'm sure you have these as you've been writing this, so it'd be good to get them into the regression test suite). - Let me know what the key changes you made to the frontend code for the "tasm" frontend. I'd like to refactor out a lot of the common code shared between yasm and tasm frontends. - I should be able to fix the lds thing more directly. Thanks for mentioning it. - Yes, a dosfmt output format would be the best approach. The lightestweight way to do this would be to add the bits to objfmts/bin and add a yasm_dosfmt_LTX_objfmt structure w/unique init function. See objfmts/elf for an example of how to do this (e.g. elf/elf32/elf64 are all implemented as separate structures). Again, thank you for all this work! Great job! Peter On Fri, 3 Oct 2008, Samuel Thibault wrote: > Resending the mail, as it looks like the big patch didn't get through... > > Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : >> Attached is a first revision of patch that adds TASM support to yasm. > > I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > >> It does so by adding a tasm frontend which accepts tasm compatible >> options and set the tasm_compatible_mode flag, which activates a lot >> of extensions, notably: >> >> - case insensitive symbols and filenames, >> - support for segment and size of labels, which permits to avoid giving >> them on each memory dereference, >> - support for data reservation (i.e. e.g. "var dd ?"), >> - support for multiples (i.e. e.g. "var dd 1 dup 10"), >> - little endian string integer constants, >> - additional expression operators: shl, shr, and, or, low, high, >> - additional offset keyword, >> - additional fword and df, >> - support for doubled quotes within quotes, >> - support for array-like and structure-like notations: t[eax] and >> [var].field, >> - support for tasm directives: macro, rept, irp, locals, proc, struc, >> segment, assume. >> >> Notes: >> >> - almost all extensions are only effective when tasm_compatible_mode is >> set, so we should have very reduced possible breakage. >> >> - Because e.g. the "and" keyword can be an expression operator and an >> instruction name, I had to make the data pseudo-instructions explicitely >> switch the lexer state to INSTRUCTION state to fix the ambiguity. >> >> - For now, exe support is just through a hack in the tasm frontend, >> using the bin objfmt to actually do the long work. Should I rather >> create a dosfmt module that does the same? There's also an issue of the >> bin-objfmt performing an fseek() which would overwrite what my exe code >> outputs as exe header, thus the ugly hack which of course shouldn't get >> commited as such. I'm not sure how I should handle that. >> >> - We already discussed a bit some time ago: in gen_x86_insn.py, I'm >> making the lds & such and lea relaxed. The reason is that in the case >> of tasm, the size of the actual pointed data is passed up to there, and >> thus any type of data should be accepted. >> >> With all of this, loadlin can be compiled by yasm with quite reduced >> modifications. > > Samuel > _______________________________________________ > yasm-devel mailing list > yasm-devel at tortall.net > http://cvs.tortall.net/mailman/listinfo/yasm-devel > From peter at tortall.net Fri Oct 3 16:00:36 2008 From: peter at tortall.net (Peter Johnson) Date: Fri, 3 Oct 2008 16:00:36 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081003192405.GA4595@implementation.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: A few more comments, should be relatively minor cleanups, all related to trying to move tasm_compatible_mode checks out of other parts of yasm: - In the symtab changes, can we instead add a case-sensitivity flag to symtab, set it in tasm mode, and then use that flag in the various functions instead of looking directly at tasm_compatible_mode? I'd prefer to make things like this more generic and not look directly at tasm_compatible_mode. - In the same vein, I don't think it's necessary to conditionalize the change in insn.c; shouldn't ea->data_len=0 in non-tasm mode anyway? - In intnum.c can we put the new code in a new function (e.g. yasm_intnum_create_charconst_tasm) instead of if'ing in the existing _nasm version? (and then call the appropriate version in the parser). - I need to think about how to do the change to x86bc.c more cleanly. Can this lookup be performed by the parser after this function returns so x86 doesn't have to look at tasm_compatible_mode? yasm_arch_ea_create is only called from two places in nasm-parse.c; and a helper function could be added locally there to do this (note yasm_x86__parse_check_regtmod is also available as yasm_arch_parse_check_regtmod from the parser). Ignore my earlier comment about frontends/nasm; it looks like the code is more independent than I first thought. Thanks, Peter On Fri, 3 Oct 2008, Samuel Thibault wrote: > Hello, > > Resending the mail, as it looks like the big patch didn't get through... > > Samuel Thibault, le Wed 01 Oct 2008 02:35:32 +0200, a ?crit : >> Attached is a first revision of patch that adds TASM support to yasm. > > I've put it on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > >> It does so by adding a tasm frontend which accepts tasm compatible >> options and set the tasm_compatible_mode flag, which activates a lot >> of extensions, notably: >> >> - case insensitive symbols and filenames, >> - support for segment and size of labels, which permits to avoid giving >> them on each memory dereference, >> - support for data reservation (i.e. e.g. "var dd ?"), >> - support for multiples (i.e. e.g. "var dd 1 dup 10"), >> - little endian string integer constants, >> - additional expression operators: shl, shr, and, or, low, high, >> - additional offset keyword, >> - additional fword and df, >> - support for doubled quotes within quotes, >> - support for array-like and structure-like notations: t[eax] and >> [var].field, >> - support for tasm directives: macro, rept, irp, locals, proc, struc, >> segment, assume. >> >> Notes: >> >> - almost all extensions are only effective when tasm_compatible_mode is >> set, so we should have very reduced possible breakage. >> >> - Because e.g. the "and" keyword can be an expression operator and an >> instruction name, I had to make the data pseudo-instructions explicitely >> switch the lexer state to INSTRUCTION state to fix the ambiguity. >> >> - For now, exe support is just through a hack in the tasm frontend, >> using the bin objfmt to actually do the long work. Should I rather >> create a dosfmt module that does the same? There's also an issue of the >> bin-objfmt performing an fseek() which would overwrite what my exe code >> outputs as exe header, thus the ugly hack which of course shouldn't get >> commited as such. I'm not sure how I should handle that. >> >> - We already discussed a bit some time ago: in gen_x86_insn.py, I'm >> making the lds & such and lea relaxed. The reason is that in the case >> of tasm, the size of the actual pointed data is passed up to there, and >> thus any type of data should be accepted. >> >> With all of this, loadlin can be compiled by yasm with quite reduced >> modifications. > > Samuel > _______________________________________________ > yasm-devel mailing list > yasm-devel at tortall.net > http://cvs.tortall.net/mailman/listinfo/yasm-devel > From samuel.thibault at ens-lyon.org Sat Oct 4 18:16:46 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 03:16:46 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: <20081005011646.GQ11612@const.famille.thibault.fr> Hello, Thanks for the prompt quick review! I have updated the patch on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm to address your proposed cleanups. As for the test cases, actually I have just tested with my old programs and loadlin. I'll try to extract the few relevant bits. About adding a "tasm" parser, that will require adding it to quite a lot of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it ok? Samuel From peter at tortall.net Sat Oct 4 23:43:50 2008 From: peter at tortall.net (Peter Johnson) Date: Sat, 4 Oct 2008 23:43:50 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005011646.GQ11612@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have updated the patch on > http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > to address your proposed cleanups. Thanks, much improved! Comments on this version: 1) Should the double-quote thing in string constants be legal in NASM syntax as well? That's the way it's currently written, but I've not tested NASM recently to see if it handles this in the same way. 2) In x86expr.c, instead of using tasm_compatible_mode, add a new YASM_WARN flag for this (errwarn.h), default it to enabled (errwarn.c), and disable it in the tasm parser, and then use it for this warning instead of YASM_WARN_GENERAL. 3) This is a big task, so I'm not asking you to do it (it's more of an observation), but in the long run might it be better for the tasm preproc to be separate (or maybe tightly integrated with the tasm parser?), rather than a thin vaneer over the nasm preproc? > As for the test cases, actually I have just tested with my old programs > and loadlin. I'll try to extract the few relevant bits. Great. Note you'll want to add a "-p tasm" to that execution line, as out_test.sh always runs the "yasm" frontend. > About adding a "tasm" parser, that will require adding it to quite a lot > of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it > ok? There's a lot lower impact way to do this: - Add X86_PARSER_TASM to the enum in x86arch.h (line 83) - Setting it in x86arch.c (line 74 or so) for the "tasm" parser. - Update the switch statement in x86id.c (~line 1733) to use the nasm find function. While you could update the "invalid displacement size" warning to use this flag in x86expr.c, this is fairly high impact (as currently x86_effaddr doesn't know about the parser setting). A better option is my #2 above. I think this is getting really close to committable. Great job! Thanks, Peter From peter at tortall.net Sat Oct 4 23:50:37 2008 From: peter at tortall.net (Peter Johnson) Date: Sat, 4 Oct 2008 23:50:37 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: On Sat, 4 Oct 2008, Peter Johnson wrote: > On Sun, 5 Oct 2008, Samuel Thibault wrote: >> About adding a "tasm" parser, that will require adding it to quite a lot >> of places, e.g. everywhere in ./modules/arch/x86/gen_x86_insn.py, is it >> ok? > > There's a lot lower impact way to do this: > - Add X86_PARSER_TASM to the enum in x86arch.h (line 83) > - Setting it in x86arch.c (line 74 or so) for the "tasm" parser. > - Update the switch statement in x86id.c (~line 1733) to use the nasm find > function. To clarify the last bullet: add a X86_PARSER_TASM case to that switch which acts the same as the X86_PARSER_NASM case (e.g. calls the nasm find function). Peter From samuel.thibault at ens-lyon.org Sun Oct 5 05:50:22 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 14:50:22 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> Message-ID: <20081005125022.GJ4808@const.famille.thibault.fr> Peter Johnson, le Sat 04 Oct 2008 23:43:50 -0700, a ?crit : > There's a lot lower impact way to do this: Ah, that's much simpler indeed :) I have updated the patch on http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm I'm now working on extracting the test cases. Samuel From peter at tortall.net Sun Oct 5 11:01:53 2008 From: peter at tortall.net (Peter Johnson) Date: Sun, 5 Oct 2008 11:01:53 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005125022.GJ4808@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005011646.GQ11612@const.famille.thibault.fr> <20081005125022.GJ4808@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have updated the patch on > http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > > I'm now working on extracting the test cases. Also, it looks like the patch doesn't have tasmlib.c/h in it (maybe you didn't svn add these?). With the exception of the tasm_compatible_mode check in section.c (which could get moved up another level to the frontend, or maybe a yasm_symtab_set_case_sensitive function could be added and called from the tasm parser), I think libyasm itself now doesn't have any tasm_compatible_mode checks, so we may be able to localize that variable (which I believe is all tasmlib.c/h adds?) to the parser/preproc? Thanks, Peter From samuel.thibault at ens-lyon.org Sun Oct 5 14:13:18 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sun, 5 Oct 2008 23:13:18 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> Message-ID: <20081005211318.GE4982@const.famille.thibault.fr> I have dropped tasmlib indeed, and added some testcases, again on http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm Samuel From peter at tortall.net Sun Oct 5 22:11:08 2008 From: peter at tortall.net (Peter Johnson) Date: Sun, 5 Oct 2008 22:11:08 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081005211318.GE4982@const.famille.thibault.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> Message-ID: On Sun, 5 Oct 2008, Samuel Thibault wrote: > I have dropped tasmlib indeed, and added some testcases, again on > http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm Looks great! Anything else you want to take care of before I commit this? Peter From samuel.thibault at ens-lyon.org Mon Oct 6 00:56:31 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 6 Oct 2008 09:56:31 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> Message-ID: <20081006075631.GA5713@const.bordeaux.inria.fr> Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : > On Sun, 5 Oct 2008, Samuel Thibault wrote: > >I have dropped tasmlib indeed, and added some testcases, again on > >http://dept-info.labri.fr/~thibault/tmp/pkatch-yasm-tasm > > Looks great! Anything else you want to take care of before I commit this? It's fine for me. Samuel From samuel.thibault at ens-lyon.org Mon Oct 6 13:51:25 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 6 Oct 2008 22:51:25 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: <20081006075631.GA5713@const.bordeaux.inria.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: <20081006205125.GD5898@const.famille.thibault.fr> Samuel Thibault, le Mon 06 Oct 2008 09:56:31 +0200, a ?crit : > Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : > > On Sun, 5 Oct 2008, Samuel Thibault wrote: > > >I have dropped tasmlib indeed, and added some testcases, again on > > >http://dept-info.labri.fr/~thibault/tmp/patch-yasm-tasm > > > > Looks great! Anything else you want to take care of before I commit this? > > It's fine for me. Note: I've updated the patch to drop a useless hunk and fix comments about big/little endian charconsts. Samuel From peter at tortall.net Wed Oct 8 21:47:14 2008 From: peter at tortall.net (Peter Johnson) Date: Wed, 8 Oct 2008 21:47:14 -0700 (PDT) Subject: [PATCH,RFC] TASM support In-Reply-To: <20081006075631.GA5713@const.bordeaux.inria.fr> References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: On Mon, 6 Oct 2008, Samuel Thibault wrote: > Peter Johnson, le Sun 05 Oct 2008 22:11:08 -0700, a ?crit : >> Looks great! Anything else you want to take care of before I commit this? > > It's fine for me. Just to close out this thread; the patch was committed in r2030, with various minor fixups committed thereafter. Thanks for all your hard work on this! Any future plans? -Peter From samuel.thibault at ens-lyon.org Wed Oct 8 23:35:04 2008 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Thu, 9 Oct 2008 08:35:04 +0200 Subject: [PATCH,RFC] TASM support In-Reply-To: References: <20081001003532.GF4623@implementation.famille.thibault.fr> <20081003192405.GA4595@implementation.famille.thibault.fr> <20081005211318.GE4982@const.famille.thibault.fr> <20081006075631.GA5713@const.bordeaux.inria.fr> Message-ID: <20081009063504.GA4909@const.bordeaux.inria.fr> Peter Johnson, le Wed 08 Oct 2008 21:47:14 -0700, a ?crit : > Just to close out this thread; the patch was committed in r2030, with > various minor fixups committed thereafter. I have seen that, thanks! > Any future plans? Release Lenny, for now :) But there are a few things that I'd like to fix in the future, notably mov a,1 a db 1 which currently doesn't work because at the point of mov we don't know yet whether `a' is a label or an equ. Samuel From peter at tortall.net Thu Oct 9 00:01:25 2008 From: peter at tortall.net (Peter Johnson) Date: Thu, 9 Oct 2008 00:01:25 -0700 (PDT) Subject: ANNC: Yasm 0.7.2 Message-ID: I'm pleased to announce the availability of Yasm 0.7.2. This is primarily a bugfix release. Note: The recently committed TASM basic syntax support and frontend contributed by Samuel Thibault is not in this release; it will be in the 0.8.0 feature release. Please download a recent snapshot if you want to try it out (bug reports welcome!). Changes from 0.7.1 to 0.7.2 include: - Add PIC support to 64-bit Mach-O (#141). - Add --prefix and --suffix options for naming globals (#132). - Make "rel foo wrt ..gotpc" generate GOTPCREL in elf64 (alias for "rel foo wrt ..gotpcrel"). - Add support for newly specified AVX/AES instructions not in original spec (VAES* and 256-bit VMOVNT{PS,PD,DQ}). - Remove invalid 256-bit form of VPBLENDVB. - Optimize non-strict push with 66h override to byte size if possible. - Fix address printing in bin map file. - Fix GAS syntax handling of no section flags (#148). - Name the absolute symbol in coff/win32/win64 output (#153). - Miscellaneous other fixes. Changes from 0.7.0 to 0.7.1 included: - AVX instruction bugfixes (0.7.0 errata) - Build fixes (crashes on some machines) - Minor CPU flags fixes Changes from 0.6.2 to 0.7.0 included: - Intel Advanced Vector Extensions (AVX) instruction support. - Multi-section binary support in the NASM style (see #71, #99, [2010]). - Add support for ELF32 and ELF64 TLS (thread local storage) relocations. - Allow use of 0X in addition to 0x to prefix hex constants (#127). - Allow underscores in hex, binary, and octal constants (e.g. 0111_1111b) - Fix memory sizes on SSE/SSE2 instructions (#119). - Allow standalone prefixes (#122). - Simplify new varieties of sym-sym values (#124). - Support SAFESEH directive for win32 SEH handlers (#130). - Enable sym at FOO constructs in GAS parser. - SSE5 condition code support. - Other bugfixes. Known issues with this release can be found in the Yasm Trac ticket system. Release Notes for 0.7.2: http://www.tortall.net/projects/yasm/wiki/Release0.7.2 Downloads from the Yasm website include .tar.gz source (for Unix systems) and Win64, Win32, CygWin, and DOS executables: http://www.tortall.net/projects/yasm/wiki/Download Please download, test, and tinker, and most importantly, send comments and bug reports! Thanks to all those who submitted bug reports and contributed code for this release. Special thanks go to Mark Charney of Intel for AVX review. More developers are always welcome to join us. Thanks, Peter Johnson and the other Yasm developers