|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: How do you run code in more than one core?
Date: 3 Nov 2012 10:10:21
Message: <509525cd@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Orchid Win7 v1
Subject: Re: How do you run code in more than one core?
Date: 3 Nov 2012 12:16:38
Message: <50954366$1@news.povray.org>
|
|
|
| |
| |
|
|
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§ion=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§ion=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
|
|
| |
| |
|
|
From: clipka
Subject: Re: How do you run code in more than one core?
Date: 4 Nov 2012 20:42:25
Message: <50971981@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |