I know x86-style machine code quite well (and have a quite good grasp at
RISC-style machine code as well), and in fact in the past I have written
entire programs in pure asm. While I have not followed the technical
details of the latest processors, I still have a relatively good grasp
of how they work at the machine code level.

There's one aspect, however, that was a complete and absolute mystery
to me: How exactly do you run code in more than one processor/core?
What kind of operations do you need to do to achieve this?

Normally you don't have to worry about this when writing a program because
the operating system takes care of it. You simply make a system call to
the OS to tell it "start a new process/thread and run this code in it".
The OS takes care of the ugly details.

However, how does the OS do it? How does it run code in different
processors/cores? What exactly is the mechanism for this? What are the
machine opcodes required to do this?

-- 
                                                          - Warp

Post a reply to this message

Am 03.11.2012 13:31, schrieb Warp:

> Normally you don't have to worry about this when writing a program because
> the operating system takes care of it. You simply make a system call to
> the OS to tell it "start a new process/thread and run this code in it".
> The OS takes care of the ugly details.
>
> However, how does the OS do it? How does it run code in different
> processors/cores? What exactly is the mechanism for this? What are the
> machine opcodes required to do this?

 From what I gather from Intel's System Programmer Guide, there are no 
specific opcodes involved.

In essence, one of the processors (the Bootstrap Processor, BSP) starts 
executing with a certain flag set (BSP in IA32_APIC_BASE MSR), while the 
others (the Application Processors, APs) enter a certain waiting state 
with that flag cleared. The BSP then does some OS initialization, 
including the creation of the task list; after that, it wakes up the 
APs, and grabs itself a task to work on. The APs, by means of testing 
for the BSP flag, take a different path through the code to bypass the 
initialization stuff, and grab themselves tasks straight away.

Starting a new process or thread is done in the very same way as on a 
single-processor machine: The parent process simply calls into the OS 
code, which then sets up the data structures for a new process or 
thread, and adds the new entry to the process and/or task list. From 
that on, the new job may be picked up by any processor that has nothing 
better to do.

(http://download.intel.com/products/processor/manual/325462.pdf might 
provide more detail.)

Post a reply to this message

On 03/11/2012 12:31 PM, Warp wrote:

> There's one aspect, however, that was a complete and absolute mystery
> to me: How exactly do you run code in more than one processor/core?
> What kind of operations do you need to do to achieve this?

As best as I can tell, when the system boots, all but one processor core 
fire up in an idle mode, and core 0 starts running. I think the process 
for actually taking a core out of its idle state and directing it to run 
code at a specific physical memory address might even vary by 
motherboard chipset - so it's probably a case of asking the BIOS to do 
it for you. (Because otherwise your OS would have to know how to drive 
every chipset known to man.)

I could be completely wrong, of course...

Post a reply to this message

Le 03/11/2012 17:16, Orchid Win7 v1 nous fit lire :
> On 03/11/2012 12:31 PM, Warp wrote:
> 
>> There's one aspect, however, that was a complete and absolute mystery
>> to me: How exactly do you run code in more than one processor/core?
>> What kind of operations do you need to do to achieve this?
> 
> As best as I can tell, when the system boots, all but one processor core
> fire up in an idle mode, and core 0 starts running. I think the process
> for actually taking a core out of its idle state and directing it to run
> code at a specific physical memory address might even vary by
> motherboard chipset - so it's probably a case of asking the BIOS to do
> it for you. (Because otherwise your OS would have to know how to drive
> every chipset known to man.)
> 
> I could be completely wrong, of course...

I would have resume it as: setting the PC on the relevant core and let
it flow. (PC: program counter)

You are correct about the startup: setting such basic things as mem
mapping is best done by a single unit, so only 1 core is up at startup.

I would not expect the bios to be involved at all.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> after that, it wakes up the APs

How?

(Also: After the other cores have been started and are running some idle
process, waiting for tasks to be assigned to them, how do you assign tasks
to them? IOW how do they detect that they should start running something?)

-- 
                                                          - Warp

Post a reply to this message

Le 04/11/2012 08:02, Warp nous fit lire :
> clipka <ano### [at] anonymousorg> wrote:
>> after that, it wakes up the APs
> 
> How?
> 
> (Also: After the other cores have been started and are running some idle
> process, waiting for tasks to be assigned to them, how do you assign tasks
> to them? IOW how do they detect that they should start running something?)
> 
Is that a general question or is it targeted to a specific architecture
? (like x86 or arm or ... even SoC)

The notion of process/tasks is something that is alien to a CPU/core. It
runs the next instruction or process some interruptions (by stacking the
current state and performing a change of PC).
The process/task concept is an illusion created by the scheduling code
of the OS.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> The notion of process/tasks is something that is alien to a CPU/core. It
> runs the next instruction or process some interruptions (by stacking the
> current state and performing a change of PC).
> The process/task concept is an illusion created by the scheduling code
> of the OS.

That doesn't answer my question.

-- 
                                                          - Warp

Post a reply to this message

Le 04/11/2012 09:41, Warp nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> The notion of process/tasks is something that is alien to a CPU/core. It
>> runs the next instruction or process some interruptions (by stacking the
>> current state and performing a change of PC).
>> The process/task concept is an illusion created by the scheduling code
>> of the OS.
> 
> That doesn't answer my question.
> 

http://www.mindshare.com/shop/?c=b&section=0A6B17101710

Have a peek inside, page 117 (#363) should answer it. More on the next
pages too.

And next jump to 147-149 (#629-#631)

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> http://www.mindshare.com/shop/?c=b&section=0A6B17101710

> Have a peek inside, page 117 (#363) should answer it. More on the next
> pages too.

> And next jump to 147-149 (#629-#631)

How about just explaining it in a few sentences?

-- 
                                                          - Warp

Post a reply to this message

Am 04.11.2012 08:02, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> after that, it wakes up the APs
>
> How?

The APs enter Halt state, so to wake them up you trigger whatever event 
gets a CPU out of Halt... Interrupt, maybe? You COULD possibly read up 
on it in the System Programmer's Guide; see the link I posted.

> (Also: After the other cores have been started and are running some idle
> process, waiting for tasks to be assigned to them, how do you assign tasks
> to them? IOW how do they detect that they should start running something?)

An idle processor enters a power-saving state, waiting for an interrupt 
from either a self-set timer or triggered by another processor via 
interrupt controller. Once it is woken up, it checks the list of pending 
jobs, calls dibs on the next one, and goes to work. (Or, if the list is 
empty, goes to sleep again.)

Not much magic in there.

Post a reply to this message