QUOTE
I'm just curious, but what does a programming language run off of, or like how does everything you type in do the task?
does someone program a programming language with another one?
how is that one programmed?
i'm thinking and i think it might be binary or, ASCII, or that one lanuage, umm , hex- something.
just curious do any of you know?
Well, I deliberately skipped my university's "Compilers & Interpreters" course in the third-year after a single lecture - it was an incredibly dull and complicated subject. This is an extremely simplified explanation.
Basically, a compiler is a program like any other that just takes some text and converts it to machine code (actual 1's and 0's that the CPU runs directly - you might know it better as an "executable" or "program") and then saves it somewhere.
When you want to write, say, C code and put it on a computer, you use a C compiler. It "converts" the C to machine code that the CPU just runs. Note that usually this compiler DOES NOT run on the CPU that you are aiming at - most GP2X software is *COMPILED* on a normal PC with a compiler that outputs "ARM" code (the type of chip in the GP2X) - but it *OUTPUTS* machine code for the chip that you want (called cross-compiling). So a PC compiler will output "ARM" code that you can transfer to an ARM device somehow (usually by putting it into a memory chip) and make it run.
But who writes the compiler, I hear you ask? That's an incredibly complicated program that is usually only written once for each new type of "chip" - GCC (the most-common collection of various compilers used in open-source software) has a compiler for ARM, one for x86 ("normal" PC chips), one for 68000, and so on. Writing a compiler is a notoriously difficult task that requires a complete knowledge not only of every quirk of the programming language itself but of the target chip.
The programming language C exists because in the past "porting" a compiler to another type of machine was a time-consuming task that was usually done in something very, very close to machine code (literally, you are giving the computer the exact bytes that it should put into its CPU for every cycle). When early-UNIX was being ported to another chip, the language C was invented - it's a real programming language but was written with this exact purpose in mind. C is a very low-level language (pedants: I'm simplifying, not using the real definition of high/low level) - converting from C to actual machine code is a quite trivial process (relatively speaking). So *writing* a program that can take in C "code" and produce machine code for a new chip tends to be quite simple.
This allows people to do nothing more than create a C compiler for a new "chip" and they can then compile the C code for all the important parts (e.g. Linux is written in C, compilers for other languages are usually written in C, device drivers are usually written in C, etc.) and then it automatically "works" on the new chip (It's not quite as easy as it sounds, but that's the gist of it).
Modern compilers, even C compilers like GCC, tend to be written in C itself (yes, I know, it sounds absolutely crazy), so when a new type of "chip" is made, the only thing that *needs* to be written for it is a very, very primitive C compiler with the most basic of features. You can use that to compile a "real" C compiler for the new chip, and that compiler has EVERYTHING that's in C. Then you can use that "full" C compiler to compile one of the myriad other programming languages and use *those* to actually write software for the machine.
So basically:
- New Chip
- Write a "Simple" C Compiler to turn "simple" C into "New Chip" Machine Code (this is usually written in Machine Code itself)
- Convert a "Full" C Compiler to Machine Code using this simple compiler.
- Use the "Full" C Compiler to turn "Full" C in Machine Code (Other Compilers, Linux, Windows, Device Drivers, the rest of the software, etc.)
Steps are sometimes missed out (e.g. sometimes a "Full C" compiler is written straight away, sometimes the new chips are similar to the old ones or have compatibility with them, so you don't need to write new compilers each time, etc.).
To complicate matters, most compilers now are written in C themselves or don't convert directly to machine code (they are technically "interpreters", and need a special program which IS written in machine code to "run" them). So there's a massive chain of software which depends on a massive chain of various compilers but which ultimately culminates in some poor sod somewhere hand-writing a small compiler in native machine code (literally 0's and 1's but we tend to use "assembly" instead, which is just a human-readable symbolic representation of those 0's and 1's). This is typically done exactly once for each type of chip and typically the person to do this would be, for example, someone who works for the chip manufacturer (e.g. ARM, Intel etc.) or someone who works for a compiler-supplier (e.g. Microsoft, Borland, GCC, etc.). This is why Intel have a (very expensive) compiler. Some "new" chips come with their own C compiler that's been written by the chip manufacturer, etc.
Writing a compiler is quite possibly the most horrible job in the IT world. Writing one in machine code for a chip that you don't know is worse. But somewhere, every time a new type of chip is released, some poor sod ends up doing it. Nowadays, new *types* of chips are rare but they are still produced. Most new chips are based on similar older chips so getting that all important first-compiler is just a matter of using one that already exists for the old chips.
Eventually, though, you will trace everything back to some poor sod coding directly a compiler in "machine code".
