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: Chuck Crayne on 7 Sep 2008 23:34 On Sun, 7 Sep 2008 21:37:30 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > Yes, you keep repeating that the manual is correct, but keep ignoring > this: _BOTH_ the current Intel and AMD manuals clearly indicates > syntax for 32-bit registers in appropriate for LAR/LSL. Yes, it does. But it also clearly indicates that specifying a 32-bit source register makes no difference at execution time. Thus they are synonyms, just like je and jz. > Specified by user... Personally, I would consider this as a valid feature request, albeit not a bug. However, I don't know how the others feel about it. > Let's say you want "MOVZX EAX,AX" in 32-bit code. I still don't see what this has to do with lar/lsl, but I do agree that NASM needs a more powerful macro system. You may recall that I asked for input on what features were most needed, but didn't get much response. However, I don't think that your proposed macro is very useful. MOVZX is not restricted to zero extending a given register to itself, but also allows things such as MOVZX EAX,DX. So your macro should allow two registers to be passed. For example crud eax, ax, 0, 2. On the other hand, if you are seriously suggesting that NASM should assemble MOVZX EAX,EAX without error, then I strongly disagree. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Chuck Crayne on 8 Sep 2008 00:29 On Sun, 7 Sep 2008 22:41:40 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > > Actually, I'm basing it on the fact that I used to make my living > > optimizing cpu gates. I do not know for certain what my > > counterparts at Intel did, but I do know what is reasonable -- and > > what is not. > > Mostly by software? Entirely by pencil and paper. > Why invent some redundant gated inputs, when the data is already in a > register? You could use regular non-gated inputs... > > Why gate at all? Much logic is not locked to a clock except by > design. Overclockers have been asking this one too... asynchronous. Because the only way to share a data bus among multiple logic elements is to gate the desired output of one logic element to the desired input element. Whether or not the gate is controlled by a clock is an entirely different matter. The gates are required in all cases. > The "wires" are driven by the gates/latches and "hold" one of two > potential voltages representative of "0" or "1" for binary logic - as > long as they are being driven by the gates/latches - indirectly from > the power source, of course. Ah! So you do see a need for gates, after all. > Do you want to tell me a capacitor doesn't "hold" potential energy > in an electrostatic field? Do you want to tell me an inductor doesn't > "hold" potential energy in a magnetic field? No. Why? Do you want to believe it? > Inaction requires no logic circuitry. Yes. Such as not checking a bit in the current cs descriptor. > Action requires logic circuitry. Yes. Such as checking a bit in the current cs descriptor. > Ignoring or modifying the action of an in use action requires more > logic circuitry. Just like this newsgroup, ignoring requires no logic. Perhaps I should adopt that strategy. > I.e., the circuitry is already checking a bit which applies to a > larger number instructions. To modify that primary action, requires > more logic. You keep saying this, but your have never even tried to justify it. To me, the Intel manual shows that it is clearly not true, as I continue to try to explain to you. > Logic is required to select between 8-bits and non-8-bits. Yes, but only for a small number of instructions -- specifically, those which have a 'w' (width) bit in their op-code. Although these instructions are the ones most commonly used by application programmers, they are still in the minority of total instructions. But you don't have to take my word for it. Read the manual, and count them for yourself. > More logic is > required to decide whether the non-8-bits is 16-bits or 32-bits. Yes, but only for those instructions which have a 'w' (width) bit in their op-code and the bit is set, which is only about half of the above cases, and therefor, a small minority of the total instructions. > Even more > logic is required to turn off the primary non-8-bit selection action > for certain instructions. No. The non-8-bit selection action is by far the majority case, and requires no special logic. [Go count them.] > I was suggesting that the > sub-fields may be connected to a latch instead of the main bus since > the main bus may be needed for other tasks. But then the latch (register) must be gated back onto the main bus to get the data to the adder. No benefit there. > If you were the logic optimizer, you should be answering this, > shouldn't you? As indeed I already have. However, you refuse to believe the expert, and are not willing or able to provide any reasonable alternative. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: H. Peter Anvin on 8 Sep 2008 04:20 Chuck Crayne wrote: > > On the other hand, if you are seriously suggesting that NASM should > assemble MOVZX EAX,EAX without error, then I strongly disagree. > I would say I weakly disagree. One can, legitimately, make a case that "MOVZX EAX,EDX" and "MOVSX EAX,EDX" should, indeed, assemble and produce the "MOV EAX,EDX" opcode. Personally, I think that is probably a net lose, in that the programmer is more likely to have made an error than genuinely have wanted that particular outcome. -hpa
From: Wolfgang Kern on 8 Sep 2008 06:02 H. Peter Anvin mentioned: > Chuck Crayne wrote: >> On the other hand, if you are seriously suggesting that NASM should >> assemble MOVZX EAX,EAX without error, then I strongly disagree. > I would say I weakly disagree. One can, legitimately, make a case that > "MOVZX EAX,EDX" and "MOVSX EAX,EDX" should, indeed, assemble and produce > the "MOV EAX,EDX" opcode. > Personally, I think that is probably a net lose, in that the programmer is > more likely to have made an error than genuinely have wanted that > particular outcome. Yes, there might be only rare needs for 'redundant' codes like shift by immediate Zero and the like, but it wont hurt to allow all these for the few who play with selfmodifying code. My disassembler report them as they are, but with a set redundancy-flag. __ wolfgang
From: Alexei A. Frounze on 8 Sep 2008 07:11
On Sep 8, 3:02 am, "Wolfgang Kern" <nowh...(a)never.at> wrote: > H. Peter Anvin mentioned: > > > Chuck Crayne wrote: > >> On the other hand, if you are seriously suggesting that NASM should > >> assemble MOVZX EAX,EAX without error, then I strongly disagree. > > I would say I weakly disagree. One can, legitimately, make a case that > > "MOVZX EAX,EDX" and "MOVSX EAX,EDX" should, indeed, assemble and produce > > the "MOV EAX,EDX" opcode. > > Personally, I think that is probably a net lose, in that the programmer is > > more likely to have made an error than genuinely have wanted that > > particular outcome. > > Yes, there might be only rare needs for 'redundant' codes like > shift by immediate Zero and the like, but it wont hurt to allow > all these for the few who play with selfmodifying code. > My disassembler report them as they are, but with a set redundancy-flag. > > __ > wolfgang I'm fascinated at how this thread lasts so long, all around one topic. :) I think I know the next source of the "renewable energy"! :) Alex |