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
>> 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
> 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
> 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
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.
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:
> "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 :)
From: Rod Pemberton on 5 Sep 2008 12:49
"Frank Kotler" <fbkotler(a)verizon.net> wrote in message
> 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
> > 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
From: Rod Pemberton on 5 Sep 2008 13:32
> "Chuck Crayne" <ccrayne(a)crayne.org> wrote in message
> 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
Which is 32-bits (or likely much larger, 128-bits, as you've
> 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
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
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