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

Reply via email to