Hi Nilay, That is correct. This is because the default address size in 16-bit mode is 16 bits, so the computed address gets truncated to 16 bits regardless of how the addition is done.
Simply changing the address size to 20 bits does not work, as Base might have some garbage in the upper bits, resulting in a wrong address. Yasuko -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nilay Vaish Sent: Wednesday, March 14, 2012 8:33 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 segmentation support in gem5 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/ge >> n >> 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
