Re: [PATCH 04/15] arc: TCG and decoder glue code and helpers

Cupertino Miranda
2021-01-15T21:48:53Z

On 1/15/21 8:31 PM, Richard Henderson wrote:
> On 1/15/21 7:11 AM, Cupertino Miranda wrote:
>>> Similarly. I think that both of these could be implemented entirely in
>>> translate, which is what
>>>
>>>> + bool restore_fp = u7 & 0x10; /* u[4] indicates if fp must be saved */
>>>> + bool restore_blink = u7 & 0x20; /* u[5] indicates saving of blink */
>>>> + bool jump_to_blink = u7 & 0x40; /* u[6] should we jump to blink? */
>>>
>>> these bits strongly imply.
>>>
>>
>> For lack of knowing better, it is unclear to me where to draw the line
>> when choosing between a translate time (tcg) or helper implementation.
>> Your suggestions for carry/overflow computation are sharp and we should
>> have never used an helper, however I wonder what would be the benefit of
>> implementing enter and leave through TCG.
>>
>> We have dealt with those exception issues by just changing SP in the end
>> of the instruction implementation, when no exceptions can happen.
>
> 5-10 tcg opcodes is the rule of thumb. A conditional exception (requiring a
> branch) is a good reason to put the whole thing out of line.
>
> In the case of enter or leave, this is one load/store plus one addition,
> followed by a branch. All of which is encoded as fields in the instruction.
> Extremely simple.

So your recommendation is leave the conditional exception triggering of
enter and leave in a helper and move the loads/stores to tcg ?

>
>> As far as I understand when an exception happens in the middle of the
>> helper or even on a TCG implementation, it jumps out of that TB
>> execution to deal with the exception. On rtie instead of it returning to
>> the same tcg_ld or tcg_st where it actually triggered the exception it
>> will re-decode the same instruction which triggered the exception, and
>> re-attempts to execute it.
>> Is that the case in current TCG implementation, or did it improved and
>> it is now able to return to previous execution flow (i.e translation
>> block) ?
>
> I think I don't understand your question.
>
> An exception leaves the TB, via longjmp. Before the longjmp, there is normally
> an "unwind" or "restore" operation, to sync the cpu state with the middle of
> the TB. This happens in restore_state_to_opc().
>
> When processing of the exception is complete, execution will continue with the
> appropriate cpu state. Which will probably be a new TB that (logically)
> partially overlaps the previous TB.
>
> I.e. everything will work as you'd expect.
>
> So... what's the question?
>
You answered the question. That is exactly how I understand it works.

>
> r~
>