On 05/04/2011 01:13 PM, Blue Swirl wrote:
>> Sparc loses out on some TCG optimizations because of that, although
>> to be fair the most effective of these are still in Aurlien's trees.
>
> Interesting. Which optimizations? What trees? How would you implement
> the register windows then?
Constant
On 05/04/2011 12:35 PM, Blue Swirl wrote:
> On Wed, May 4, 2011 at 3:59 AM, Max Filippov wrote:
>> See ISA, 4.7.1 for details.
>>
>> Physical registers and currently visible window are separate fields in
>> CPUEnv. Only current window is accessible to TCG. On operations that
>> change window base
On Wed, May 4, 2011 at 11:07 PM, Richard Henderson wrote:
> On 05/04/2011 12:35 PM, Blue Swirl wrote:
>> On Wed, May 4, 2011 at 3:59 AM, Max Filippov wrote:
>>> See ISA, 4.7.1 for details.
>>>
>>> Physical registers and currently visible window are separate fields in
>>> CPUEnv. Only current wind
On Wed, May 4, 2011 at 3:59 AM, Max Filippov wrote:
> See ISA, 4.7.1 for details.
>
> Physical registers and currently visible window are separate fields in
> CPUEnv. Only current window is accessible to TCG. On operations that
> change window base helpers copy current window to and from physical
See ISA, 4.7.1 for details.
Physical registers and currently visible window are separate fields in
CPUEnv. Only current window is accessible to TCG. On operations that
change window base helpers copy current window to and from physical
registers.
Window overflow check described in 4.7.1.3 is in s