Xenial Sasquatch
Posts: 5
Joined: Sun Jan 22, 2017 5:47 am

Executing code on a particular core (RPi 2)

Sun Jan 22, 2017 6:07 am

I am trying to learn how to make basic operating systems on the RPi2 (mainly using the tutorials provided on valvers.com, although I must say I am finding it slightly difficult to understand since I have never programmed bare metal before) and am trying to run code on particular cores. Eventually, I plan to schedule processes on cores.

I am programming in C using the bare metal gcc-arm-none-eabi compiler on GNU/Linux. At first I thought that I could use threads (PThreads in particular) but later read that I can't use the functionality provided by PThreads since the API is meant to run on the Linux kernel and not bare metal.

How do I make code execute on a particular processor core on the Raspberry Pi 2? Is there any other library that could help me with bare metal threads with C? Or is it something that can only be done with assembly code? If so could someone give me pointers on how to do this?

Thanks

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Sun Jan 22, 2017 5:27 pm

Krom (Peter Lemon) has an example of doing that in baremetal assembler look at the SMP directory which stands for symmetric multi-Processing.

https://github.com/PeterLemon/RaspberryPi

He has the precompiled image files on there so you can even look at the results first and the instructions of the files to go on the SD card on the front page

It's not hard to convert his code into C.

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: Executing code on a particular core (RPi 2)

Mon Jan 23, 2017 3:47 pm

I have a simple example as well.

https://github.com/dwelch67/raspberrypi ... er/multi00

Basically if you let the raspberry pi folks boot the cores for you the other three are sitting in a loop staring at a mailbox register, when the register goes non-zero that core jumps to that address. So all you have to do is write the address of the entry point for that core into its mailbox register.

This is bare metal, and chip specific (other chip solutions may vary), so it is not something the compiler or those kinds of libraries will do for you. There may and likely is someone that has written some bare metal library to help out with this.

Other chips may work differently, from the cores I have seen ARM has separate enables and resets for each core, my guess is broadcom releases all of them at once rather than individual control. So the bootstrap code has to sort them out using id bits.

With this core you can use a (set of) config.txt entries to boot from address zero, you can control the splitting up of the execution paths of the cores and then define how you want to send each core into its own code.

David

AlfredJingle
Posts: 69
Joined: Thu Mar 03, 2016 10:43 pm

Re: Executing code on a particular core (RPi 2)

Tue Jan 24, 2017 8:23 pm

Starting a core other than core 0 is in fact surprisingly simple: You write the address where the code is for a specific core to a kind of 'start'-addres of that core. The 'start'-addresses are 0x4000009C for core 1, 0x400000AC for core 2 and 0x400000BC for core 3.
So for instance, if the code you want to run at core 1 is located at 0xF000, you would write 0xF000 in 0x4000009C and core 1 will immediately start running the code at that address. There is a document from Broadcom called 'quad-A7 control', written by Gert van Loo, which gives more details.
going from a 6502 on an Oric-1 to an ARMv8 is quite a big step...

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Wed Jan 25, 2017 2:40 am

Just to be accurate for the OP .... that is only true if you allow the Pi boot sequence to complete and pick it up at 0x8000 with the cores in the standard Pi start positions. You have a choice in this.

If like in Peter Lemons code you pick the processor up at startup at 0x0000, one of your first tasks you need to do is park the other cores in a stable state to retrieve them from at a later stage which can be any number of ways as you are not locked into the Pi standard way.

David correctly explained that above and the OP needs to be clear he may run across two sorts of samples out there. Davids code does a classical Pi way, Krom (Peter Lemon) and AZO(Tomohiro Yoshidomi) do it there own way which are the three big examples out on the net I found. Conceptually they are doing the same thing but implementation wise they look very different and you need care in the discussion about where the cores will be parked.

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: Executing code on a particular core (RPi 2)

Thu Jan 26, 2017 1:21 am

