On 08/23/2015 08:15 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko <dvlas...@redhat.com> wrote:
>
>>> static FUNC const st_instr_table[64] = {
>>> - fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_,
>>> _df_c0_,
>>> - fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_, fmulp_,
>>> _df_c8_,
>>> - fcom_st, fp_nop, fcmovbe, fcmovnbe, _dc_d0_, fst_i_, _de_d0_,
>>> _df_d0_,
>>> - fcompst, _d9_d8_, fcmovu, fcmovnu, _dc_d8_, fstp_i, fcompp,
>>> _df_d8_,
>>> - fsub__, FPU_etc, __BAD__, finit_, fsubri, fucom_, fsubrp, fstsw_,
>>> - fsubr_, fconst, fucompp, fucomi_, fsub_i, fucomp, fsubp_,
>>> fucomip,
>>> - fdiv__, FPU_triga, __BAD__, fcomi_, fdivri, __BAD__, fdivrp, fcomip,
>>> - fdivr_, FPU_trigb, __BAD__, __BAD__, fdiv_i, __BAD__, fdivp_, __BAD__,
>>> +/* 0x00 */ fadd__, fld_i_, fcmovb, fcmovnb,
>>> +/* 0x04 */ fadd_i, ffree_, faddp_, _df_c0_,
>>> +/* 0x08 */ fmul__, fxch_i, fcmove, fcmovne,
>>> +/* 0x0c */ fmul_i, _dd_c8_, fmulp_, _df_c8_,
>>> +/* 0x10 */ fcom_st, fp_nop, fcmovbe, fcmovnbe,
>>> +/* 0x14 */ _dc_d0_, fst_i_, _de_d0_, _df_d0_,
>>> +/* 0x18 */ fcompst, _d9_d8_, fcmovu, fcmovnu,
>>> +/* 0x1c */ _dc_d8_, fstp_i, fcompp, _df_d8_,
>>> +/* 0x20 */ fsub__, FPU_etc, __BAD__, finit_,
>>> +/* 0x24 */ fsubri, fucom_, fsubrp, fstsw_,
>>> +/* 0x28 */ fsubr_, fconst, fucompp, fucomi_,
>>> +/* 0x2c */ fsub_i, fucomp, fsubp_, fucomip,
>>> +/* 0x30 */ fdiv__, FPU_triga, __BAD__, fcomi_,
>>> +/* 0x34 */ fdivri, __BAD__, fdivrp, fcomip,
>>> +/* 0x38 */ fdivr_, FPU_trigb, __BAD__, __BAD__,
>>> +/* 0x3c */ fdiv_i, __BAD__, fdivp_, __BAD__,
>>
>> The numeric comments added at the left don't look correct.
>
> Yeah, so they are correct for the purpose I used it: I simply wanted to index
> the
> table by its natural index: 'instr_idx', which is derived from the opcode.
>
> But you are right that indexing it by the opcode is more useful for future
> extensions:
>
>> In this table, each _column_ corresponds to one 0xd? opcode.
>> Each row corresponds to a group of mod-reg-rm bytes
>> with only "rm" field chnaging. (These insns act on registers,
>> not memory, and "rm" value encodes register number, st(i).)
>>
>> Something like this:
>>
>> /*Opcode: d8 d9 da db dc dd de df */
>> /*c0..7*/ fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_,
>> /*c8..f*/ fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_,
>> /*d0..7*/ fcom_st,fp_nop, fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_,
>> /*d8..f*/ fcompst,_d9_d8_, fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_,
>> /*e0..7*/ fsub__, FPU_etc, __BAD__,finit_, fsubri, fucom_, fsubrp, fstsw_,
>> /*e8..f*/ fsubr_, fconst, fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip,
>> /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_, fdivri, __BAD__,fdivrp, fcomip,
>> /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__,
>
> (Assuming you also do the table alignment improvements I did, the current
> format
> is pretty hard to navigate.)
>
>>
>>
>> They should be:
>
> Hm, your mail seems to have been cut off at this point.
In fact, my mail was too long - I forgot to delete this last line,
"They should be" :)
I propose the table to be commented like shown below:
/*Opcode: d8 d9 da db dc dd de df */
/*c0..f*/ fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_,
/*c8..f*/ fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_,
/*d0..7*/ fcom_st,fp_nop, fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_,
/*d8..f*/ fcompst,_d9_d8_, fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_,
/*e0..7*/ fsub__, FPU_etc, __BAD__,finit_, fsubri, fucom_, fsubrp, fstsw_,
/*e8..f*/ fsubr_, fconst, fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip,
/*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_, fdivri, __BAD__,fdivrp, fcomip,
/*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
