If CPU can understand and execute binary files on its own, then why does it still need compiler to execute compiled code? For example when I compile my cpp program for addition it produce .exe file which i assume to contain binary instruction to add two given number. Then I uninstalled gcc compiler and try to run exe file, it wont run. it produce error like gcc compiler is missing. Why so?

 

A compiled program does not require the compiler to execute. Your description is confusing. Did it complain that a library was missing? What was the error, exactly?

A compiler takes a high level language like C++ and compiles it isn't a low level language like machine language which has instructions that can be executed by the CPU directly. The purpose is to make programming complex programs easier for humans. You could write your program in a lower level language but as the complexity of it increased the difficulty would grow even faster.

It is not necessary for the compiler which produced the executable (.exe) to be present on the computer executing it.

 

It may be possible when you uninstall gcc it may also remove libraries needed to rrun. I am assuming you are on Windows which typically doesn't use GNU type programming out of the box.

 

Yep, probably needs a .dll from the gcc installation. There is probably an option when building that links everything statically, which means the .exe would run without needing the .dll

Bob

 

A compiled program does not require the compiler to execute. Your description is confusing. Did it complain that a library was missing? What was the error, exactly?

A compiler takes a high level language like C++ and compiles it isn't a low level language like machine language which has instructions that can be executed by the CPU directly. The purpose is to make programming complex programs easier for humans. You could write your program in a lower level language but as the complexity of it increased the difficulty would grow even faster.

It is not necessary for the compiler which produced the executable (.exe) to be present on the computer executing it.

Ok then take example of JVM, why running .class (java bytecode) require JVM?

 

Ok then take example of JVM, why running .class (java bytecode) require JVM?

A Java Virtual Machine is completely different from a C++ compiler. Java is a just in time (JIT) compiled language. A jar file is byte code, not an executable, the JVM runs the byte code.

With C++ the code is compiled into machine instructions, and if you statically link it, it contains all the resources it requires.

 

Also keep in mind that it's not simply a matter of a CPU being capable of executing raw instructions. Executable formats (eg: EXE, ELF) are actually quite complex, containing things like imports, exports, symbol tables, stack limits, and so forth that all have to be navigated and decyphered by the "loader" in order to start the program up.

FWIW, Windows use to run "raw" COM files (which contained fully executable code starting from the very first byte of the file) but those haven't been natively supported for many years now. (You may still be able to install some kind of emulation layer that can effectively get them to work. Can't think of any off the top of my head however.)

 

If CPU can understand and execute binary files on its own, then why does it still need compiler to execute compiled code? For example when I compile my cpp program for addition it produce .exe file which i assume to contain binary instruction to add two given number. Then I uninstalled gcc compiler and try to run exe file, it wont run. it produce error like gcc compiler is missing. Why so?

There is an interface layer between the CPU and your program, that is the OS, your CPP program has been compiled to a code which is executable on the OS you have, which in your case seems to be a Windows OS, but I don't understand why you are using GCC on Windows. (Maybe you are using Linux Subsytem for Windows, that is why you are using GCC?) Each OS abstracts the interface between the CPU, other hardware on your computer with your program, your program has been compiled for that OS, you program hasn't been compiled to the pure machine code which the CPU can execute without any OS.

Are you double clicking the exe file or running it from command line, maybe you are not running the compiled executable but recompiling everything through GCC, that could be why you are getting errors when you uninstall GCC.

 

Ok then take example of JVM, why running .class (java bytecode) require JVM?

Can I ask, have you tried removing the compiler and finding your program does not work ?

As for JAVA, as mentioned already, its compiled to JVM, that way it can run on any JVM , and the JVM is the bianry which runs on the CPU firectly.

 

Funny enough I totally agree with the OP...

I wrote a program in assembly for the PC some time ago. I used the A86 assembler.. It ran on Dos ~ win98.. When windows 7,8 and 10 came along it struggled... I downloaded visual studio, re-assembled for 64 bit and it now runs on win 10... Ahh!! but!! it doesn't port to another computer until you install visual studio.. Not just visual studio.. THE EXACT SAME visual studio version.. I too thought this is garbage... It's assembled code for the PC....

I use Lazarus ( pascal ) and that doesn't do this... I write some code at home and take the executable to work and it runs without any DLL's or "environmental" issues..

 

Funny enough I totally agree with the OP...

I wrote a program in assembly for the PC some time ago. I used the A86 assembler.. It ran on Dos ~ win98.. When windows 7,8 and 10 came along it struggled... I downloaded visual studio, re-assembled for 64 bit and it now runs on win 10... Ahh!! but!! it doesn't port to another computer until you install visual studio.. Not just visual studio.. THE EXACT SAME visual studio version.. I too thought this is garbage... It's assembled code for the PC....

I use Lazarus ( pascal ) and that doesn't do this... I write some code at home and take the executable to work and it runs without any DLL's or "environmental" issues..

It's still using system traps and system memory locations supplied and installed on the system by another process even if the code was originally written in assembler. There is nothing magical about an assembled program from a A86 assembler and linkage that makes it independent of the OS and system libraries needed for X program to execute on the system.

 

You don't need a compiler. I did the RCA1802 by hand. I had a list of HEX codes that I entered with a keypad.

The venerable PDP-11 had a console with switches, displays and modes. In the early days, You entered a small program by hand, that "booted" the first block of a device. That code executed and brought in the rest of the operating system.

An early BIOS equivalent.

 

You don't need a compiler. I did the RCA1802 by hand. I had a list of HEX codes that I entered with a keypad.

The venerable PDP-11 had a console with switches, displays and modes. In the early days, You entered a small program by hand, that "booted" the first block of a device. That code executed and brought in the rest of the operating system.

An early BIOS equivalent.

The DECSystem 20 was a mashup of a PDP 11 and a DECSystem 10. The PDP 11 was a front end processor.

It loaded its OS from the system hard drives. But when the hard drives failed, you had to toggle the boot loader from the front console switches.

I had to do this more than once.

 

It really doesn't matter if it's toggled in by hand or an executable created using a compiler system unless your one static linked program is running bare-metal with no OS, no bios support, no linked libraries, with the complete code needed to run all possible routines within it's own code. The fact a computer CPU can execute a set of instructions is pretty irrelevant to if X program generated from assembler source, HLL compiler source or toggle switches can execute within X computer system environment without support from other computer system elements.

 

We had dual drives that were like 65MB or whatever the size of washing machines. Backup was made to magnetic tape. DEC has a restore program that required toggling a loader, I believe. I wrote a program to do the restore while online by opening the other disc non file structured.
That was a PDP 11/50. Later I dealt with the 11/2, 11/23 and the 11/23+.

 

It really doesn't matter if it's toggled in by hand or an executable created using a compiler system unless your one static linked program is running bare-metal with no OS, no bios support, no linked libraries, with the complete code needed to run all possible routines within it's own code. The fact a computer CPU can execute a set of instructions is pretty irrelevant to if X program generated from assembler source, HLL compiler source or toggle switches can execute within X computer system environment without support from other computer system elements.

I suppose "run time files" are the new norm ( to coin a new phrase ) I know that lazarus ( pascal ) just puts them all in the executable.. That's why they are a little large.. But portability... Well its got to be more helpful..