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

[microcode at zoho.com]

On Fri, Dec 28, 2012 at 08:49:51AM +0000, Mark Morgan Lloyd wrote:
> 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).

Oh sorry, I misunderstood your post. I thought you meant only 12 of 16 CPUs
were showing in Linux. If you only have 12 CPUs in this case then I
understand the explanation. I seem to remember a discussion where you said
you have a box with 16 sockets.