Note I have examples that do both, boot from 0x8000 and use the mailboxes, and have some that boot from zero, and sort the cores.

Xenial Sasquatch
Posts: 5
Joined: Sun Jan 22, 2017 5:47 am

Re: Executing code on a particular core (RPi 2)

Sat Feb 04, 2017 4:16 pm

Thanks for the replies, everyone!

Since I'm using the default bootcode from a Linux installation, it sounds like the mailbox registers should work just fine for me :)

AALLeeXXX
Posts: 77
Joined: Sun Apr 10, 2016 1:37 pm
Location: Yokohama

Re: Executing code on a particular core (RPi 2)

Wed Mar 14, 2018 1:58 pm

Hello,

Just in case some still read this topic ... We discover here how to start a core. but... how to stop a core ??

I cannot find any document explaining the mailbox allocation , eg mailbox 3 of each core as a start address.. did I overlook soemething ?

Thanks

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Wed Mar 14, 2018 5:19 pm

You don't stop it you put it in a spinloop, if you want to save power while waiting for something to do you use wfi, wfe instructions.

The mailbox layout is covered in
https://github.com/raspberrypi/document ... rev3.4.pdf page 7 section titled registers.

AALLeeXXX
Posts: 77
Joined: Sun Apr 10, 2016 1:37 pm
Location: Yokohama

Re: Executing code on a particular core (RPi 2)

Thu Mar 15, 2018 4:22 pm

Hello LdB,

Thanks for the reply. Not sure whet you call a spin loop. I guess a endless loop with an exit condition, correct ?

About that doc, I knew it already, but it does not give the mailbox allocation. I want to know the usage of each of them. This doc just states they are all the same and programmer to decide ho to use them. So, how do we know this is mailbox 3 to start the cores ? Is it the PI gpu that initialises them that way ? Is this dynamically set ? I don't think my start-up code does that - thus, I guess this is set before... but when and by "who" ?

User avatar
Paeryn
Posts: 2680
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Executing code on a particular core (RPi 2)

Thu Mar 15, 2018 8:57 pm

We know the default boot code uses those mailboxes to wake up cores 1-3 by looking at the code that it runs.

There isn't anything special about those mailboxes, whoever wrote the boot code used them for kickstarting the parked cores. Once you start a core up then the mailbox that was used for it can be used however you want, they are only special in that when the default boot code parks the cores it has them each monitoring a particular mailbox for a startup location.
She who travels light — forgot something.

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Fri Mar 16, 2018 2:11 am

AALLeeXXX wrote:
Thu Mar 15, 2018 4:22 pm
About that doc, I knew it already, but it does not give the mailbox allocation. I want to know the usage of each of them. This doc just states they are all the same and programmer to decide ho to use them. So, how do we know this is mailbox 3 to start the cores ? Is it the PI gpu that initialises them that way ? Is this dynamically set ? I don't think my start-up code does that - thus, I guess this is set before... but when and by "who" ?
It's just a block of hardware your spinloop runs around reading the hardware, so your spinloop decides what the mailboxes mean.

Here look at a basic C example
https://github.com/LdB-ECM/Raspberry-Pi ... /Multicore

This is not intended as a serious multitasking example it's just showing you how it operates and taken up to the C level to make it easier to see.

Here is the spin loop for the CPU's

Code: Select all

