Yasuko, are you saying that the bits() operation below converts the
address from 20-bits to a 16-bits?
EA = bits(SegBase + scale * Index + Base + disp, addressSize * 8 - 1, 0);
Note that all the addition operations are 64-bit, but the bits()
operation will suitably choose the required bits.
--
Nilay
On Thu, 15 Mar 2012, Watanabe, Yasuko wrote:
Hi Gabe,
Unfortunately, I cannot easily send an example because it is proprietary code.
But I will try to be more specific.
Macro-op MOV_R_M has the following single micro-op:
Ld req, seg, sib, disp
In 16-bit mode, seg contains a 20-bit segment-base address, and sib and disp
are used to compute a 16-bit offset. However, when the segment-base address is
added to the offset, it uses 16-bit addition, so the load address becomes 16
bits, not 20 bits.
Does this make sense?
Yasuko
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Gabriel Michael Black
Sent: Wednesday, March 14, 2012 3:33 AM
To: [email protected]
Subject: Re: [gem5-dev] x86 segmentation support in gem5
It would be really helpful if you could send me an example I could run that
demonstrates the problem.
Gabe
Quoting "Watanabe, Yasuko" <[email protected]>:
Hi Gabe,
Let me clarify. Setting a segment-base address is done correctly, as
you pointed out by the MOV_REAL_* macro-ops. The issue is adding the
20-bit base address to a 16-bit address to produce a 20-bit linear
address when accessing the memory. Specific examples include MOV_R_MI
and MOV_R_M, just to name a few.
Yasuko
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Gabriel Michael Black
Sent: Monday, March 12, 2012 11:32 PM
To: [email protected]
Subject: Re: [gem5-dev] x86 segmentation support in gem5
16 bit real mode and 32 bit legacy mode are already supported,
although not as well as 64 bit mode. When the address size is 16 bits,
that's the size of the virtual address from the instruction.
It's then turned into a linear address by applying segmentation, and
then a physical address by applying paging. The first of those is done
by the instruction itself. Paging and the permission checks for
segmentation and paging are done by the TLB. The 16 bit real mode
segment base should be used to compute the base added to the virtual
address by shifting it to the left by 4, as defined by the ISA.
That's done when the selector is assigned in real mode. See here:
http://repo.gem5.org/gem5/file/6df06e5975c6/src/arch/x86/isa/insts/gen
eral_purpose/data_transfer/move.py#l214
Gabe
Quoting "Watanabe, Yasuko" <[email protected]>:
Hi,
I have been working on adding x86 16-bit and 32-bit legacy mode
operations. The current infrastructure makes it very hard to compute
linear addresses due to segmentation, and I would like to get advice
from the gem5 community.
Here is the issue. In 16-bit legacy mode, the default effective
address size is 16-bits; however, it has to be zero-extended and
added to a 16-bit segment-base address that is left-shifted by four
bits, producing a 20-bit linear address. My understanding is that
gem5 does not differentiate the effective address computation part
from the latter part of adding a 20-bit segment-base address. That
is, when you specify an address size either in predecoder.cc through
emi.addrSize or in the macro-op definition files through addressSize,
that size is enforced even to a segment-base address.
As a result, in a typical case of 16-bit effective addresses in
legacy mode, you are truncating the upper four bits from a
segment-base address, getting a wrong 16-bit linear address.
I have temporary workarounds but would love to implement a more
permanent solution. Please let me know if you have thoughts on this.
Thank you,
Yasuko
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
