----- Original Message -----
From: "Frank Kotler" <fbkotler@...>
To: "Ben Lunt" <fys@...>
Sent: Sunday, May 25, 2003 8:08 AM
Subject: Re: nasm / ndisasm
> Hi Ben,
> Hope you don't mind if I cc my reply to the "list" (Hi, List - anybody
> awake? :).
Hi Frank, Hi list.
> > Instructions not supported:
> > LFENCE 0F AE /5
> This is a "Willamette" instruction, and wouldn't have been in 0.98[bf].
> We've got it now.
> > MLFENCE 0F AE /6
> Got this as "MFENCE", not "MLFENCE" - I, or someone, will have to look
> into this.
Sorry, that was my fault. I copy pasted from the line above and forgot
to delete the L. MFENCE is correct.
> > SFENCE 0F AE /7
> This is KATMAI, and should be in 0.98 - although not documented :(
> > SMSW reg32 0F 01 /4
> Hmmm, if this exists, we haven't got it. I was under the impression that
> SMSW is one of those "always 16-bit" instructions (given reg32, will
> just use reg16 - no effect from a size override). We currently *only*
> allow reg16 for SMSW, and probably should allow reg32 also (doing the
> same thing). Have to look into this one, too.
The IA-32 vol2, page 3-709 (in the hardcopy any), it has the follow:
0F 01 /4 SMSW r/m16
0F 01 /4 SMSW r32/m16
However, it does say that the high 16-bits of the r32 are undifined, but
does allow a 32-bit register.
is used, nasm returns:
invalid combination of opcode and operand.
Unless I am wrong, and please tell me if I am, the above instruction
should be allowed, correct?
> > This is supported, but per the Intel Docs, it is supported wrong.
> > nasm/ndisasm current:
> > SYSEXIT 0F 36
> > should be
> > SYSEXIT 0F 35
> > per vol2 of the IA-32 docs.
> This one we *have* got fixed - just in time for 0.98.36.
> > If they have been fixed in a more recent version, I guess I will just
> > have to go to sf.com and get it :-)
> sf.net, yes. There *have* been a number of additions and bug-fixes since
> 0.98.bf, so if you're going to use Nasm as a "test" for Nbasm, it might
> be worthwhile to get the latest...
I will do just that.
> > P.S. Have you ever heard/read about the order of the 66h and 67h
> > prefixes? NBASM uses the order of 67h-66h, while NASM
> > uses the order of 66h-67h.
> > I don't think it matters, but if you have read it somewhere and the
> > document was worth reading, then maybe I will change it.
> I don't know where I read it (if anywhere), but I'm under the impression
> that it makes no difference which order the prefixes are encountered.
> Unless you're interested in "binary compatibility" with Nasm, I don't
> think it's worth changing. Although it might make it easier to spot
> "real" differences, if you're using Nasm as a "comparison"...
> Good to hear from you, Ben. Always nice to have another pair of eyes
> "checking up" on Nasm. Hope life is treating you well.
Very well, thank you, and wish the same to you.
Thanks for you comments,