NASM 0.98.39 vs. NASM 2.03.01 disassembly
in [ASM]
|
Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Wolfgang Kern on 3 Sep 2008 15:51 Herbert Kleebauer posted some examples... [...] Yeah, and I fully agree (except for your reg-numbering) ... Perhaps we missed the correct sentence to convince Rod on this facts. :):) ;doubled yet. wolfgang
From: Chuck Crayne on 3 Sep 2008 19:08 On Wed, 3 Sep 2008 09:47:15 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > "1. For all loads (regardless of source or destination sizing) only > bits 16-0 are used. Other bits are ignored." Other than the obvious typo, I think we all agree that this statement is correct. The discussion is about how to interpret it. You seem to be saying that "used" means "written" and "ignored" means "read and discarded". However the rest of us feel that "used" means "read", and that "ignored" means "not read". -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Rod Pemberton on 4 Sep 2008 10:39 "Chuck Crayne" <ccrayne(a)crayne.org> wrote in message news:20080903160844.5c5238b1(a)thor.crayne.org... > On Wed, 3 Sep 2008 09:47:15 -0400 > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > > > "1. For all loads (regardless of source or destination sizing) only > > bits 16-0 are used. Other bits are ignored." > > Other than the obvious typo, Typo? I don't see a typo. One must understand the dash "-" means "through". BTW, this was cut-n-paste from an Intel .pdf. So, if there is some "typo" it is Intel's, not mine as implied... > I think we all agree that this statement is > correct. The discussion is about how to interpret it. You seem to be > saying that "used" means "written" No, "read". > and "ignored" means "read and > discarded". Yes. > However the rest of us feel that "used" means > "read", Yes, as do I. > and that "ignored" means "not read". And, everyone seems to be ignoring the large clarification: "For all loads (regardless of source or destination sizing)" The important parts: "loads" "load" to me means a "read" of default register size. "regardless of ... source sizing" And, this clarifies that the load may be some size other than needed 16-bits. These together are Intel is saying that 32-bits are read for 32-bit mode. "only bits 16-0 are used. Other bits are ignored." Here, Intel is saying that even when 32-bits are read for 32-bit mode, only 16-bits are used by the instruction. I.e., the rest are discarded. Rod Pemberton
From: Frank Kotler on 4 Sep 2008 10:57 Jim Carlock wrote: > From: "Frank Kotler", Sent: Wednesday, September 03, 2008 1:47 PM > : (Merely out of curiosity, I'd like to see it done on an older processor. > : Doesn't "make sense" to me that it would read 32 bits, but maybe... I > : don't think "must make sense to Frank" is in Intel's design criteria... > : I'd bet on "error in manual"... but I wouldn't bet more than I could > : afford to lose...) > > Frank, > > Define "older processor". Well... 386 would be nice. Maybe 486... Rod posted those older manuals which clearly indicate that lar/lsl uses a 32-bit memory operand. They were dated, but didn't mention which specific processors they applied to. One of *them*. AFAIK, lar/lsl were introduced with 286. If anyone cares what a 286 does, test it there, too! (Won't be using a 32-bit operand, either reg or mem, so it isn't really relevant.) > An older (2004 IA-32 Intel Architecture Software > Developer's Manual, Volume 2A: Instruction Set Reference A-M, p. 3-402 to > 3-404) Intel book defines the following for the LAR instruction: > > <snip> > Real-Address Mode Exceptions > #UD The LAR instruction is not recognized in real-address mode. > > Virtual-8086 Mode Exceptions > #UD The LAR instruction cannot be executed in virtual-8086 mode. > </snip> Yeah, "access rights" aren't honored in real or vm86 modes anyway. Segment limit is... but what would you use for a selector??? > It appears that the 32-bit / 16-bit mode gets defined by either the source > register or the destination register. Mmmm, 32/16-bit mode is determined by a bit in the cs selector... > So we need to ask ourselves which one > represents the effective OPERAND? In the case of lar/lsl, the "effective" operand would be destination, since source is always 16 bits (I claim). > It's easy for the compiler to recognize > EAX and for it differentiate that from AX. And as far as I can tell, as no > 16-bit mode exists, the compiler should compare the operand sizes and issue > at least a warning about mismatched operand sizes. > > Am I correct and does the compiler do this? Well, that's the question. Is "lar eax, bx" mismatched? Is "lar eax, ebx"? (Nasm currently accepts both) > I am just trying to ask the > right question. This thread is actually about how it should be disassembled, but what an assembler will accept, and when to generate the operand size override prefix, is essentially the same question... > I'm not sure I've seen this instruction used anywhere. And > I do not know how to use it, where it gets used, and so on. Me neither. Damnedest thing to get into an extended argument over! But we *know* how to (dis)assemble "mov"... :) Best, Frank
From: Rod Pemberton on 4 Sep 2008 11:35
"Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:g9milg$vn1$1(a)aioe.org... > You asked > earlier in this thread if I believed this "just because Nasm64developer > said so". Yes, pretty much... Without identity I can't share your belief... > > PS. Who is Nasm64developer? > > I wish I could tell ya, but he wishes to remain anonymous. That's his personal choice. I respect that. But, his choice to be anonymous in a forum or newsgroup is very different to me from being anonymous in an open source project. In the later, he loses almost all credibility with me. There is no way to know if he's respectable or disreputable, etc. The crux is should an anonymous participant be allowed to have such a strong influence in an open source project? I for one can't confirm his identity, credentials, experience, or the even the Intel/AMD sources that he uses to justify his reasoning. He never provides this even when an explicit statement of or a quote from his source documents would be apropriate. A few things he has stated do indicate a non-neutral perspective IMO. I perceive a bias from him towards AMD documentation over Intel. Having followed the gmane indexing of the various NASM mail archives, for some time now. I've personally questioned various things he suggests. I'm not saying everything he suggests is bad, odd, or lunacy. Although, he does have an ability to over rationalize. Nor am I saying, he is out of step with the rest of the key NASM developers group as HPA has posted quite a few bad and odd ideas also. I'm just saying, where's the accountability when anonymity is involved? How can one accept his claims if they can't be rebutted since we know nothing about him or the sources he uses? How can one accept his claims if they can't be discussed as his decisions seem to be final, especially when it appears to be illogical or over rationalized? Rod Pemberton |