--- Comment #6 from Don <> 2011-02-20 08:40:20 PST ---
(In reply to comment #4)
> I don't agree this is an enhancement, it is a bug, 

It's neither. It is a task. Bugzilla's options are ridiculously limited.

> Why is this being handled by assembly code, all the operating systems must 
> have
> APIs for handling this?

The most recent ones do, the older ones don't.
Really, this code is primarily intended for determining which features should
be supported for low-level operations used by the runtime; and as such, it must
be available at a very early stage in the initialization process, regardless of
the OS. It replaces several ad-hoc and incorrect functions which had been used
in the runtime.

It would be good to supplement this with systems calls for the most recent
OSes, but to do this without breaking older OSes. Although, probably all 64-bit
OSes support it, so maybe it's only a issue for 32-bit systems.

 > Of course with Mac hardware with 64-bit processors where the boot ROM is
> the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. 
> A hypothesis:  the current assembly code can only deal with a single processor
> which is why it reports 4 in 32-bit mode on my dual quad-core workstation.  If
> this is the case should a new bug be raised or can this be handled here?

That should be a new bug. The value should be correct, if the BIOS has done its
job in setting the processor APIC values correctly.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to