On 05/03/2019 18:16, Mark Cave-Ayland wrote:
> On 03/03/2019 23:35, Richard Henderson wrote:
>
>> On 3/3/19 9:23 AM, Mark Cave-Ayland wrote:
>>> static inline void get_cpu_vsrh(TCGv_i64 dst, int n)
>>> {
>>> - if (n < 32) {
>>> - get_fpr(dst, n);
>>> - } else {
>>> - get_avr64(dst, n - 32, true);
>>> - }
>>> + tcg_gen_ld_i64(dst, cpu_env, vsrh_offset(n));
>>> }
>>>
>>> static inline void get_cpu_vsrl(TCGv_i64 dst, int n)
>>> {
>>> - if (n < 32) {
>>> - get_vsrl(dst, n);
>>> - } else {
>>> - get_avr64(dst, n - 32, false);
>>> - }
>>> + tcg_gen_ld_i64(dst, cpu_env, vsrl_offset(n));
>>> }
>>>
>>> static inline void set_cpu_vsrh(int n, TCGv_i64 src)
>>> {
>>> - if (n < 32) {
>>> - set_fpr(n, src);
>>> - } else {
>>> - set_avr64(n - 32, src, true);
>>> - }
>>> + tcg_gen_st_i64(src, cpu_env, vsrh_offset(n));
>>> }
>>
>> I think these ought to have a "high" parameter, like set/get_avr64.
>
> Right, this is effectively the same discussion as in my previous email so I
> suggest
> we follow this up there.
I've reworked this patchset over the evening to keep avr64_offset() and looking
over
the result it's more readable than I thought, mostly thanks to its use of the
VsrD macro.
The only part I'm now not sure about is whether from the above you want to keep
fpr_offset() and vsrh_offset(), or whether in the final patch in the series I
can
introduce vsr64_offset() similar to avr64_offset() and switch the callers over
to use it?
ATB,
Mark.
