For Example when we write " print("Hello"); " in unity, how it detects it should show "Hello" in console?

According to the documentation, print() is functionally identical to Debug.Log(). Looking at the documentation for Debug.Log(), it looks like it's integrated into the editor (that is, it's more than just a 'log a message' function) in that you can include a 'context' object with your message and Unity will highlight the object in the editor when you click on the message. It also logs to various files in addition to the console.

Maybe you already know all that, but I mention it just in case it's relevant.

As for your question, I don't know the exact answer with respect to Unity, but in general, the answer depends on what languages and systems are being used. For example, the answer would be different for e.g. Lua and C++ than for C# and Unity.

Regarding Unity, here's a thread that discusses the issue. Some of the information may be out of date (for example, I see mention of UnityScript, which I think is either gone or at least on its way out), but maybe the architectural stuff is still relevant. In any case, maybe it'll provide some insight.

It-depends counter +1: In Unity, everything is implemented in a mix between the Unity Engine C# Assembly and the Unity Player Executabel that is written in C++ (and for Android encapsulated into a small Java Bootstrapper). As soon as the Unity Player embedds the Mono Runtime (or is build via IL2CPP) anything that is inside the "native" part of the engine can be exposed to the CLR runtime and so is addressable from C# too.

Same for C++ and Lua, there is a library to expose C++ functions into the Lua runtime.

In general one can say that scripting interfaces always run some kind of interpreter either for plain-text (that is rather unlikely in games nowdays) or "compiled" byte-code of the scripting language. Those interpreters (as far as they are productiin ready) then offer an interface to the embedding code for exposing functions in a way that the interpreter can execute them with the correct parameters. In C++ these are often plain pointers with some kind of meta data description of the function, delegates in C# with or without reflection to get the meta data here or even dynamically compiled IL.

A CPU is in general just an FSM (finite state maschine) because all it does is reading byte code from a backbuffer, changing states based on the read data and jumping to other states (aka functions) if needed. If you try it out in Assembler (NASM) and write some kind of micro kernel, you'll see that as soon as the CPU has finished reading the assembly code, the computer does nothing because the FSM ended

no I dont mean exactly unity and C# .

at all how player , communicates with code?

(in case of unity Unityplayer.dll and assemblycsharp.dll

)

Scripting APIs are much like any other code - it's just one set of functions calling other functions. Arguably Unity doesn't have a 'scripting' API, although they call it that - it's a compiled language just like any other. They provide several useful objects which you can access in C# and which themselves access C++ objects to do some of the hard work for you.

If you want to know how regular scripting is done at a low level, and how one language can connect to another, then a good place to start is to look at how Lua can be used to wrap C and C++ programs. http://lua-users.org/wiki/BindingCodeToLua

Repixel said:
no I dont mean exactly unity and C# .

Repixel said:
at all how player , communicates with code? (in case of unity Unityplayer.dll and assemblycsharp.dll )

You know that you are clashing yourself here? I explained how this works on the examples of Unity/C# and C++/Lua, if you want to get a better answer just ask a better question