[PATCH,RFC] TASM support
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
- 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
>> - support for tasm directives: macro, rept, irp, locals, proc, struc,
>> segment, assume.
>> - 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
> yasm-devel mailing list
> yasm-devel at tortall.net
More information about the yasm-devel