2

Would anyone be as so kind as to demonstrate how Intel assembly code can represent different threads being worked on by different cores? I presume you don't have one assembly file per thread/core?

EDIT: Let me reword: if i want to write assembler on different CPU cores, can i control what happens on core X and the communication between each core (just like one can control the register values on a core)?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
user997112
  • 29,025
  • 43
  • 182
  • 361
  • Threads are an operating system concept. It has nothing to do with assembly code. There is no machine code instruction for "start a thread", it requires an OS call. – Hans Passant Jan 15 '12 at 22:53
  • I have changed the title to reflect more accurately what im asking – user997112 Jan 15 '12 at 23:17
  • highly related: [What does multicore assembly language look like?](https://stackoverflow.com/q/980999) has an example of bare-metal code to bring up multiple cores on an x86 PC. You can have different cores run different code when you do that, same as when you start threads under an OS and give each thread a function + data arg. – Peter Cordes Jun 01 '20 at 21:35

5 Answers5

5

So you want to start a thread without help from the OS.

On recent Intel processors you do start up a second core via ACPI functions. The function issues an IPI (Interprocessor Interrupt) to a halted logical processor, it then begins executing code (the new thread) at an address specified as part of the IPI.

If you really do want to see the gory details, an example is at http://lxr.linux.no/#linux+v3.2/arch/x86/kernel/smpboot.c#L477 .

Further details and documentation is in the Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3 (System Programming Guide), chapter 8.6. As Intel keeps randomly changing the link, you better find it with google.

Gunther Piez
  • 29,760
  • 6
  • 71
  • 103
  • Good answer, upvoted. Still, the wording of the question doesn't explicitly clarify if the OP is working under an existing OS, or is out to create a new one. In the former case, none of this would work - the OS won't allow it from a userland program. – Seva Alekseyev Jun 01 '20 at 17:37
4

At the assembly level, threads look just like any other code. Certain instructions have semantics that are useful in a threading context, such as LOCK CMPXCHG, which performs an atomic compare-and-exchange. But in general, threads are create and managed through operating system calls, and you normally don't see the "plumbing". You just pass one of your functions to the thread creation API and it starts executing in parallel to (or interleaved with) the current code. The rest is up to you.

In the OS, threading is implemented by twiddling the stack and other registers in response to timer interrupts. There isn't a "create thread" opcode, as such.

Marcelo Cantos
  • 181,030
  • 38
  • 327
  • 365
  • you should probably change the wording about `CMPXCHG`, using atomic when threads are involved is different to single instruction multiple operation opcodes. in the thread case the `LOCK` prefix is needed for bus locking – Necrolis Jan 15 '12 at 22:54
  • @Necrolis: Thanks for pointing this out. I've added the prefix; is that a sufficient correction? – Marcelo Cantos Jan 16 '12 at 00:51
0

It all depends on your architecture--Windows? Linux? Mac OS? And in general threads will be managed by your operating system, just like in a higher level language. From the perspective of your code, you need to ask the operating system to create a thread using the same APIs you'd have used from C.

Basically, creating a thread is something you ask the host OS to do, and it's the same basic concept whether you're writing C, assembly, C#, Objective-C, or whatever.

StilesCrisis
  • 15,972
  • 4
  • 39
  • 62
0

Since it's MASM I guess you're using Windows. You call CreateThread passing the address of the thread start procedure (and some other stuff).

Some relevant posts: http://www.google.co.uk/search?q=createthread+site:masm32.com

Update

You're still limited to what the OS gives you. For example you can call SetThreadAffinityMask or SetThreadIdealProcessor. As Marcelo Cantos and Hans Passant have noted, threads are implemented by the OS, not the CPU, so it's the OS you need to talk to.

I don't believe Intel processors have a mechanism for passing messages between themselves (other than for very low level and automatic stuff like cache coherency).

arx
  • 16,686
  • 2
  • 44
  • 61
  • Of course you are not limited to what the OS gives. You can always do it yourself, or how do you think the OS does start threads in the first place? – Gunther Piez Jan 16 '12 at 13:52
  • @drhirsch: Yes, you can create coroutines, Erlang-style lightweight threads, etc. but they are not threads in the usual sense of something scheduled by the OS. Plus, you can't make one of your pretend threads run on a different processor, which was the point of the OP's question. – arx Jan 17 '12 at 03:34
  • I didn't mean coroutines or lightweight threads. You can completely omit the OS and write your own startup stuff just to start some routine on each processor, like BareMetalOS (http://www.returninfinity.com/baremetal.html) . I assumed the OP did want to know how to do this, but his question wasn't very clear. – Gunther Piez Jan 17 '12 at 09:43
0

Yes, you can. You'll need to write your own OS to do it with absolute control. This is part of the OS function, and the amount of ability to do so that it exposes to you varies depending on the OS.

Brian Knoblauch
  • 20,639
  • 15
  • 57
  • 92