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

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 02 Jun 2012 00:03:54 +0200

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 :-)

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.

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.

Bye,
   Axel.

Other related posts: