: _start is the actual entry point to the program. The linker will do whatever the OS requires to go there. main is the C or C++ entry point. The C/C++ runtime library contains a _start function that calls the constructors of global variables and sets up the argc and argv parameters for main, then calls it.
|Too lazy to read documentation at the moment.|
There's the root of all your assembly problems. RTFM, my friend. RTFM.
|In CPUs from 20 or so years ago, and possibly in some rudimentary modern CPUs (I'm not really sure if there are any new CPUs that don't use microcode), instructions would instead be implemented directly on the CPU's circuitry.|
You've got it backwards. Original processors were hard coded. As they became more complex, they started using microcode. I think this was around the mid 80's. Then in the early 90's Hennessey and Patterson showed that computers could be made faster by employing less
complex instruction sets, not more
, and RISC was born. This meant going back to direct execution (no microcode) and resulted in a big leap in processor speeds at that time. Today I think every processor is RISC except the x86, which brute forces speed at the cost of enormous numbers of transistors. In particular, ARM, which powers most small devices like phones and tablets, is a RISC processor.
The big insight that led to RISC was the realization that, for the most part, people
no longer wrote assembly code, compilers
did. Compilers can easily deal with whacky time saving measures in the instruction set that people would find hard to keep straight.
I haven't written any assembly code in years, but I do find it helpful in debugging. Sometimes the symptom shows up in a library routine and you have to slog through the assembly to see what the problem is. In those cases, you have to know assembly obviously.
Also, I think it's very helpful to understand what the processor is doing under the hood. There are times when this helps you write better code.