When you compile your code, you creating so called "object" code that already(in most cases) depended on system libraries (printf for example) then you code wrapped by linker that will add kind of program loader that only particular operation system can recognize (that is why you can't run program compiled in windows on Linux for example) and know how to unwrap your code and execute. So you program is as a meat inside of a sandwich and can be ate only as a bundle, in whole.

Recently I was reading up on Kernels and I found out that programs cannot access the hardware directly but have to go through the kernel.

Well it half way true, if your program is a kernel mode driver then actually you can access directly hardware if you know "how to talk" to hardware, but usually (especially for undocumented or complicated hardware) people using drivers that are kernel libraries. This way you can find API functions that know how to talk to hardware in almost human readable way without need to know addresses, registers, timing and bunch of other things.

will each instruction in this machine code be directly be executed from the memory (once the code is loaded into the memory by OS) or will each each command in the machine code still need to go through the OS(kernel) to be executed

Well, kernel is as a waitress, which responsibility is to walk you to a table and serve you. The only thing it can't do - it is eat for you, you should do it on your own. The same with your code, kernel will unpack your program to a memory and will start your code which is machines code executed directly by CPU. A kernel just need to supervise you - what you allowed and what you're not allowed to do.

it not explain if the machine code that is generated after compilation is an instruction to the CPU directly or will it need to again go through the kernel to create the correct instruction for the CPU?

Machine code that is generated after compilation is an instruction to the CPU directly. No doubt on that. The only thing you need to keep in mind, not all code in compiled file are actual machine's/CPU code. Linker wrapped your program with some meta data that only kernel can interpret, as a clue - what to do with your program.

What happens after the machine code loaded on to the memory? Will it go through the kernel or directly talk to the processor.

If your code just a simple opcodes like addition of two registers then it will be executed directly by CPU without kernel assistance, but if your code using functions from libraries then such calls will be assisted by kernel, as in example with waitress, if you want to eat in a restaurant they would give you a tools - fork, spoon (and it still their assets) but what you will do with it, - it up to your "code".

Well, just to prevent flame in comments - it is really oversimplified model that I hope would help OP understand base things, but a good suggestions to improve this answer are welcome.

When you compile your code, you create so-called "object" code that (in most cases) depends on system libraries (printf for example), then your code is wrapped by linker that will add kind of program loader that your particular operating system can recognize (that is why you can't run program compiled for Windows on Linux for example) and know how to unwrap your code and execute. So your program is as a meat inside of a sandwich and can be eaten only as a bundle, in whole.

Recently I was reading up on Kernels and I found out that programs cannot access the hardware directly but have to go through the kernel.

Well it is halfway true; if your program is a kernel mode driver then actually you can access directly hardware if you know how to "talk" to hardware, but usually (especially for undocumented or complicated hardware) people use drivers that are kernel libraries. This way you can find API functions that know how to talk to hardware in almost human readable way without the need to know addresses, registers, timing and bunch of other things.

will each instruction in this machine code be directly be executed from the memory (once the code is loaded into the memory by OS) or will each each command in the machine code still need to go through the OS(kernel) to be executed

Well, the kernel is as a waitress, whose responsibility is to walk you to a table and serve you. The only thing it can't do - it is eat for you, you should do that yourself. The same with your code, kernel will unpack your program to a memory and will start your code which is machine code executed directly by CPU. A kernel just need to supervise you - what you are allowed and what you're not allowed to do.

it not explain if the machine code that is generated after compilation is an instruction to the CPU directly or will it need to again go through the kernel to create the correct instruction for the CPU?

Machine code that is generated after compilation is an instruction to the CPU directly. No doubt on that. The only thing you need to keep in mind, not all code in compiled file are actual machine's/CPU code. Linker wrapped your program with some meta data that only kernel can interpret, as a clue - what to do with your program.

What happens after the machine code loaded on to the memory? Will it go through the kernel or directly talk to the processor.

If your code is just simple opcodes like addition of two registers then it will be executed directly by CPU without kernel assistance, but if your code using functions from libraries then such calls will be assisted by kernel, as in example with waitress, if you want to eat in a restaurant they would give you a tools - fork, spoon (and it still their assets) but what you will do with it, - it up to your "code".

Well, just to prevent flame in comments - it is really oversimplified model that I hope would help OP understand base things, but good suggestions to improve this answer are welcome.

When you compile your code, you creating so called "object" code that already(in most cases) depended on system libraries (printf for example) then you code wrapped by linker that will add kind of program loader that only particular operation system can recognize (that is why you can't run program compiled in windows on Linux for example) and know how to unwrap your code and execute. So you program is as a meat inside of a sandwich and can be ate only as a bundle, in whole.

Recently I was reading up on Kernels and I found out that programs cannot access the hardware directly but have to go through the kernel.

Well it half way true, actually you can access directly hardware if you know "how to talk" to hardware, but usually (especially for undocumented or complicated hardware) people using drivers that are kernel libraries. This way you can find API functions that know how to talk to hardware in almost human readable way without need to know addresses, registers, timing and bunch of other things.

will each instruction in this machine code be directly be executed from the memory (once the code is loaded into the memory by OS) or will each each command in the machine code still need to go through the OS(kernel) to be executed

Well, kernel is as a waitress, which responsibility is to walk you to a table and serve you. The only thing it can't do - it is eat for you, you should do it on your own. The same with your code, kernel will unpack your program to a memory and will start your code which is machines code executed directly by CPU. A kernel just need to supervise you - what you allowed and what you're not allowed to do.

it not explain if the machine code that is generated after compilation is an instruction to the CPU directly or will it need to again go through the kernel to create the correct instruction for the CPU?

Machine code that is generated after compilation is an instruction to the CPU directly. No doubt on that. The only thing you need to keep in mind, not all code in compiled file are actual machine's/CPU code. Linker wrapped your program with some meta data that only kernel can interpret, as a clue - what to do with your program.

What happens after the machine code loaded on to the memory? Will it go through the kernel or directly talk to the processor.

If your code just a simple opcodes like addition of two registers then it will be executed directly by CPU without kernel assistance, but if your code using functions from libraries then such calls will be assisted by kernel, as in example with waitress, if you want to eat in a restaurant they would give you a tools - fork, spoon (and it still their assets) but what you will do with it, - it up to your "code".

Well, just to prevent flame in comments - it is really oversimplified model that I hope would help OP understand base things, but a good suggestions to improve this answer are welcome.

When you compile your code, you creating so called "object" code that already(in most cases) depended on system libraries (printf for example) then you code wrapped by linker that will add kind of program loader that only particular operation system can recognize (that is why you can't run program compiled in windows on Linux for example) and know how to unwrap your code and execute. So you program is as a meat inside of a sandwich and can be ate only as a bundle, in whole.

Recently I was reading up on Kernels and I found out that programs cannot access the hardware directly but have to go through the kernel.

Well it half way true, if your program is a kernel mode driver then actually you can access directly hardware if you know "how to talk" to hardware, but usually (especially for undocumented or complicated hardware) people using drivers that are kernel libraries. This way you can find API functions that know how to talk to hardware in almost human readable way without need to know addresses, registers, timing and bunch of other things.

will each instruction in this machine code be directly be executed from the memory (once the code is loaded into the memory by OS) or will each each command in the machine code still need to go through the OS(kernel) to be executed

Well, kernel is as a waitress, which responsibility is to walk you to a table and serve you. The only thing it can't do - it is eat for you, you should do it on your own. The same with your code, kernel will unpack your program to a memory and will start your code which is machines code executed directly by CPU. A kernel just need to supervise you - what you allowed and what you're not allowed to do.

it not explain if the machine code that is generated after compilation is an instruction to the CPU directly or will it need to again go through the kernel to create the correct instruction for the CPU?

Machine code that is generated after compilation is an instruction to the CPU directly. No doubt on that. The only thing you need to keep in mind, not all code in compiled file are actual machine's/CPU code. Linker wrapped your program with some meta data that only kernel can interpret, as a clue - what to do with your program.

What happens after the machine code loaded on to the memory? Will it go through the kernel or directly talk to the processor.

If your code just a simple opcodes like addition of two registers then it will be executed directly by CPU without kernel assistance, but if your code using functions from libraries then such calls will be assisted by kernel, as in example with waitress, if you want to eat in a restaurant they would give you a tools - fork, spoon (and it still their assets) but what you will do with it, - it up to your "code".

Well, just to prevent flame in comments - it is really oversimplified model that I hope would help OP understand base things, but a good suggestions to improve this answer are welcome.