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: Frank Kotler on 4 Sep 2008 17:15 Rod Pemberton wrote: > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:g9ot2a$fjq$1(a)aioe.org... >> Well, that's the question. Is "lar eax, bx" mismatched? Is "lar eax, >> ebx"? (Nasm currently accepts both) > > Just an FYI, Nasm64developer said (bugtracker): > > "The assembler permits 16/32/64-bit src registers -- purely for courtesy > reasons." > > Do I need to file another bug report? If you feel it's wrong, by all means! If you feel that the emitted code is wrong, definitely!!! My understanding is that your issue is with the way we "say it", rather than the actual code... > That's clearly incorrect according to > Intel's documentation for 64-bit mode which only allows a 32-bit source. Still claim "bits 16-0"? > Now, given the ambiquity of AMD's documentation, it might be correct for AMD > cpu's. Could be... > Someone complained that LAR was broken and they (Nasm64developer and HPA) > fixed *BOTH* LAR and LSL for the assembler, Do you feel that they should differ? > under BR 1828866 "lar > instruction broken": > > "I upgraded from 0.98.39 to 0.99.06-20071101," > "and this line no longer works:" > "lar ecx,ebx" > "error: invalid combination of opcode and operands" > > Is that a "courtesy," or a "bug-fix"... ;-) No, that's a bug report. Long since "fixed". There's really no point in discussing 0.99.06-20071101. ftp://ftp.zytor.com/pub/nasm/snapshots/latest Best, Frank
From: Chuck Crayne on 4 Sep 2008 19:47 On Thu, 4 Sep 2008 10:39:10 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > "load" to me means a "read" of default register size. The reason that one should not take such words too literally is that they were chosen by a tech writer who was trying to explain a hardware process in terms that an average programmer would understand. From a hardware design point of view, "load" is acceptable in the case where the selector must be fetched from memory, but is inappropriate when the selector has already been loaded into a register. Every bit the cpu logic needs to access can be accessed directly from the source register, so gating it to some hidden 32-bit register would merely waste cpu resources. Nor does the concept of "default register size" apply to the source register. The cpu uses bits 0-2 to enforce the security rules; bit 3 to select between the GDT and LDT; and bits 4-15 as an index into the selected table. Under no circumstances does it deal with 8, 16, 32, or 64 bit entities. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Wolfgang Kern on 5 Sep 2008 05:47 Rod Pemberton wrote: .... >> 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. The CPU doesn't need to 'read' or 'load' already set registers, this internal hardware parts (all GPregs) are direct wired to the ALU and the AGU/AGL as well. So it's just a matter of gating the whole, a part or just some bits to the appropriate destination. And while older CPUs used barrel-shifters, modern design use bit-address-gating (ie: for real segments and scaled index transformation into address parts). > "only bits 16-0 are used. Other bits are ignored." .... should be read as bits 15..0 :) > 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. It may be hard and useless to explain all details of how a CPU internal work in a programmers reference manual. In 386/486-times we got all hardware details in the books, but were rare..never published today. So some of the description in the manuals may give us a wrong picture, but nevertheless the visible functionality should be our only concern. Your sense for contradictional stuff is quite astonishing Rod :) __ wolfgang
From: Rod Pemberton on 5 Sep 2008 12:49 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:g9peik$r7a$1(a)aioe.org... > Rod Pemberton wrote: > > "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... > > So this describes a 17-bit operation? Must be, sez so in the manual... :) > I guess that depends on inclusive vs. exclusive on the 16th bit since "-" is understood as "through"... ;-) If it was written "bits 16..0", then definately wrong. RP
From: Rod Pemberton on 5 Sep 2008 13:32
> "Chuck Crayne" <ccrayne(a)crayne.org> wrote in message news:20080904164739.67b22968(a)thor.crayne.org... > On Thu, 4 Sep 2008 10:39:10 -0400 > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > > > > "load" to me means a "read" of default register size. > > The reason that one should not take such words too literally is that > they were chosen by a tech writer who was trying to explain a hardware > process in terms that an average programmer would understand. Are you belittling the tech writer? How do you know the tech writer isn't a competent senior engineer who is too old, unhealthy, or frail to work full-time as an engineer anymore (or a team of pre-retirees) and not some young guy who writes down what he is told to get some college credit? How do you know the tech writer wasn't someone who has an engineering mind and but was sidetracked by life from engineering? IMO, one has to be slightly perverse, in a non-sexual way, to be a tech writer. That person must be able to know, understand, and express what the engineer, programmer, or designer knows, but have a desire to write it down instead of having a passion for programming, designing, or engineering. > From a hardware design point of view, "load" is acceptable in the case > where the selector must be fetched from memory, but is inappropriate > when the selector has already been loaded into a register. I'd think it's acceptable for both. Even if the selector is in a register, it must be gated onto a data bus used by the logic performing the instruction's operations. This data transfer, from register to bus to other logic, constitutes a "load" or "read". > Every bit the > cpu logic needs to access can be accessed directly from the source > register, Which is 32-bits (or likely much larger, 128-bits, as you've indicated...)... > so gating it to some hidden 32-bit register would merely > waste cpu resources. ? That doesn't make sense. Why would you gate to or through a hidden register when the data is already in a register? It just needs to be placed onto the correct data bus at the correct time. But, yes, the logic could just gate 16-bits onto a data bus... With sufficient silicon for the extra logic, that's not a problem. Personally, I'd think that having data smaller in size than the bus size used by that mode would cause more headaches for the designer and programmer. Think "mov eax,ds". I'd doubt such logic would exist on a smaller die where each transistor was more valuable and where generic logic blocks were used, at least without information from a reputable source. The early cpu's were all custom logic but the industry moved away from that fast. > Nor does the concept of "default register size" apply to the source > register. Why not? It should apply to to all registers for the mode. > The cpu uses bits 0-2 to enforce the security rules; bit 3 > to select between the GDT and LDT; and bits 4-15 as an index into the > selected table. Under no circumstances does it deal with 8, 16, 32, or > 64 bit entities. You've just stated the operations of a descriptor... not a selector. A selector is just a numerical index, i.e., n*8, n=0,1,2,3..., into the descriptor table. The instructions can use a register to obtain a selector instead of memory. If a register is holding the selector, the register must be at least 16-bits... Rod Pemberton |