qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation


From: Richard Henderson
Subject: Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation
Date: Wed, 16 Sep 2015 13:41:01 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 09/16/2015 01:59 AM, Alex Bennée wrote:
> 
> Richard Henderson <address@hidden> writes:
> 
>> On 09/10/2015 11:55 AM, Alex Bennée wrote:
>>> I've only had a quick glance so far but I'm fairly familiar with the
>>> concept from a previous life. I'll aim to do a full review later once
>>> I've gotten through my MTTCG review backlog.
>>>
>>> Anyway some quick points:
>>>
>>>  * You can save data by only marking faulting instructions
>>>
>>> Assuming that all asynchronous instructions trigger at the end/prologue
>>> of basic blocks you only actually need to record the address of
>>> potentially faulting instructions. In fact only a few backend
>>> instructions will actually synchronously fault.
>>>
>>> Of course this does have the downside of having to mark all those
>>> instructions in the front end.
>>
>> We have that.  The only tcg opcodes that can fault are qemu_ld, qemu_st, and
>> call.  So, yes, I could do exactly this.  Perhaps not for round 1,
>> however?
> 
> I unfortunately haven't got a SPARC manual handy (or my old testsuite)
> but I was sure there was more than just loads/stores. I guess all the FP
> related exceptions are handled in Softfloat for QEMU and the hardcoded
> cases caught during instruction decode.

Yes indeed.  A tcg-opcode based "might it trap" test will be more inclusive
than one that actually examined the target insns.  But it'll work universally
without needing to modify the translators, and it will save *some* space.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]