[MPlayer-dev-eng] [PATCH] Remove cputable.h?

[Ivan Kalvachev]

On 2/21/09, Zuxy Meng <zuxy.meng at gmail.com> wrote:
> 2009/2/21 Ivan Kalvachev <ikalvachev at gmail.com>:
>> On 2/20/09, Zuxy Meng <zuxy.meng at gmail.com> wrote:
>>> Hi,
>>>
>>> 2009/2/21 Ivan Kalvachev <ikalvachev at gmail.com>:
>>>> On 2/20/09, Zuxy Meng <zuxy.meng at gmail.com> wrote:
>>>>> 2009/2/20 Ivan Kalvachev <ikalvachev at gmail.com>:
>>>>>> On 2/20/09, Zuxy Meng <zuxy.meng at gmail.com> wrote:
>>>>>>> 2009/2/20 Attila Kinali <attila at kinali.ch>:
>>>>>>>> On Thu, 19 Feb 2009 21:30:59 +0800
>>>>>>>> Zuxy Meng <zuxy.meng at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> > I wouldnt. Though i only see sense to do detection ourselfs when
>>>>>>>>> > handling
>>>>>>>>> > pre P-II processors (iirc)... I've no clue how many of them are
>>>>>>>>> > still
>>>>>>>>> > in
>>>>>>>>> > use for video decoding.
>>>>>>>>>
>>>>>>>>> For them, we still print the vendor, family, model and stepping as
>>>>>>>>> well as SIMD support and I guess that's fairly enough.
>>>>>>>>
>>>>>>>> Well then.. go ahead
>>>>>>>> .. unless someone else complains ;-)
>>>>>>
>>>>>> I complain.
>>>>>
>>>>> Because?
>>>>
>>>> line 262 contains my cpu.
>>>
>>> A K7? mplayer prints its built in name string directly withouth the
>>> help from cputable.h So removing this header wont' affect the output
>>> of mplayer on you fairly up-to-date CPU.
>>
>> The build-in name string is not the same as the one in the table.
>> The table contains far more detailed description as it is not limited
>> by string size.
>
> I guess you mean those internal codenames that are translated from FMS
> (family/model/stepping). So essentially it doesn't give any extra
> information, while built in strings say more: the frequency, whether
> it's a Celeron or Pentium, dual core or quad core etc. which FMS and
> hence the table can't tell you.

Maybe on newers CPU's that are not described in the table anyway.
On my cpu it says "AMD Athlon(tm)"
I hardly care that it is trademarked, and I already know it is AuthenticAMD.
So I do get less info.

BTW, I do accept hardware donations. :)

>> Actually the table content should be preferred.
>>>> And I don't like removing features, even if they are not essential.
>>>
>>> No features are removed, just dead code and an outdated table.
>>
>> I disagree. It's better to update the table.
>
> We are not writing a CPU detection tool. Besides, there ceases to be a
> one to one correspondence between codenames and FMS so the table has
> lost its meanings for recent and future CPUs.

There is one major rule. If the program doesn't say it
have detected the cpu, then users assume the program
doesn't detect it at all and doesn't use its full capabilities.

I know somebody "accidentally" turned the whole thing off.
Wrong move.

p.s.
This bike shed discussion is already too big.
If you really want so badly to remove the table,
don't ask people if they object.