No idea why cpuid is present at all, maybe some game crashed otherwise.
What do you need that for?

I have no special need of CPUID but I just want to notice when it is supported it should be implemented correctly.
Some guy sent me mail that tried to run my CPUID program also in DOSBox just for fun and it didn't worked while some other programs show CPUID. So we treace the problem and it is in different CPUID support detection routine.

The correct way to identify whether cpuid is present or not is to
see if that ID-bit can be toggled. Under dosbox it can't (it's always
set) so it behaves like 386s and early 486s, which is just fine for
the games that dosbox targets at.

OK.

BTW do you plan to support higher CPUs? Maybe some latest games/demos/progs will require some 486/pentium features.

But I'd rather to see DOSBox support dualcore CPUs (if it can gain performance) 😀

There shouldn't be any 486+ instructions missing that are used
by games/demos, think one or two games don't work because of
the missing rdtsc.

RDTSC should't be hard to implement, just return dosbox cpu cycles in EDX:EAX:

Well we're not aiming at pentium+ compatibility at the moment 😉
I'd like to have a #define that switches between 386/486/pentium
(different flags behaviour, pagefault privileges, instruction differences)
but Qbix didn't like it too much so the aim is to run everything <586.
The rdtsc-requiring game wasn't worth adding it imo...

Since dosbox is a games emulator above all else, then how come adding that in isn`t worth it?

Even if 2 games benefit its that bit closet to 100% compatibility.

What 2 games?

then how come adding that in isn`t worth it?

Because it was some really crappy game and i don't have a clue what it was called.
Feel free to add it to your sourcetree, instructions are above.

Interesting, I tried new DOSBox 0.74 and now it supports CPUID, huh. So authors did change their opinion?

No, but things were cleaned up and revisited. CPUID is bound to the cpu_type btw.

RDTSC should't be hard to implement, just return dosbox cpu cycles in EDX:EAX:

That is not how RDTSC works, it returns real-time not cycle time. If DOSBox were to run at a variable rate, then just returning the cpu cycles done so far would then return the wrong value, and introduce clock drift.

Well it returns "ticks" or "cycles" or however it may be called, and since games either
measure the tsc distance against a real time measure using rdtsc as a quick way to
get high resolution timing, or just require an always-increasing timer, the dosbox cycles
should work fine. If you know of a game that takes measurement otherwise but relies
on rdtsc, or misbehaves because of the current implementation, please post.