Hi Tomasz!
I wanna discuss two things:
1) I found one bug in FASM:
following instructions don't cause error:
movq xmm1, mm0
movq mm1, xmm0

while only following variants are allowed (see IA-32 Intel® Architecture Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M):
movq mm1, mm0
movq xmm1, xmm0

2) And what do you think about symbolic mnemonics for OS and AS prefixes (66h and 67h) as well as for segment override prefixes (cs:, ds: and etc.)? And the same for branch hints prefixes (2eh and 3eh) that used with Jcc instructions (see IA-32 Intel® Architecture Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M, 2.1.1 Instruction Prefixes, page 2-2).

1) Thanks for the report, it's fixed now.

2) The mnemonic-like segment override prefixes are present since the very beginning of fasm.
For branch prefixes see http://board.flatassembler.net/topic.php?p=4547#4547
As for NASM-like O16 and O32, I mentioned them here: http://board.flatassembler.net/topic.php?t=5287, but I got no positive feedback.

Maybe is better to use something-like "O16 <instruction>" or "OS <instruction>"? OS - operand size, AS - address size, and for branch prefixes to define mnemonics like "BT" and "BNT", e.i. BT - branch taken, BNT - branch not taken.

BT is a mnemonic already, it's Bit Test

I think O16 and O32 are a pretty good idea. However, ut and lt stink. I'd suggest plain ol' YES and NO (or maybe JA, NEIN to avoid typical name collision...plus JA means Jmp if Above anyways).

<EDIT>
Doh, JA would conflict, wouldn't it? Oh well, maybe JES, NE ?
</EDIT>

Yes, BT is already used, ok.
I suggest using following mnemonics:
1) O16 and O32
2) A16 and A32
3) maybe including OS and AS, which will depend on current 16-bit or 32-bit code segment.
4) BHT and BHNT for branch hint prefixes.
see http://qc.borland.com/wc/qcmain.aspx?d=15548

I really don't understand why everyone so dislike the UT/LT
Anyway, since those are easily defined with equates, I don't feel it necessary to build them in - unless there comes some naming standard for them.
The notation I actually saw most frequently was HT/HNT.
(BTW: there was also a thread here about this: http://board.flatassembler.net/topic.php?t=5113 and I revived it, as I found another interesting thing about this topic, and that thread seems to be more appropriate to discuss it).

As for the O16/O32 - on one side, it would be nice as another compatibility with NASM; on the other, the fasm's point initially was that those prefixes shouldn't be actually needed, as the combinations of size specifiers should allow to make any variant of the instruction you need. Only recently it appeared (in that mentioned thread) that there are some (thought rare and not of crucial importance) problems with this approach. However I still prefer this over the O16/O32 notation, which is cryptic and may be sometimes misleading.

I like BHT/BHNT more than HT/HNT .

There was also a wide discussion in between most of the actual Assemblers Authors, at the time these came out. After some time, i choosed to "align" my choice on the one of one of the NASM developers, who was part of the discussion:

LTJ // UTJ

Unfortunately, the discussion, and my efforts to push to a common decision, so that all actual Assemblers could all share the same mnemonic, have been useless, and this choice has not even been implemented into NASM itself (!!!...).

It was, to me, my very _last_ attempt of ever trying to unicize anything, with guys who do not _want_ to unicize anything, not even for a so costless and un-important detail.


Betov.

I say we should have a vote.

P.S. Betov, you sure took long enough to post: your last post was in '04, almost two years ago! Glad you still occasionally read this forum, though.

offtopic: Betov as author of Rosasm?

Yes, "Betov, as...". I stopped posting anything, here, since Thomasz dishonored himself with compromising with Randall Hide. Nevertheless, on such a general interrest subject as defining a trivial Mnemonic, i keep in the opinion, that it would be of general interrest of having all of the actual Assemblers assuming a so low cost of "compatibility".


Betov.