[haiku-development] Re: Major CPUID revamp, rfc

On 01.06.2012 17:03, Axel Dörfler wrote:

On 01.06.2012 23:22, Alexander von Gluck wrote:

On 01.06.2012 16:15, Axel Dörfler wrote:

On 01.06.2012 18:01, Alexander von Gluck wrote:

I've been working on a major revamp of the CPU identification in Haiku.
I have a commit all ready to go pending a little testing.

[...]

The code is done, and I am testing it now... however I wanted to check
to make sure there aren't any
known compatibility issues with enlarging these numbers. We do have
CPUID numbers at the bottom of
OS.h for compatibility... so I don't think it is an issue.

I don't really understand what you are talking about. It's hard to
tell anything without seeing the source -- do you
have a patch that we could have a look at? :-)

Haha, sorry. It was a pretty complicated change :)

http://pub.haikungfu.net/0001-CPUID-Update-Haiku-CPUID-s.patch
Thanks! BTW I was worried when you wrote "6 bytes"; luckily you mean only 3 :-) 

Haha, you're right.  Not sure why I was calling 4 bits a byte :)
However, this change breaks binary compatibility for anything interested in that value compiled before -- you only 
retain source compatibility.
Since it's not a very important value (I would think so, at least), it's debatable whether it's worth the hassle of 
maintaining the old method of doing things for all CPUs already there.
That you changed the location of the vendor bits is definitely problematic, though - this might actually be used by 
software to select 3Dnow over MMX, or rather, to check for either of them.
Yeah, I was mostly running on the assumption that BeOS didn't use these values (or a vendor id << 8), but I can definitely 
see the benefit of shaking the apple cart as little as possible here.
Also, as you can see in src/add-ons/kernel/cpu/x86/amd.cpp the value might actually be used in ways that would not only cause some appearance problems (a.k.a. "unknown CPU"), but might actually crash the application in question.
Those things in mind, I would definitely be for keeping the vendor bits at the same position as before, and I'd be slightly favor of retaining the former CPU IDs, and only give newer ones more bits to play with.
I guess moving the family before the vendor (only on amd?) would be another way to solve this.. 

(E.xtended  V.endor  F.amily  M.odel)

Original (Intel):       EE VV FM
Original (AMD + other):    VV FM
New AMD chips:       FF MM VV 00  ?
That would limit the changes (no Intel changes at all or vendor mask changes), and allow us to get the needed data.
This is mostly all to cover AMD expecting you to be able to identify cpu's based on 1 byte fields: 
  (extended family + family) , (extended model << 4) + family
What makes this a hard call is that normally I would just do FF VV FM to keep the format consistent... but we need 8 bits for the cpu model. Another option would be just shoving the full CPUID in there, however the vendor ID is right in the middle of 
the CPUID processor family.

 -- Alex

Other related posts: