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

Richard Henderson
2021-01-15T20:31:19Z

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.

> 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?

r~