[PATCH,RFC] TASM support

Peter Johnson peter at tortall.net
Fri Oct 3 13:15:50 PDT 2008

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!


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

More information about the yasm-devel mailing list