/*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++}
{    Modified bootloader Spin loop but tolerant on registers R0-R3 for C    }
{++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/
.balign	4
SecondarySpin:
	mrc     p15, 0, r0, c0, c0, 5
	ands r0, r0, #0x3					    // Make core 2 bit bitmask in R0
	ldr r5, =mbox		
	ldr r5, [r5]		@ mbox
	mov	r3, #0			@ magic
	add	r5, #(0x400000CC-0x4000008C)	@ mbox
SecondarySpinLoop:
	wfe										// Lets CPU core sleep
	ldr	r4, [r5, r0, lsl #4]
	cmp	r4, r3
	beq	SecondarySpinLoop
@ clear mailbox
	str	r4, [r5, r0, lsl #4]
	mov	r0, #0
	ldr r1, =machid		
	ldr r1, [r1]		@ BCM2708 machine id
	ldr r2, = atags		
	ldr r2, [r2]		@ ATAGS
	ldr lr, =SecondarySpin
	bx	r4
	b SecondarySpin
mbox: 	.4byte 0x4000008C
machid:	.4byte 3138
atags:  .4byte 0x100
.balign	4
.ltorg
All it does is this sequence

1.) Read the mailbox for that core (by using the CPU core ID bit ... I decided mailbox 0 = CPU0, mailbox1 = CPU1 etc)
2.) If the address value read is not zero it clears the mailbox to zero and calls that address
3.) When it returns back it does some register cleanup and back to step 1

There is a slight trick to the loop that if the value read is zero, it sleeps the CPU via wfe instruction.

That means when you write an address to the mailbox you need to poke the CPU with a sev instruction to wake it up
Here is the CoreExecute function, R0 will have the CPU core to use R1 will be the address to call

Code: Select all

.globl CoreExecute
CoreExecute:
	ands r0, r0, #255
	beq CoreExecuteFail
	ldr r3, =RPi_CoresReady
	ldr r2, [r3]							// Fetch cores ready count
	cmp r0, r2
	bcs	CoreExecuteFail
	ldr r3, =#0x4000008C					// Load address of spins
	str r1, [r3, r0, lsl #4]				// Save caller address
	sev                                                         // Poke the CPU to wake up
	mov r0, #1
	bx  lr
CoreExecuteFail:
	mov r0, #0
	bx  lr
.balign	4
.ltorg
I decided what the mailbox mean and I chose that mailbox 0 = CPU0, mailbox 1 = CPU1 etc because it is easy.
I could have equally decided on another scheme so lets make up a random one.
Lets pass a struct thru only mailbox 0 which looks like this

Code: Select all

struct {
      int coreToUse;
      long AddressToCall;
} mailboxMsg;
So now my spin loops would read the address from the mailbox if not zero they would look at the coreToUse value and if it matches that core call to the address after zeroing the mailbox. All the core the message wasn't for would go back to sleep. So that scheme uses only 1 mailbox.
The point here is it is up to you what the mailbox means as you are writing the spinloop.

Now to complete the discussion using the mailbox is completely optional you can just use a piece memory in the same way (only the clear doesn't have the offset obviously). The 64 bit standard stub does exactly that probably because it expects the hardware mailbox to be virtualized away. It isn't clear why exactly they built the mailbox as hardware perhaps they had a different idea of how core communication would work. The thing here is to not get over worried about the mailbox being hardware the scheme works exactly the same by using memory and for practical purposes you can ignore it being hardware.

User avatar
Ultibo
Posts: 158
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Executing code on a particular core (RPi 2)

Sat Mar 17, 2018 10:03 am

LdB wrote:
Fri Mar 16, 2018 2:11 am
It isn't clear why exactly they built the mailbox as hardware perhaps they had a different idea of how core communication would work.
I think that's been covered previously, the mailbox is hardware so it can generate an interrupt.

When you want to do IPC and still have your CPU do real work at the same time polling is not useful, an interrupt on the other hand is the perfect solution.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

AALLeeXXX
Posts: 77
Joined: Sun Apr 10, 2016 1:37 pm
Location: Yokohama

Re: Executing code on a particular core (RPi 2)

Sat Mar 17, 2018 3:18 pm

Thank you all for your inputs. It's more clear now and I have better directions to search now.

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Mon Mar 19, 2018 12:04 am

Ultibo wrote:
Sat Mar 17, 2018 10:03 am
LdB wrote:
Fri Mar 16, 2018 2:11 am
It isn't clear why exactly they built the mailbox as hardware perhaps they had a different idea of how core communication would work.
I think that's been covered previously, the mailbox is hardware so it can generate an interrupt.

When you want to do IPC and still have your CPU do real work at the same time polling is not useful, an interrupt on the other hand is the perfect solution.
Gary, I never understand that statement because the cores only ever spinloop when then is nothing to do (in fact as per the example you usually sleep them in the loop) and I have never seen a switcher/IPC code setup like that.

I thought the interrupt was just used to pull the sleeping cores (using the wfi instruction) out to check the mailbox which as far as I can see no advantage over sleeping the cores with wfe and waking them with sev. The only situation I could see that it might be useful would be on some strange switcher which didn't have the usual time tick to the scheduler but somehow the act of writing kicked the scheduler but I have never seen any code that behaves like that. Most of the O/S I have looked at all do the same they either spin all the cores into an idle_function which means even in idle there is considerable power use or they sleep all but one core which runs the idle-function.

Now I know you have a lot of knowledge in this area and if there is a different and better way to use the interrupt would love to pick your brains.
I have setup a number of different SMP and AMP cluster code from off the net but they all tend to function the same way in the spinloop, so if there is a different way to use the interrupt I am very very interested.

I guess I shouldn't be lazy and go look at what you have done with the switcher in Ultibo since I am obviously missing something and hopefully I can understand it :-)

UPDATE: So I have looked at Ultibo and I can't see anything different you have a thread concept which functions in the same way as standard task context. I see the obligatory idle thread and you have 3 standard threads slots to process interrupts FIQ, IRQ and SWI if they are enabled (I assume you need different register/context stack saving on these). New threads are added to the thread list which is handled by the scheduler which looks like it has a couple of operations modes. When a normal thread finishes you use ARMv8Halt/ARMv7Halt which gives you a wfi, you configure the mailbox interrupt to wake the core up. You have the wfe version available under ARMv8WaitForEvent/ARM7WaitforEvent but don't use it choosing the interrupt method over the software method. I am not seeing anything different that I didn't expect or anything new with the mailbox use?

My guess is if I replaced the use of ARMv8Halt with ARMv8WaitForEvent, turned off the mailbox interrupt and fired a sev event on the mailbox write, Ultibo would work unchanged. Infact I could then use a standard memory location as the mailbox and ignore the hardware mailbox. Do I have something wrong with that belief?

User avatar
Ultibo
Posts: 158
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Executing code on a particular core (RPi 2)

Mon Mar 19, 2018 10:07 am

LdB wrote:
Mon Mar 19, 2018 12:04 am
I never understand that statement because the cores only ever spinloop when then is nothing to do (in fact as per the example you usually sleep them in the loop) and I have never seen a switcher/IPC code setup like that.
If you use the mailbox as a sort of super simple task scheduler like in your Multicore example then polling will be fine, but operating systems don't really do that.

Think about a different usage, like the case where one CPU wants to tell all the other CPUs to stop what they are doing and prepare to shutdown the system immediately. Those other CPUs will be busy doing whatever they are doing (not polling the mailbox) and an interrupt is the perfect way to get their attention. Circle has an implementation of something very similar to this in its multicore class.
LdB wrote:
Mon Mar 19, 2018 12:04 am
UPDATE: So I have looked at Ultibo and I can't see anything different...

When a normal thread finishes you use ARMv8Halt/ARMv7Halt which gives you a wfi, you configure the mailbox interrupt to wake the core up.
...
My guess is if I replaced the use of ARMv8Halt with ARMv8WaitForEvent, turned off the mailbox interrupt and fired a sev event on the mailbox write, Ultibo would work unchanged.
...
I'm not exactly sure what you read but Ultibo doesn't use or implement the ARM local mailbox at all, except just once during boot to release the secondary CPUs.

It is a fairly conventional pre-emptive multitasking design using a thread list and a number of priority queues, the scheduler (driven by the timer interrupt) selects the next thread to run based on state, priority and a couple of other factors.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Mon Mar 19, 2018 1:48 pm

Ultibo wrote:
Mon Mar 19, 2018 10:07 am
If you use the mailbox as a sort of super simple task scheduler like in your Multicore example then polling will be fine, but operating systems don't really do that.
You keep talking about polling but the CPU are basically always asleep in the loop. The only time they will exceute a poll is when a sev instruction is fired which like the irq situation is the only time you want them to wake up.

Then you are saying that isn't what an O/S do but both linux and windows on ARM processors use WFE/SEV on multicore not the IRQ method
http://linuxkernelarticles.blogspot.com ... n-arm.html
https://elixir.bootlin.com/linux/v4.3.6 ... spinlock.h

I asked around about why they don't use wfi and got told because you can get race and deadlock conditions when you wake the processor up, you can do it but you have to be extremely careful and a few said basically don't do it.

This is why I am getting confused all the real O/S kernels seem to do it that way and then the ARM forum advice is

Code: Select all

WFI is typically used in idle loops, or as part of the process of entering a deeper sleep (e.g. shut down mode).

WFE is often used in spin-locks.  Spin-locks are typically used for resources that are only held for a short period.  
So if a thread attempts to lock a spin-lock and finds it already taken, it will "spin" until it becomes available. 
Actually spinning is wasteful, so the lock function could use WFE to enter standby.  An "event" is generated when 
the other thread releases the spin-lock, causing the waiting thread to wake and re-attempt the lock. It's important to 
note that there is no additional information in an event.  That is, you don't know which spin-lock was released, hence 
the waking thread has to re-attempt the lock.  It might fail, and re-enter stand-by.
As per what I said in first statement we don't really spin poll the CPU we put it to sleep and the crass setup we have matches the recommended and current linux and windows spinlocks on the ARM8.
Ultibo wrote:
Mon Mar 19, 2018 10:07 am
Think about a different usage, like the case where one CPU wants to tell all the other CPUs to stop what they are doing and prepare to shutdown the system immediately. Those other CPUs will be busy doing whatever they are doing (not polling the mailbox) and an interrupt is the perfect way to get their attention. Circle has an implementation of something very similar to this in its multicore class.
That is an example I can definitely see the interrupt method does have an advantage ... +1 to you.
Ultibo wrote:
Mon Mar 19, 2018 10:07 am
It is a fairly conventional pre-emptive multitasking design using a thread list and a number of priority queues, the scheduler (driven by the timer interrupt) selects the next thread to run based on state, priority and a couple of other factors.
Gotcha and that probably explains a little thing I noticed, that a basic linux core doesn't run the PI3 as hot as Ultibo when it is sitting doing nothing as you aren't sleeping the excess idle cores.

User avatar
Ultibo
Posts: 158
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 9:35 am

I don't intend to get caught up in some long running post that goes wildly off track from the original point so I'll just add the following.

Of course modern operating systems run an idle loop when there is no other work to do and many switch the CPU to a lower power state during that loop as well, but they don't poll a mailbox in the idle loop waiting for the address of the next task to execute, that is the job of the scheduler.

If you want to use a mailbox as a primitive task scheduler then that's great but on the question of why the ARM local mailbox in the Pi is hardware and not memory it is so it can be used for scenarios where triggering an interrupt is the best solution.
LdB wrote:
Mon Mar 19, 2018 1:48 pm
Then you are saying that isn't what an O/S do but both linux and windows on ARM processors use WFE/SEV on multicore not the IRQ method
http://linuxkernelarticles.blogspot.com ... n-arm.html
https://elixir.bootlin.com/linux/v4.3.6 ... spinlock.h
...
As per what I said in first statement we don't really spin poll the CPU we put it to sleep and the crass setup we have matches the recommended and current linux and windows spinlocks on the ARM8.
You are seriously confusing different terminologies, a spinlock is a synchronization primitive used to protect code and data from simultaneous access. It is not some form of task scheduling or an idle loop so most of the quoted information has little or nothing to do with this discussion or the point you are trying to make.
LdB wrote:
Mon Mar 19, 2018 1:48 pm
Gotcha and that probably explains a little thing I noticed, that a basic linux core doesn't run the PI3 as hot as Ultibo when it is sitting doing nothing as you aren't sleeping the excess idle cores.
Again I don't know what you are reading, Ultibo uses WFE in the idle loop (WFI on the ARMv6) and while waiting to acquire a spinlock, just as it should. What we don't do is drop the CPU speed when idle but the Pi3 running at 1.2GHz never exceeds about 55 degrees C so we don't see a need for that yet.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 11:17 am

Yeah there is some serious crossed wires. I have not discussed scheduling or task switching and my code doesn't have context stacks, a scheduler or anything that remotely looks like a task switcher.

So to be clear the code represents a hyperthread spinlock, that is all it has ever claimed to be. You are saying Ultibo does it the same way so we actually agree on the implementation.

Many people including myself aren't interested in a task switcher they limit the real time response all we want to do is task up the cores with a given set of code in a typical embedded fashion.

The OP asked the question "Executing code on a particular core"
He isn't asking to build a task switcher or an O/S scheduler he is asking how to run code on a given core and I gave him the simplest way which is a standard hyperthread spinlock. If you wanted simpler you could just go the static one time load but that is obvious and you assume he wants to be able to change what code is running.

The reason the hyperthread spinlock works so well is because the cores are either running assigned code or sleeping it actually avoids continually polling the mailbox. You fixated on something about mailbox polling but the code is designed specifically to avoid doing.

User avatar
Ultibo
Posts: 158
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 11:32 am

LdB wrote:
Tue Mar 20, 2018 11:17 am
So to be clear the code represents a hyperthread spinlock, that is all it has ever claimed to be.
...
The reason the hyperthread spinlock works so well is because...
I've never heard of a "hyperthread spinlock" and sadly neither has Google :?

I'm really not sure you are being fair dinkum Leon, please consider doing some serious reading so we can have a genuine conversation.

Garry.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 12:40 pm

https://en.wikipedia.org/wiki/Hyper-threading
Unlike a traditional dual-processor configuration that uses two separate physical processors, the logical processors in a hyper-threaded core share the execution resources.
I am pretty sure we are setting up to execute code on another core as a shared execution resource

https://en.wikipedia.org/wiki/Spinlock
In software engineering, a spinlock is a lock which causes a thread trying to acquire it to simply wait in a loop ("spin") while repeatedly checking if the lock is available.
Technically because we sleep the processor rather than repeatedly aquire so it's a spinloop or a sleeping spinlock take your pick because

Code: Select all

A process cannot be preempted nor sleep while holding a spinlock due spinlocks behavior. 
So feel free to nitpick that with the same degree of stupidity .

Hence what the code does is a "hyperthreading spinloop" or "hyperthreading sleeping spinlock" whether you know what it is or not.

Now you are obviously far to elite level for me and just being insulting, so I think we should just agree to stop all communication, I certainly don't want to ever talk to you again.

MODS there is no need to get involved this has ended as far as I am concerned and am happy to ignore him.

User avatar
Paeryn
Posts: 2680
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 1:12 pm

LdB wrote:
Tue Mar 20, 2018 12:40 pm
https://en.wikipedia.org/wiki/Hyper-threading
Unlike a traditional dual-processor configuration that uses two separate physical processors, the logical processors in a hyper-threaded core share the execution resources.
I am pretty sure he wanted to execute code on another core as a shared execution resource
How do you run code as a "shared execution resource"?

An example of a shared execution resource would be two processors with their own integer pipelines but only one floating point pipeline shared between them. As far as code running on these two processors is concerned they both have an fpu, just that if both processors want to run an fpu instruction at the same time then one will take longer to obtain a result as it has to wait for the other to finish, but the code you write is no different.

Talking about hyper-threading on the RPi is pointless as the cpus aren't hyper-threaded, the 4 cores each have their own execution resources. Even in a hyper-threaded processor the sharing of execution resources is managed by the hardware, as far as software is concerned there is no shared execution resource.
She who travels light — forgot something.

LdB
Posts: 1239
Joined: Wed Dec 07, 2016 2:29 pm

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 1:39 pm

You are right because it was originally designed as a hardware implementation by Intel the problem is VMWare hijacked the term to mean software making one core like multiple cores.

https://pubs.vmware.com/vsphere-4-esx-v ... ading.html
Hyperthreading technology allows a single physical processor core to behave like two logical processors.
The processor can run two independent applications at the same time. To avoid confusion between logical and
physical processors, Intel refers to a physical processor as a socket, and the discussion in this chapter uses that
terminology as well.
You can see they acknowledge the confusion with hardware hyperthreading and then promptly ignore it.

So you are right but it doesn't change anything, we are trying to run two applications (AKA code) at the same time so by VMWare definition you are hyperthreading. In fact on ARCH64 I virtualize everything and it's actually really close to VMWare setup. Remember I don't have a task switcher or scheduler so all I can do is make it appear there is more cores than there actually is in a simple VMWare style setup. I probably should be careful it's not really a Virtual machine it's more like multiple debuggers running so lets go easy on calling it VMWare like or you will object to that as well.

It's the same nitpicking with the term spinlock it sleeps so is it really a spinlock, I prefer spinloop.
I actually laughed when I was reading the linux stuff and they still call a sleeping spinlock as a spinlock.
Do a search on "can a spinlock sleep" it's more than a bit contentious :-)

Personally I don't care what people call it I understand what they are doing, so knock yourself out and call it whatever you want and I am happy to work with your definition. It's like all things in the field people hijack terms and there is no authority that says this is right and this is wrong you just work thru the cracks. I work with a lot of non english speaking programmers and you wait until you throw different languages into the mix.

So if you don't want to call it hyperthreading I am cool but can you tell me what you want to call it so we have a term?

User avatar
Paeryn
Posts: 2680
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Executing code on a particular core (RPi 2)

Tue Mar 20, 2018 2:57 pm

LdB wrote:
Tue Mar 20, 2018 1:39 pm
You are right because it was originally designed as a hardware implementation by Intel the problem is VMWare hijacked the term to mean software making one core like multiple cores.

https://pubs.vmware.com/vsphere-4-esx-v ... ading.html
Hyperthreading technology allows a single physical processor core to behave like two logical processors.
The processor can run two independent applications at the same time. To avoid confusion between logical and
physical processors, Intel refers to a physical processor as a socket, and the discussion in this chapter uses that
terminology as well.
You can see they acknowledge the confusion with hardware hyperthreading and then promptly ignore it.
No, they are doing the same sort of thing, only in their case they are doing it at a software level if you ask for more processors than you have. Either way as far as any programs running under VMWare are concerned, be it on a real or virtual hyper-threaded processor, each logical processor is treated as a separate entity by software. The only thing software running on a hyper-threaded processor has to do is be aware of which cores it runs code on simultaneously as you don't generally want to run two processes on logical processors that share resources whilst another separate processor is left doing nothing (not counting cases like where the user knows two processes won't cause much contention and a third will be run later along side them that would benefit from having an uncontested core to itself).
LdB wrote:
Tue Mar 20, 2018 1:39 pm
So if you don't want to call it hyperthreading I am cool but can you tell me what you want to call it so we have a term?
From the OP's question I'd say they are talking about common-or-garden SMP (Symmetric Multi Processing).
She who travels light — forgot something.

Return to “Bare metal, Assembly language”