[fpc-devel] Feature announcement: Extension of TThread's interface

[Mark Morgan Lloyd]

microcode at zoho.com wrote:
> On Thu, Dec 27, 2012 at 07:01:08PM +0000, Mark Morgan Lloyd wrote:
>> Ewald wrote:
>>
>>> Now, for the implementation of ProcessorCount I've got code here that
>>> reads the amount of processor cores from `/proc/cpuinfo` (linux only I
>>> think) and some assembly code [asmmode att] (tested on x86_64 and i386)
>>> that *tries* to get the amount of cpu cores by the use of CPUID. The
>> In the general case, you have to be careful with this since (a)
>> every architecture puts different info in /proc/cpuinfo and (b) the
>> processor numbering and affinity vectors can have gaps.
> 
> In the general case how is his x86 asm supposed to ever work on anything but
> Intel or AMD boxes?
..
> Looks like a weird bug in the probing. Why does it miss CPs 2,3,6,7?

Because on that architecture every board, when initialising, starts off 
by running independently and gets an ID from its slot position. One slot 
(slot 1, not 0) is taken up by the mandatory card which has things like 
keyboard, serial and diagnostic JTAG support, and another (slot 3 on the 
system here) by a card with enough SCSI and Ethernet to boot. Once all 
cards have decided they're OK, the first card sends JTAG commands to the 
bus controllers on every card to rewire them to distribute resources 
over the centerplane, but the CPU IDs persist through to the process and 
interrupt affinity vectors (the taskset command on Linux).

Even on something like an Ultra-60 there's a gap:

$ taskset -p 1
pid 1's current affinity mask: 5
$ taskset -p -c 1
pid 1's current affinity list: 0,2

I'm not sure about this, but I /think/ that counting the bits in those 
vectors is the safest approach. However I've not gone into the API and I 
don't know how long the vector gets: I'd expect it to be able to handle 
 >32 CPUs (or cores) since I believe much of the work here was done by SGI.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]