Elucidation solicited, please.

[cloasters]

First off, I'm a dummy in the software department. Can I ask a very basic question, please?

Do CPU's "translate" program wording so that it makes sense to the them? Or is it a given that modern CPU's handle every one of the many programming languages?

I'd guess that big iron RISC processors specialize in olde through modern programming languages that are 64-Bit?

And x86 CPU's are befuddled by say, Cobol. But are happy with before Basic through C#?

Thank you for taking the time and effort on my behalf!

[Rackne]

Assuming we're talking about high level languages like VB, Pascal, C++ etc, before programs can be run they have to be translated from source code (what the programmer writes) into object or machine code depending on what you want to call it.

This is done by a compiler or interpreter, which are language specific.

Compilers convert all the source code into object code at once and create a "standalone" program which will run independently of the interpreter. eg they might make a .exe file. This can be a time consuming process if you have a lot of code to compile so isn't ideal when developing as one tiny change in code requires all the code to be compiled again before it can be tested. For small programs this isn't much of an issue but when there's more than 1000 lines of code things begin to take a while. Compilers also hide the source code from the user whcih means people can't copy, steal or alter your program.

Interpreters are most commonly used during development as they convert one line of source code to object code at a time, execute it then get the next line of source code. Good during development cos they crash as soon as an error is found which makes modifying mistakes quicker than using a compiler as you don't have to reload and recompile the whole program every time you make a slight change. However interpreted code will always run slower than compiled code because translation is occuring as the program runs. Also, it exposes your source code.

I'm not going to go into all the steps of machine/object code generation unless asked.

As to the processor languages will run on, don't know specifics, not my area of expertise. Low level languages like assembly language are machine orientated (ie will only work for one type of chip) while high level langauages are in theory portable between different machines provided there is an appropriate compiler or interpreter available.

[cloasters]

Thank you very much for providing this information, Rackne!
May I ask another Q, please?

Where is a compiler located? Is it included with an OS?

[Allan]

I think (at least for Java) the compiler is a part of the Java SDK (Software Development Kit).

The compiler is a "program" by itself. We used a compiler called javac (for java compiler?!), I bet there are others out there though. But it came with the SDK.

In "dintprog" (Introduction to programming) I wrote the code in Emacs, compiled it with Javac and ran it with java...

[Rackne]

Linux comes with some compilers included, Windows doesn't. Compilers tend to be available for download if they're free, or come with development environments like Visual Basic and other Microsoft offerings.

The standard Java compiler is indeed javac, which Sun distribute for free and which runs from the command line.

I write most of my code in gvim then compile it with whichever compiler necessary.

[Superman]

vim rocks, emacs sucks, end of story

The GNU project offers compilers for many languages, including C, C++, Java, Fortron, and Ada (I think, hehe) via their gcc project. That's for Linux, BTW.

[Rackne]

Never tried emacs but vim does indeed rock.

[cloasters]

Another "duuh" question if you have the time, please.

Does any processor handle "machine code" only? If so, do you write in programming language that is later "dumbed down" for computers? Or do you write in "machine code" that is then "translated" into instructions that fit the desired programming language?

Is it safe to assume that you write the program in a language that approaches English(with plenty of what are usually known as exclamation points, brackets, the other kinds of brackets, colons and lots of uppercase characters? If so, is this is what is "compiled" into machine code?

Sorry, I'm thick as a brick in this department!

[Aedan]

A processor only understands machine code, and more specifically, only the machine code for that processor will work on it. (Not quite true for some mainframes though) Hence, a program written for a Mac won't run on a PC, not just because the OS is different, but also because the processor effectively speaks a different language.

Machine code is effectively just a bunch of numbers stored in some memory locations, that just happen to make sense to the CPU.

Generally, they're fairly simplistic instructions, along the lines of...

Move data from A to B
Add A to B
Subtract A from B
Multiply A by B
Divide A by B
Compare A and B
Go to another bit of program if A was larger/smaller/equal/zero/notzero than B
Do nothing (Better known as NOP for No Operation)

Unless, of course, you're Intel, in which case you do stuff like:

Move data from B to A
Add B to A
Subtract B from A
...
and so on

Now, the really magic thing here is that A and B can be memory (RAM), IO space (like memory, but for Peripherals), registers (temporary storage on the CPU) or any mix!

Do these simple steps often enough, and quick enough, and you can make it seem like things are really happening!

A compiler does the magic work of taking your program and converting it into these basic steps. Obviously one instruction in a high level language can take many instructions (possibly hundreds) at the machine level.

Writing much code in Assembly code can be a lot of work. Each instruction in Assembly code has a direct corresponding instruction in the machine code. Assembly is friendlier, as it uses mnemonics instead of numbers. For instance, an instruction to load the contents of memory location 1234 into temporary store A could be represented like

MOVE 1234,A

In machine language, it might look like

17 10 18 52

There's a direct one-to-one relationship between the two, no matter how hard that might seem. For obvious reasons, most sane people prefer a higher level language!


The other thing that can be done is interpretation. This is where a program takes your code, instruction at a time, and interprets its actions and carries them out. This is much slower, as your program is running on another program that is running on the processor. It's basically like an emulator for the language!

Áedán

[cloasters]

Thank you Aedan! I'm actually going to be able to understand this post after reading it a few more times.

[Allan]

Originally posted by Superman
vim rocks, emacs sucks, end of story

Well, can you play TETRIS in vim? You can in emacs, hehe. Seriously, there are a lot of people who (when they get used to it) really love emacs... but it DOES take some getting used to.

[cloasters]

Originally posted by Áedán
A processor only understands machine code, and more specifically, only the machine code for that processor will work on it. (Not quite true for some mainframes though)Áedán

(Please excuse my snippery. I did it for brevity. Hated to, your's is an exceptionally helpful post.)

May I ask another question, please? If processors only understand machine code written specifically for them, how do Via and AMD CPU's survive in a predominantly Intel world?

I'm sure this is an ignorant question, sorry.

[Aedan]

Originally posted by cloasters
May I ask another question, please? If processors only understand machine code written specifically for them, how do Via and AMD CPU's survive in a predominantly Intel world?

That's not a stupid question. It's because Via and AMD work hard at making their chips understand the same instructions as Intel's chips. Intel's architecture is known as IA32 (Intel Architecture 32). When I say IA32, I mean Intel compatible.

More recently, AMD and Intel's chips have diverged. Things like Intel's SSE and AMD's 3DNow! are actually sets of instructions on the CPU.

If code is running on an AMD IA32 CPU, it has to know which instructions it can run. Hence, it's possible to query an IA32 CPU and find how what sets of instructions it understands. That's what certain CPU info programs do!

Áedán

[cloasters]

Thank you very much, Aedan! I figured that there must be a "translator" section of the CPU's, which converted the "foreign" machine code into code that the CPU "understands."

It's better to not have to do this. This "translator" might require lots of dedicated memory in an "L0" cache!

[SiGmA_X]

No, both vim and emacs suck (I hate them.. So confusing! I kept deleting stuff I didn't want to!) and nano p0wnz them all