All of the high-level languages that we use (because they look like English and we can read and understand) actually exist because each is defined by a Compiler. A Compiler is another program that has a range of defined words it can recognize, and a pre-set whole routine for each word that can convert that into the hexadecimal machine code the computer circuits actually can execute. It also has a whole bunch of rules of syntax - how words and symbols and numbers can be deciphered into smaller steps that each can be translated into machine code. Then it has all sorts of programmer aids that can determine that a certain input phrase cannot be understood for translation, so it displays instead an error message the user may be able to understand to use in correcting the input. The final output of a Compiler is a complete string of machine code the computer can execute, written as an executable file. The computer's Operating System, using a small range of commands its own Command Interpreter can understand, can load such an executable file and start it running.
A Compiler, by its fixed ability to respond to a limited number of command words, defines the language. BUT it also MUST be written for a particular CPU processor which has its own fixed set of recognized operations.
In the old days, the LINK step was the way that a programmer could specify that a source code set also required the use of some other pre-compiled subroutines in a library file. This step ensured that the required routines were found and added to the executable file before the entire setup was actually started. AFTER that, the GO step actually initiated running the final group of code. The comparable structures today are the .dll files - named for Dynamic Link Library - which can be used by executable code as sources of subroutines, provided that are made available to that code.
In the earlier days of desktop microcomputers it was common to have the Operating System also include what is known as an Interpreter - VERY often a BASIC interpreter - which again defines the language and must be customized to the processor and other hardware in the system. In this system there was no Compiler or Linker. High-level code (in BASIC, for example) was written and stored as text code exactly as written. When the OS command to RUN was executed, it started the Interpreter. That tool read the text file one line at a time, translated it into machine code, executed that code, then returned to process the next line. This process makes the machine do a lot more work for each line of original code (compared to pre-compiled code) and slows things down, but it makes interactive code development and debugging easier. Most interpreters have no simple way to access external pre-compiled routines in libraries, but one uses subroutines in the main code instead. In some cases, actual Compilers were also developed for some interpreter-based languages. AFTER the complete code was developed and debugged under the Interpreter system, that same code file could be run through a compiler to generate an executable file that could be stored and then run much faster (with no line-by-line interpretation steps) under the OS.
If you were to use some tool to examine the string of hexadecimal values stored in a section of RAM where an executable file is stored, it would appear to almost everyone as meaningless. But each value represents either an instruction, an address in RAM, or a data value. People who actually do this, however, normally use a tool called an Assembler. It can display the hexadecimal code from a section of RAM, and alongside that the Assembly language symbols for the meaning of the instruction codes. Used correctly, this tool allows one to read exactly what the compiled code set does, and even allows one to write in the Assembly language. However, that requires a very complete understanding of how computers do their work - in particular, the exact processor and system you are working with - and is VERY slow and VERY poor for debugging, so virtually nobody does this any more. Machine code accessed this way is so complex and different from a high-level language that it is virtually impossible to translate it back into any high-level language. The very best that might be done with enormous work would be to understand absolutely every action of the entire executable file under all circumstances, and then re-write a new set of high-level code to produce the same results. That's a HUGE reverse-engineering task. In almost any case, a different route would be taken to reproduce the work of an established executable.
Facebook
Twitter