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