Need Answer of A Question

[ahsan_b]

would anyone kind enough to resolve ma prob by answering the following question

"which one was made first
1. Compiler
2. Operating System"

if u have any reference please let me know


thanks for ur help in advance

[Rainbow32]

http://en.wikipedia.org/wiki/Compiler

[The Dude]

Interesting..

[Amiduffer]

Ah, now answer this!

Which came first, the chicken or the egg? ;)

[oracle128]

The Operating System was first, of course. Compilers weren't needed until programmers used interpreted languages.

[z1p]

The Operating System was first, of course. Compilers weren't needed until programmers used interpreted languages.Hmmm, it may just be a matter of semantics, but it seems to me that interpreted languages aren't compiled, they are interpreted at run time....

[oracle128]

Java and Python are classified as "interpreted languages" (which in this usage means is interpreted by a virtual machine), but they're compiled to bytecode first. Anything which isn't compiled first into some other form, and is interpreted by a virtual machine, is basically a script (there's no real definition of "script" though). Anything which isn't interpreted or compiled is machine code.

[z1p]

Still losing me. Why weren't compilers needed until there were interpreted languages? A fully interpreted language (like a scripting language) doesn't need a compiler.

[Rainbow32]

Ah, now answer this!

Which came first, the chicken or the egg? ;)
The chicken came first.

[oracle128]

"Compiling" is another term for "interpreted to another form" (which includes machine code), ie. any language that isn't machine code is an interpreted language (whether it be interpreted twice, into bytecode then machine code like Java, or just the once to machine code, in the case of C).
Not to be confused with the technical classification "Interpreted Language", which is any language which isn't pre-compiled. The difference being, an "Interpreted Language" is one which IS "compiled" (translated to machine code), but at runtime by a virtual machine.

[z1p]

"Compiling" is another term for "interpreted to another form" (which includes machine code), ie. any language that isn't machine code is an interpreted language (whether it be interpreted twice, into bytecode then machine code like Java, or just the once to machine code, in the case of C).
Not to be confused with the technical classification "Interpreted Language", which is any language which isn't pre-compiled. The difference being, an "Interpreted Language" is one which IS "compiled" (translated to machine code), but at runtime by a virtual machine.:confused:

See http://en.wikipedia.org/wiki/Compiled_language

[oracle128]

Yes, that's correct. Everything there supports what I'm saying, except for the line step-by-step executors of source code, where no translation takes place (in reference to interpreters), which is misleading - while the code itself is not "translated" at all, the interpreter (the virtual machine) needs to generate machine code from the language commands, which is essentially run-time compiling.

Think of it this way: logically, an interpreter just compiles code to machine code at runtime. In the same way, a compiler is just a program which interprets the code before runtime.

[z1p]

No, a compiler does not interpret code it syntactically and semantically parses the code and generates assembly language, which is then translated to object code. This is then processed by a linker generate a binary (machine level) executable.

An interpreter does not generate machine level code. Never ever.....
It takes an 'instruction' and runs some machine code (that was compiled as part of the interpreter) based on the 'instruction' it is processing. What you are talking about is Just-In-Time compilation and that is not the same as an interpreter.

[oracle128]

a compiler does not interpret code it syntactically and semantically parses the code and generates assembly languageHow does the compiler read the code then? Could it be that it interprets the code and converts it into assembly (aka machine code)?
An interpreter does not generate machine level code. Never ever.....And how does the system run the code from the interpreter? The system can't read the script. It can only understand machine code. Could it be that the interpreter compiles each command of the language into machine code, step by step, at runtime?

You're not misunderstanding my point, but rather the words I'm using. To "compile" code is to convert source code to another form. As in, "the Java Compiler (javac.exe) compiled my Java code to a .class file" or "the Bloodshed DevC++ Compiler compiled my C++ code into an executable assembly .exe file", or "cmd.exe compiled my dir command into machine instructions to fetch a list of the files in the current directory, then print them out into the command window". To "interpret code" is exacty the same thing: "The Java Compiler interpreted my commands into a .class file", or "Dev C++ interpreted my code to assembly code", or "cmd.exe interpreted my dir command into machine code".
A "Compiled Language" however is a different term, meaning, specifically, a language that is implemented to be pre-converted to machine code. Respectively, an "Interpreted Language" is one that is implement to be converted, step by step, to machine code at runtime. The vagueness of these latter 2 terms is shown by the fact that any language can be either compiled or interpreted, depending on the program doing the translating.

Logically, the only different between a "compiled language" and an "interpreted language" is not how the code is converted from source to machine/assembly (which is the same in both methods, it HAS to happen at some point), but when - 'compilation' being before a command in the source is to be executed, 'interpretation' only doing it at that specific point. Thus, JIT is compiling, because it picks up on commands before they need to be executed, even though this identification only happens at runtime.

Realistically, there are other differences between the two methods of implementation, mostly for performance reasons - but the logic is the same.

[Rainbow32]

So does this mean the chicken didn't come first:confused:

[oracle128]

So does this mean the chicken didn't come firstIt depends on one's beliefs. If you believe in evolution, then the egg came first. Whether or not it was a "chicken egg" depends on how you determine the species of an egg, because as far as I can tell there's no standard - if you believe the egg's species is determined by whatever creature laid the egg, then the egg was an "almost a chicken"'s egg, the creature that hatched was a chicken, and the chicken came first. If you believe the egg's species is determined by whatever creature will hatch from the egg, the chicken came first. There's a much better explanation of the biological answer on Wikipedia (http://en.wikipedia.org/wiki/Chicken-and-egg_problem).

However, if you're a creationist, assuming the supernatural creator of your belief is logical, it would have made more sense to create the chicken instead of waiting around for an egg, and thus the chicken magically appeared first. If your believed creator is not logical or intelligent, they probably created the egg first. If your believed creator is not supernatural, the egg would have been developed and fertilised first, so the egg came first. There's also a brief explanation of the thelogical side on Wikipedia (http://en.wikipedia.org/wiki/Chicken-and-egg_problem#Theological_answers), which raises another interesting point, of the "pro-life" crowd.

Realistically, there's no definite answer - not due to the question being a logical conundrum, but because of the vagueness of it. It comes down to a few points external to the question. What context is the question in? Biologically, what do you classify a "chicken", and what do you classify as an "egg"? Does the question refer only to a chicken egg, or an egg of any species? How would you define the species of an egg - the animal that laid it, or the animal that will hatch from it? Are you a creationist or not? Are you pro-life?

[jtdoom]

did the chicken have a BIOS?

:dizzy:

[z1p]

How does the compiler read the code then? Could it be that it interprets the code and converts it into assembly (aka machine code)?Where to begin.... Well, first off assembly and machine code are not the same thing. Assembly language is a human readable instruction set, while machine code is binary code that is executed by the CPU.
And how does the system run the code from the interpreter? The system can't read the script. It can only understand machine code. Could it be that the interpreter compiles each command of the language into machine code, step by step, at runtime?Actually, what you are describing here is JIT (Just In Time) compilation not interpretation. Yes, some Jave virtual machines do JIT, but that is a separate mode than its interpretive mode. [Sun's hotspot JVM for example]. In a pure interpretive language, the instructions being interpreted are never, I repeat never translated into machine code. Instead, the language is interpreted and the interpreter performs actions based on the commands. The only machine code that gets executed is the machine code that was generated when the interpreter was compiled.

You're not misunderstanding my point, but rather the words I'm using. To "compile" code is to convert source code to another form. As in, "the Java Compiler (javac.exe) compiled my Java code to a .class file" or "the Bloodshed DevC++ Compiler compiled my C++ code into an executable assembly .exe file", or "cmd.exe compiled my dir command into machine instructions to fetch a list of the files in the current directory, then print them out into the command window". To "interpret code" is exacty the same thing: "The Java Compiler interpreted my commands into a .class file", or "Dev C++ interpreted my code to assembly code", or "cmd.exe interpreted my dir command into machine code".
A "Compiled Language" however is a different term, meaning, specifically, a language that is implemented to be pre-converted to machine code. Respectively, an "Interpreted Language" is one that is implement to be converted, step by step, to machine code at runtime. The vagueness of these latter 2 terms is shown by the fact that any language can be either compiled or interpreted, depending on the program doing the translating.

Logically, the only different between a "compiled language" and an "interpreted language" is not how the code is converted from source to machine/assembly (which is the same in both methods, it HAS to happen at some point), but when - 'compilation' being before a command in the source is to be executed, 'interpretation' only doing it at that specific point. Thus, JIT is compiling, because it picks up on commands before they need to be executed, even though this identification only happens at runtime.

Realistically, there are other differences between the two methods of implementation, mostly for performance reasons - but the logic is the same.Gotta go... for now...

[z1p]

... To "compile" code is to convert source code to another form. As in, "the Java Compiler (javac.exe) compiled my Java code to a .class file" or "the Bloodshed DevC++ Compiler compiled my C++ code into an executable assembly .exe file", or "cmd.exe compiled my dir command into machine instructions to fetch a list of the files in the current directory, then print them out into the command window". You were correct till you got to "cmd.exe compiled my dir command into machine instructions to fetch a list of the files in the current directory, then print them out into the command window". The program cmd.exe does not compile the dir command, that it absurdity at its peak. That is like saying a program that takes two numbers as input and adds them together 'compiles' the two numbers. Take time and think about what you are writing. To "interpret code" is exacty the same thing: "The Java Compiler interpreted my commands into a .class file", or "Dev C++ interpreted my code to assembly code", or "cmd.exe interpreted my dir command into machine code".
A "Compiled Language" however is a different term, meaning, specifically, a language that is implemented to be pre-converted to machine code. Respectively, an "Interpreted Language" is one that is implement to be converted, step by step, to machine code at runtime. The vagueness of these latter 2 terms is shown by the fact that any language can be either compiled or interpreted, depending on the program doing the translating.

Logically, the only different between a "compiled language" and an "interpreted language" is not how the code is converted from source to machine/assembly (which is the same in both methods, it HAS to happen at some point), but when - 'compilation' being before a command in the source is to be executed, 'interpretation' only doing it at that specific point. Thus, JIT is compiling, because it picks up on commands before they need to be executed, even though this identification only happens at runtime.

Realistically, there are other differences between the two methods of implementation, mostly for performance reasons - but the logic is the same. I am struggling to respond to this last section. All i can say, is that an interpreted language is never converted to machine code. It is run within the context of the interpreter.

No matter how you quote or capitalize compile and interpret, they will never mean the same.

[sho-dan]

What about the rooster?

As you two take a break and down some refreshments, this site has helped me
in the learning and the understanding of computer history, give a read my follow rocket scientist. :dizzy:
Timeline of Computer History (http://www.computerhistory.org/timeline/?category=sl)

[Rainbow32]

would anyone kind enough to resolve ma prob by answering the following question

"which one was made first
1. Compiler
2. Operating System"

if u have any reference please let me know


thanks for ur help in advance
Grace Hopper wrote the first compiler, A-O,in 1949.
If the word "Operating system" means software then the first didn't come until more than a decade or so later.
http://en.wikipedia.org/wiki/Operating_system
The Incas used rope and pulley's as a sort of calculator and in doing so invented the first mechanical computer.

[z1p]

Grace Hopper wrote the first compiler, A-O,in 1949.
If the word "Operating system" means software then the first didn't come until more than a decade or so later.
http://en.wikipedia.org/wiki/Operating_system
The Incas used rope and pulley's as a sort of calculator and in doing so invented the first mechanical computer.

Thx for the info...

[Rainbow32]

I hope this puts an end to this thread. I haven't slept in 3 days researching and learning the history of computers and OS's, compiling, languages, machine code, Incas, zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzz

[oracle128]

Where to begin.... Well, first off assembly and machine code are not the same thing. Assembly language is a human readable instruction set, while machine code is binary code that is executed by the CPU.True, but assembly is just a human-readable form of machine code - other than its appearence, it's exactly the same thing. The system interfacing with the CPU (whether this be the OS or a virtual machine or emulator) converts the instruction set to a hex (or binary) code, which is then sent directly to the CPU. I know this process well from my months spent programming in Z80 assembly.
Actually, what you are describing here is JIT (Just In Time) compilation not interpretation. Yes, some Jave virtual machines do JIT, but that is a separate mode than its interpretive mode. [Sun's hotspot JVM for example].Already explained that JIT is just another form of compiling.
In a pure interpretive language, the instructions being interpreted are never, I repeat never translated into machine code. Instead, the language is interpreted and the interpreter performs actions based on the commands. The only machine code that gets executed is the machine code that was generated when the interpreter was compiled.Well, if you want to take that road, don't forget to apply it to a "Compiled Language" too. They don't get translated to machine code. Instead, the compiler reads the commands, then generates machine code from them. Just like an interpreter, except it does it all beforehand. In other words, like I originally said, the actions are exactly the same, it's only the point in time at which source code becomes machine code that differntiates compilation from interpretation.
You were correct till you got to "cmd.exe compiled my dir command into machine instructions to fetch a list of the files in the current directory, then print them out into the command window". The program cmd.exe does not compile the dir command, that it absurdity at its peak. That is like saying a program that takes two numbers as input and adds them together 'compiles' the two numbers. Take time and think about what you are writing.Well, software can't do the calculating. What does I wonder? The CPU? But that's absurd! A CPU can't magically read the input from a calculator program and know what to do with the input and the result! But wait, that's not what happens. What happens is, the calclator program takes the user input, and generates (compiles, interprets, if you will) an instruction to send to the CPU that calculates, and returns the result. It then displays the result (again, with another instruction set, this time telling the CPU which pixels to turn on and off on its graphics communication chanel - this is a collaborative effort of the calculator software, the OS, and likely, its underlying graphics library, eg DirectX). So yes, in that way, the calculation is "compiled".

I am struggling to respond to this last section. All i can say, is that an interpreted language is never converted to machine code. It is run within the context of the interpreter.

No matter how you quote or capitalize compile and interpret, they will never mean the same.Question: What's the similarities of the two?
Answer: They both take an input source and translate it to machine code.

Question: What's the difference between the two?
The point in time at which the source is translated to machine code.

The action is exactly the same, the only difference is when. Since the answer to the OP's question regarded only the process which took place, and not the point in time that process takes place with regards to the time between creating the source code and running it (which is negligable, in these circumstances), then an answer of either "compiled languages" or "interpreted languages" would have sufficed, since they are both the same concept. I could have said "compiled languages", but then that would have made unlearned viewers wonder if perhaps batch files or VBScript were created before operating systems. "Interpreted languages", I felt, gave more of an impression of "anything other than machine/assembly code" (a machine to assembly translater is little more than a lookup table; not a compiler, and not an OS - though one would likely embed an OS to interface it) than "compiled languages" would have.

If you would prefer, I could change my answer to "either compiled, interpreted, interfaced, translated, virtualized, or otherwise 'not directly transmitted to the processor' languages, scripts, instructions other than the native instruction set(s), commands, source code, markup, or other programmatic input that isn't a native instruction set". I chose not to confuse the people.

[z1p]

Question: What's the similarities of the two?
Answer: They both take an input source and translate it to machine code.Can't you see and understand that an interpreted language like Perl or Python does not get translated into machine code... That it why they are interpreted languages,not compiled.

Maybe this from a book on Python will help make it clear, http://swaroopch.info/text/Byte_of_Python:Introduction Interpreted
This requires a bit of explanation.

A program written in a compiled language is converted from the source language (such as C or C++) into a language that is spoken by your computer (binary code i.e. 0s and 1s) using a compiler with various flags and options. When you run the program, the linker/loader software copies the program from hard disk to memory and starts running it immediately.

Python, on the other hand, does not need compilation to a binary. You just run the program directly from the source code. Internally, Python converts the source code into an intermediate format called bytecodes and then the interpreter just runs the bytecode. This makes Python easier to use since you do not have to worry about compiling the program, making sure the libraries are installed properly, etc. among other things. This also makes your Python programs more portable since you can just copy your Python program to a different computer and it just works.


Already explained that JIT is just another form of compiling. Yes, Just In Time compiling is a form of compilation, BUT it is not doing run time interpretation. Instead of taking byte codes running them within the context of an interpreter [Virtual Machine], a JIT compiler compiles the byte codes into machine and the machine code is run natively on the computer. This is vastly different from an interpretive language and is only available in a few languages like Java and Mono and even then it is not available on all platforms.

What happens is, the calclator program takes the user input, and generates (compiles, interprets, if you will) an instruction to send to the CPU that calculates, and returns the result.You write software that dynamically generates new code.... You must be one of the few people around that does that. Not only is it difficult, it nearly impossible to maintain.

Most developers I know choose to use standard methods for code development, like using the common flow constructs of 'if' and 'while' along with functions or methods. That way the compiler (or interpreter) does all the work and you don't have to right the machine code generation for each platform you want to run on. :cool:

[Snurfen]

Oh no, it'll be Amiga versus Atari in round two............................

[oracle128]

Python, on the other hand, does not need compilation to a binary. You just run the program directly from the source code. Internally, Python converts the source code into an intermediate format called bytecodes and then the interpreter just runs the bytecode.And the 'interpreter' outputs what kind of code in its final run?
Yes, Just In Time compiling is a form of compilation, BUT it is not doing run time interpretation. Instead of taking byte codes running them within the context of an interpreter [Virtual Machine], a JIT compiler compiles the byte codes into machine and the machine code is run natively on the computer.No, it's pre-compilation, but at runtime. Hotspot, for example, can't take effect until the bytecode has already begin interpretation. It 'pre-emptively interprets' (another word for 'compiles) the code before it is needed at a given step. So it becomes machine code before it's needed, just like with regular compiling. The rest of the code, the stuff that isn't deemed worthy for JIT, has to wait until its called upon to become machine code. So the process it: pre-compile to bytecode (before runtime), pre-compile any "Hotspots" (at runtime), interpret the bytecode (at each step).

You write software that dynamically generates new code.... You must be one of the few people around that does that. Not only is it difficult, it nearly impossible to maintain.Nooooo, I do the only other possible alternative to that; I write calculator programs which have trillions of possibile calculations stored in it, and uses a lookup table to get answers. Because that's much smarter! (not) But oh, wait, a lookup table has to be stored in memory, and the memory needs to be accessed by the CPU...the only way to do that would be to pre-define the memory locations of the lookup answers. I guess that may be a problem if the memory is changed, or if the CPU decides to store the table at different memory addresses...

FYI, you don't need to manually code in a way to generate machine code calculations - intelligent programming and OS assistance take care of that. Perhaps take a look here (http://offog.org/code/) at "z80calc-0.1.tar.gz" to see what kind of programming is involved at the lower levels. This (http://www.ticalc.org/pub/text/z80/) may also be a good place to look. Note: Z80 is very similar to X86.

Theortical situation: What happens if I take a standard C compiler, but heavily modify it so it only compiles a line of code when its needed at runtime, executes that sequence of machine code, then moves on to the next line of source? It still does the same action, but only does it step by step. Why, I believe that sounds a heck of a lot like an 'interpreter'.

[Rainbow32]

Now I understand why Vista took so long to hit the streets.:dizzy:

[z1p]

And the 'interpreter' outputs what kind of code in its final run? Could it possibly be byte codes or was that a trick question? Didn't you read the info on Python I referred you to?

No, it's pre-compilation, but at runtime. Hotspot, for example, can't take effect until the bytecode has already begin interpretation. It 'pre-emptively interprets' (another word for 'compiles) the code before it is needed at a given step. So it becomes machine code before it's needed, just like with regular compiling. The rest of the code, the stuff that isn't deemed worthy for JIT, has to wait until its called upon to become machine code. So the process it: pre-compile to bytecode (before runtime), pre-compile any "Hotspots" (at runtime), interpret the bytecode (at each step).First, interpreting code and compiling code is not the same thing. Why don't you just admit it? Second, talking about Java Hotspot and interpreting is wrong as Hotspot is a JIT compiler, it is a different mode than interpreting Java, which is why it is a highlighted feature and can be enabled and disabled on its own.

Nooooo, I do the only other possible alternative to that; I write calculator programs which have trillions of possibile calculations stored in it, and uses a lookup table to get answers. Because that's much smarter! (not) But oh, wait, a lookup table has to be stored in memory, and the memory needs to be accessed by the CPU...the only way to do that would be to pre-define the memory locations of the lookup answers. I guess that may be a problem if the memory is changed, or if the CPU decides to store the table at different memory addresses...You seem to be having difficulty understanding how interpreted languages work. Let's see if I can clear things up.

Let's say I write program foo in a compiled language, cgo through the whole compilation process and end up with foo.exe.

And let's also say I write program bar in an interpreted language. Let's stay with Python for this example, so I'll have a file bar.py.

Now when foo.exe is run the machine code that was generate for it is fed to the CPU subsystem and run directly. The process that is running on the system is foo.exe.

However when I need want to run bar.py, I need to run the Python interpreter. It is the machine code that was generated when the Python interpreter was compiled that is passed to the CPU subsystem and run. How does the instructions that are part of the Python program bar accomplish what you want, you ask. Good question!!

What happens is the Python interpreter reads bar.py and translates it to bytecodes. Is it interpreting the instructions yet? Not really. At this time its just creating bytecode, which is very similar to compiling except the final result is not going to be machine code.

After we have the bytecodes, the interpretation begins. The Python interpreter takes the bytecodes and performs actions based the bytecodes. Does the bytecode get converted to machine code? No, they don't. If they did, that would be JIT compilation. What happens is based on the bytecodes sections of the machine code generated when the Python interpreter was compiled are executed. When you run bar.py the only machine code that ever runs in the CPU subsystem for that task is the machine code that was generated when the Python interpreter was compiled.

FYI, you don't need to manually code in a way to generate machine code calculations - intelligent programming and OS assistance take care of that. Perhaps take a look here (http://offog.org/code/) at "z80calc-0.1.tar.gz" to see what kind of programming is involved at the lower levels. This (http://www.ticalc.org/pub/text/z80/) may also be a good place to look. Note: Z80 is very similar to X86.Impressive portfolio you have there, but I'm not seeing the point you were trying to make with it. I have to say I didn't bother looking at the code and I don't intend to, I did my Z80/Z8000 assembly about 15-18 years ago and have moved on.

Theortical situation: What happens if I take a standard C compiler, but heavily modify it so it only compiles a line of code when its needed at runtime, executes that sequence of machine code, then moves on to the next line of source? It still does the same action, but only does it step by step. Why, I believe that sounds a heck of a lot like an 'interpreter'.NO.... THAT WOULD BE A JIT COMPILER. The code is being COMPILED into machine code Just In Time to be run.

[oracle128]

Could it possibly be byte codes or was that a trick question? Didn't you read the info on Python I referred you to?I'm sorry, I didn't realize an x86 CPU can understand proprietary Python bytecode.
When you run bar.py the only machine code that ever runs in the CPU subsystem for that task is the machine code that was generated when the Python interpreter was compiled.And how is this machine code different to pre-compiled, .exe machine code? I thought they were the same thing. So what you're saying is, there's two different types of machine code? Or is the "machine code" generated by the interpreter from bytecode not really machine code at all? If not, what is it? Or maybe you're saying that the Python interpreter is itself a CPU, and doesn't need to send instructions from the Python program to the system CPU to have them executed. I believe you've just won a Nobel Prize! The first PC made entirely of software!

NO.... THAT WOULD BE A JIT COMPILER. The code is being COMPILED into machine code Just In Time to be run.No, it wouldn't. JIT is a process to determine which commands are/will be needed more often than others, and those are pre-interpreted/compiled into machine code (either preemptively, like a CPU does with ILP; or by learning behaviour) for as long as the VM process is in memory. Its whole function is to AVOID the repetitive step-by-step runtime compilation of bytecode to machine code, and is a completely different function to the theoretical process I described.

[z1p]

I'm sorry, I didn't realize an x86 CPU can understand proprietary Python bytecode. If you'd take the time to try to understand what I have said you wouldn't be wasting every ones time asking such a question. See below.....
And how is this machine code different to pre-compiled, .exe machine code? I thought they were the same thing. So what you're saying is, there's two different types of machine code? Or is the "machine code" generated by the interpreter from bytecode not really machine code at all? If not, what is it? Let me refer to what I said in my last post. "When you run bar.py the only machine code that ever runs in the CPU subsystem for that task is the machine code that was generated when the Python interpreter was compiled." Now I never said the bytecodes generated by the Python interpreter is run on the CPU, as a matter of fact I said the only machine code that gets run is the machine code generated when the Python interpreter is compiled. I don't think I'm being obtuse here, but maybe I am.

Or maybe you're saying that the Python interpreter is itself a CPU, and doesn't need to send instructions from the Python program to the system CPU to have them executed. I believe you've just won a Nobel Prize! The first PC made entirely of software!As you well know, I'm not saying the Python compiler is a CPU. But it also doesn't send instructions to the CPU as you well know. I'm splitting hairs a bit here, but I feel I have to because you insist muddying the water with absurd comments. The closest a process could come to 'sending' machine code to the CPU is setting its program counter. It is the OS that controls what is run by the CPU and when it is run.

Once again I will repeat what I've said already as I don't know how to make it any clearer. "When you run bar.py the only machine code that ever runs in the CPU subsystem for that task is the machine code that was generated when the Python interpreter was compiled."

No, it wouldn't. JIT is a process to determine which commands are/will be needed more often than others, and those are pre-interpreted/compiled into machine code (either preemptively, like a CPU does with ILP; or by learning behaviour) for as long as the VM process is in memory. Its whole function is to AVOID the repetitive step-by-step runtime compilation of bytecode to machine code, and is a completely different function to the theoretical process I described.What you just described is basically how Java Hotspot works, but your theoretical process would still be a JIT compiler.

[Snurfen]

First, interpreting code and compiling code is not the same thing.

This statement is the absolute crux of this argument. It is utterly, totaly and incontravertibly true. Only a lawyer would try to weasle out of it!

Despite all the mucking around I do in posts here, I have been in the IT industry since March 1984 - continuously. In that time, I have worked on Mainframes, minis, midis, servers, thin-client blah blah blah. In that time, I have attended courses from ALL the MAJOR manufacturers and OS makers. Believe me, that statement above is the one truism that has carried throughout all of the material supplied by these big hitters.

Oracle, I don't want to be seen as attacking you personally, but mate, please back off, you are making a bit of a goon yourself here.

[oracle128]

So then please, in all your wisdom (either of you), answer this: how is machine code generated from Python different to machine code from an .exe?

Yes, the Python interpreter already knows that the '+' sign should mean to send the addition command to the CPU (among other things), which naturally goes through the OS first (but this is transparent, and certainly not relavent to anything discussed here), as well as whatever other hardware or software hooks and handlers are implemented on the system (again, which aren't relavent to the process). But then, that's exactly the same thing that a C compiler knows how to do. What, you think it magically knows how to generate native machine code based on the source code input? NO. This information is built into the compiler software in EXACTLY THE SAME WAY it's built into an interpreter. THERE IS NO DIFFERENCE in the way the source code (or bytecode) is translated from its current form and output to machine code. Why is that so difficult to understand? What, you think the generated machine code is somehow different if it came from an interpreter as opposed to a compiler? It's exactly the same thing! If I program a .exe to add 2 integers and do nothing else, the machine code will be generated for that (about 3 commands if I remember correctly - the first 2 being to set the registers). If I make a Python program do the same thing, what do you think is going to come out of the Python interpreter? The same 3 lines! And that machine code goes through the same process the C++ machine code does. C++ .exes have no more ability to go directly to the CPU than machine code from the Python interpreter does.

If you still don't understand why the modified C++ compiler I proposed is actually an interpreter, then why don't YOU explain just how one would implement a C++ interpreter in the way that you imagine it is meant to work?

[Snurfen]

Dunno and don't care ora. I'm just chopping your legs from under you as you are trying to obsfucate your original faux-pas with a load of rubbish.
Take a chill-pill fella, your the butt of many jokes around the ether with this pompous display.
R-E-L-A-X ;p

[z1p]

So then please, in all your wisdom (either of you), answer this: how is machine code generated from Python different to machine code from an .exe? Once again... There is no machine code generated from the Python code. I don't know how to say it any clearer..."the only machine code that gets run is the machine code generated when the Python interpreter is compiled."

Yes, the Python interpreter already knows that the '+' sign should mean to send the addition command to the CPU (among other things), which naturally goes through the OS first (but this is transparent, and certainly not relavent to anything discussed here), as well as whatever other hardware or software hooks and handlers are implemented on the system (again, which aren't relavent to the process). Once again the Python interpreter doesn't send anything to the CPU. Code within the Python interpreter is run based on the bytecodes that are being processed. I don't know how to say it any clearer..."the only machine code that gets run is the machine code generated when the Python interpreter is compiled."

But then, that's exactly the same thing that a C compiler knows how to do. What, you think it magically knows how to generate native machine code based on the source code input? NO. This information is built into the compiler software in EXACTLY THE SAME WAY it's built into an interpreter. THERE IS NO DIFFERENCE in the way the source code (or bytecode) is translated from its current form and output to machine code. Why is that so difficult to understand? What, you think the generated machine code is somehow different if it came from an interpreter as opposed to a compiler? It's exactly the same thing! If I program a .exe to add 2 integers and do nothing else, the machine code will be generated for that (about 3 commands if I remember correctly - the first 2 being to set the registers). If I make a Python program do the same thing, what do you think is going to come out of the Python interpreter? The same 3 lines! And that machine code goes through the same process the C++ machine code does. C++ .exes have no more ability to go directly to the CPU than machine code from the Python interpreter does.
For a reference here is a link to the Python bytecodes (http://www.python.org/doc/1.5.2p2/lib/bytecodes.html).

Now lets look at BINARY_ADD
Implements TOS = TOS1 + TOS.

Now your proposing that when the interpreter goes to process this instruction it creates the machine code for adding two numbers and then runs it. So it would have to have a buffer somewhere, we'll call it inst_buf. Then it will write the opcode to move TOS to a register. Then write the opcode to move TOS1 to another register. then write the opcode to add the registers together. then most likely write the opcode to return from subroutine. then call the code you just generated.

Now how I see it is when the interpreter runs across BINARY_ADD it calls its function to perform the function. Now let's assume that the Python interpreter is written in C. The code for the BINARY_ADD function would look something like
void binary_add_func {
int op1 = pop(); int op2 = pop();
push(op1+op2);
return; }Now this code is part of the interpreter and was compiled when the interpreter was compiled.

So when the binary_add byte code is seen, instead of writing all the opcodes to a buffer and executing that buffer, the function that adds the two numbers at the top of Python's internal stack is called.

If you still don't understand why the modified C++ compiler I proposed is actually an interpreter, then why don't YOU explain just how one would implement a C++ interpreter in the way that you imagine it is meant to work?A C++ interpreter would NOT generate machine code, but would generate a intermediate language which would be processed and would result in functions/ sections of the code with the interpreter being executed.

[oracle128]

Once again... There is no machine code generated from the Python code. I don't know how to say it any clearer..."the only machine code that gets run is the machine code generated when the Python interpreter is compiled."Once again the Python interpreter doesn't send anything to the CPU. Code within the Python interpreter is run based on the bytecodes that are being processed. I don't know how to say it any clearer..."the only machine code that gets run is the machine code generated when the Python interpreter is compiled."But how can I say it clearer? "If Python didn't output any machine code, the CPU couldn't execute any Python programs". The Python interpreter MUST output machine code in order for the language to work. The point being, that this final output of machine code is not only the same between interpreted and compiled languages, but is also the same across ALL languages, scripts, etc. The CPU doesn't care if the instruction set came from the Python interpreter or from a pre-compiled .exe. It doesn't know any different. It's the same stuff. I repeat, a CPU cannot understand Python source code or bytecode, or any other intermediate command set, compiled or not, or anything other than its native machine code. Is this machine code already contained within the interpreter, waiting for the necessary parameters to be defined, so it can be transmitted when needed? Why, yes, it is. I don't disagree with you on that point. But like I've already stated, the compiler works exactly the same way - the compiler, like the interpreter, knows which functions/commands relate to which machine code instructions, and only waits on a programmer to tell it what values to use for that instruction set (by calling upon the language's built in functions and keywords - like in the 'addition' example before). Hence, the programmer doesn't need to create the machine code, and the compiler/interpreter doesn't have to magically conjure up a set of instructions to perform the programmed statements, which is clearly what you think happens if you honestly believe the process of machine code creation is different between compiler and interpreter, as those are the only 2 other possibilities. It is not possible for an interpreter to store machine code instruction sets for every single possible program one could make - therefore, there has to be some form of machine code generation, even if it's only part of the instructions, that is based on what the programmer writes.

It really isn't that difficult to understand, but perhaps you need an analogy to do so. If a person (the CPU) can only understand English (machine code), then anything going to that person needs to be translated to English (machine code). Now, what if the information required was a book in Spanish (C++)? Well, the book needs to be translated from Spanish to English first (ie. Compiled). But what if the required information was a person talking in French? Well, we now need a French to English interpreter (code interpreter/scripting engine) to translate the speech, on-the-fly. What is the result of either method though? English. The person (CPU) knows no different.

Now, let's complicate things. Let's say, the information is another book in Spanish, but the translater only knows how to translate Spanish to French - so he does so (compiles to bytecode). Luckily, we still have our interpreter from before (bytecode interpreter) so we can then translate that French to English. The person (CPU) finally ends up with the information in English (machine code), and knows no different about where the information came from originally, or in what language or form it intially was.

Again, what's the final result? The information ends up in English, no matter which way you look at it. Sound familiar?

[z1p]

I was going to reply just as I have been doing, but decided that it really has gotten to be a waste of time repeating myself as it appears that either you refuse to comprehend or just are having a mental block with the concepts I'm trying to get across. So, since we have been focusing on Python as an example on an interpreted language, I figured I'd go to the source (literally) to make things clearer. (For your reference the source code for Python can be found HERE (http://www.python.org/download/).)

My starting point is in a file called compile.c. I have to admit that I really didn't want to start here 'cause I didn't want to deal with hearing 'see its says compile, so must be the same as a compiler', but for the sake of clarity it is the place to start. The function I started at in that file is "fold_binops_on_constants" and here is a code snippet from it.static int
fold_binops_on_constants(unsigned char *codestr, PyObject *consts)
{
PyObject *newconst, *v, *w;
Py_ssize_t len_consts, size;
int opcode;

/* Pre-conditions */
assert(PyList_CheckExact(consts));
assert(codestr[0] == LOAD_CONST);
assert(codestr[3] == LOAD_CONST);

/* Create new constant */
v = PyList_GET_ITEM(consts, GETARG(codestr, 0));
w = PyList_GET_ITEM(consts, GETARG(codestr, 3));
opcode = codestr[6];
switch (opcode) {
case BINARY_ADD:
newconst = PyNumber_Add(v, w);
break;As you can see, this is the code to process bytecodes. I'm focusing on the BINARY_ADD instruction as it fall in line with our previous examples. So, when a BINARY_ADD bytecode is found the function PyNumber_Add is called. So, let's look at its code next.PyNumber_Add(PyObject *v, PyObject *w)
{
PyObject *result = binary_op1(v, w, NB_SLOT(nb_add));

if (result == Py_NotImplemented) {
PySequenceMethods *m = v->ob_type->tp_as_sequence;
Py_DECREF(result);

if (m && m->sq_concat) {
return (*m->sq_concat)(v, w);
}
result = binop_type_error(v, w, "+");
}
return result;
}Now as you can see, the main line in the function is the line with 'binary_op1'. Now this is an area where the code starts getting complex as it uses defines, function pointers and abstract data types, so that the code can handle the wide variety of bytecodes. You can take my word on it or trace through the code yourself, but what happens next is it checks the arguments' object types and the opcode and determines what function to call. If we assume we're adding two floats we end up at the function 'float_add'.static PyObject *

float_add(PyObject *v, PyObject *w)
{
double a,b;
CONVERT_TO_DOUBLE(v, a);
CONVERT_TO_DOUBLE(w, b);
PyFPE_START_PROTECT("add", return 0)

a = a + b;

PyFPE_END_PROTECT(a)
return PyFloat_FromDouble(a);
}As you can see here there is no machine code being generated, instead it is just adding the 2 values and returning the result.

[oracle128]

As you can see here there is no machine code being generated, instead it is just adding the 2 values and returning the result.And those values get added how? By magic?

That code is pre-compiled into the Python interpreter, is it not? And it needs to accept variable input from the programmer, does it not? And these variables (the arguments) will be used in the function, which will then ouput x86 instructions, will it not? And these instructions are DYNAMICALLY GENERATED, are they not? Surprise! That's exactly what a compiler does too! (Though naturally, the first compilers, and lower level languages like C, would have been written in machine code originally - though it's quite possible, even plausible, to write a C++ compiler in C, a JVM in C++, a Python interpreter in VB, etc - but of course the resulting process is still the same.)

Because the way you say it, it makes you sound like you think every possible instruction set that one would need in order to create a functional program is HARD CODED into the Python interpreter, which is just ridiculous - there needs to be the dynamic generation of machine code dependant on the programmer's input. Otherwise you end up with stupid things like the interpreter just using a lookup table for every possible command, which of course not only leads to an incredibly inefficient compiler/interpreter, but also one that must be infinite in size to cover every possible input accepted from the programmer. But if that's what you'd rather believe, then so be it.
I mean, seriously, look at the logical possibilities:

1) The machine code is generated
a) The machine code is generated with a combination of existing knowledge of instruction sets, and the programmer's input. Therefore, an interpreter acts the same as a compiler, as far as the processes and input/output involved are concerned (and my original statement using "interpreted languages" as a catch-all for any non-native-machine-code programming language is correct)

2) The machine code is NOT generated
a) The machine code must be gathered somehow
i) The machine code is hard-coded into the interpreter/compiler, and is looked up when a source code calls for it (poor performance, compiler/interpreter's infinite size assuming unrestricted programmer input)
ii) The machine code is obtained from some external repository (poor performance, compiler/interpreter's infinite size assuming unrestricted programmer input)
iii) It's magic

b) The original source code or bytecode is the code that is sent to the CPU
i) The CPU understands the instructions. Therefore, the source/byte code is also machine code if it can be directly understoon by the machine
ii) The CPU rejects the instructions. The system fails. Either outcome 1) or 2)b) (or both) logically must therefore apply.
c) The compiler/interpreter only runs pre-defined instruction sets, ignoring programmer input. No longer compiling or interpreting anything, it becomes nothing more than an executable program

[Rainbow32]

would anyone kind enough to resolve ma prob by answering the following question

"which one was made first
1. Compiler
2. Operating System"

if u have any reference please let me know


thanks for ur help in advance
This has got to be the most off topic thread of all times, cause I don't think most of us know what the hell you 2 are talking about.:rotflmao:

[bAdWaYz]

I have learned a great deal myself.

[Rainbow32]

With the difference of opinions expressed?
They both make good points, at times, but which is right?

[z1p]

With the difference of opinions expressed?
They both make good points, at times, but which is right?

You want my take on it.

I say that a compiler and and interpreter are different. The big difference is that the ultimate output of a compiler is machine code (an executable) that can be run. On the other hand an interpreter processes a command language, other than machine code, and performs actions "described" by this command language. Basically, I say all the actions that an interpreter takes are compiled into it.

oracle seems to believe that the interpreter generates machine code on the fly and then executes it.

[BTW I'm right ;)]

[Rainbow32]

[BTW I'm right ]
I know you are. Besides it's answer 42 right?

[Snurfen]

Well, technically thats true, nephew, as it is the ultimate answer to life the universe and everything.

Case closed.
Next.

Who would win a fist fight? Saddam Hussien or Kim Yong Ill ?

[z1p]

And those values get added how? By magic?

That code is pre-compiled into the Python interpreter, is it not? My point exactly, at least we can agree on that. So we can agree that the machine code for the statement a = a + b; is created by the C compiler and is part of the executable we are referring to as the Python interpreter. And it needs to accept variable input from the programmer, does it not? And these variables (the arguments) will be used in the function, which will then ouput x86 instructions, will it not? And these instructions are DYNAMICALLY GENERATED, are they not? Sadly, this is where we part company. The machine code for a = a + b is not dynamically generated. It is machine code that can be found in the python executable. As a matter of fact if you were to disassemble the the python executable and found the function float_add, you would see the assembly to add two numbers.Surprise! That's exactly what a compiler does too! (Though naturally, the first compilers, and lower level languages like C, would have been written in machine code originally - though it's quite possible, even plausible, to write a C++ compiler in C, a JVM in C++, a Python interpreter in VB, etc - but of course the resulting process is still the same.)

Because the way you say it, it makes you sound like you think every possible instruction set that one would need in order to create a functional program is HARD CODED into the Python interpreter, which is just ridiculous - there needs to be the dynamic generation of machine code dependant on the programmer's input. Otherwise you end up with stupid things like the interpreter just using a lookup table for every possible command, which of course not only leads to an incredibly inefficient compiler/interpreter, but also one that must be infinite in size to cover every possible input accepted from the programmer. But if that's what you'd rather believe, then so be it.
I mean, seriously, look at the logical possibilities:

1) The machine code is generated
a) The machine code is generated with a combination of existing knowledge of instruction sets, and the programmer's input. Therefore, an interpreter acts the same as a compiler, as far as the processes and input/output involved are concerned (and my original statement using "interpreted languages" as a catch-all for any non-native-machine-code programming language is correct)Now what you describe here can be done an is done to an extent in some Java virtual machines. But, this is different than an interpreter it is JIT compilation. And it is different why else would they have made a distinction between the normal Java bytecode interpreter and JIT.

2) The machine code is NOT generated
a) The machine code must be gathered somehow
i) The machine code is hard-coded into the interpreter/compiler, and is looked up when a source code calls for it (poor performance, compiler/interpreter's infinite size assuming unrestricted programmer input)
ii) The machine code is obtained from some external repository (poor performance, compiler/interpreter's infinite size assuming unrestricted programmer input)
iii) It's magic

b) The original source code or bytecode is the code that is sent to the CPU
i) The CPU understands the instructions. Therefore, the source/byte code is also machine code if it can be directly understoon by the machine
ii) The CPU rejects the instructions. The system fails. Either outcome 1) or 2)b) (or both) logically must therefore apply.
c) The compiler/interpreter only runs pre-defined instruction sets, ignoring programmer input. No longer compiling or interpreting anything, it becomes nothing more than an executable program
You seem to keep purposefully misquoting me. I never said that the machine code for an instruction like "a = a + b" is not generated I said it is not generated by the interpreter, it is generated by the compiler.

Now on to your points. First let me start with item "b", 'cause it is another case where you are trying to put words in my mouth.

I have never said that the bytecodes are sent to the CPU and have in fact said they don't. So, once again I say, "stop putting words in my mouth and trying to confuse the issue by spouting BS.

Next, lets visit point "c". Its hard to respond to this point, because it is partially true, but it is phrased in a way to confuse the issue being discussed here.

Any program that runs on a computer is "nothing more than an executable". What else do you think runs on a computer?

It is also true that it only runs a predefined instruction set. If an instruction wasn't predefined how in the world would the interpreter know what to do.

But, why you seem to think a predefined instruction set eliminates input to the interpreter is beyond me. After all, isn't it this predefined instruction set that is the input to the interpreter?

Lastly, let's visit item "a". Right off the bat , I can ignore "iii" due to its absurdity, but if you think it is a valid option that needs to be address, please let me know and I will do so.

Working up from there, let's visit a-ii. Again, this is nothing I've ever said and seems to be yet one more attempt by you to muddy the waters.

That seems to leave us with a-i. Now this isn't an accurate representation of what an interpreter does, but it is the description you provided that is the closest to the truth, so lets use it as a starting point.

#1 the machine is hard-coded in the interpreter
To an extent this is a true statement. All the machine instructions that will be executed during the processing of a Python program can be found in the python interpreter or one of the libraries it links with.

What you seem to imply is that there must be unique machine code to add together each unique pair of numbers. This is obviously not true. There is machine code to add to arbitrary inputs together, along with unique code that multiplies two inputs together, so on and so on. If there is a functionality available in the Python language there must be machine code in the python interpreter or one of the libraries its linked with.

#2 [the machine code] is looked up when a source code calls for it
No, when a particular instruction is encountered the code that supplies that functionality is called. ( a function call in a high level language or a Jump SubRoutine[JSR] in assembly

#3 interpreter's infinite size assuming unrestricted programmer input
I'm not sure you tossed this in,but let's look at it any way.
Since code is written to handle arbitrary inputs and a computer language contains a relatively small set of instructions, the interpreter does not need to be infinite.

Your so sure that the Python dynamically creates machine code why don't you go to the source I pointed to you and find where its doing it. It really shouldn't be hard to find if its there as there needs to be code to generate machine code for each architecture that the interpreter supports. So, go find the code to generate machine code for a SPARC processor, or maybe an Intel chip or an Itanium or a .... There must be a big chunk of code to create the different machine codes.


(BTW - Perusing the results of searching for "language BNF" can provide some insightful reading on computer language specifications and parsing. Though for most people its better than a sleeping pill for getting to sleep)

[oracle128]

Sadly, this is where we part company. The machine code for a = a + b is not dynamically generated. It is machine code that can be found in the python executable. As a matter of fact if you were to disassemble the the python executable and found the function float_add, you would see the assembly to add two numbers.Yes, I agree with this point. But, the program doesn't add "a" and "b" and store it in "a", and there is no machine code to perform such a calculation. It takes "2" and "3" (which naturally gets translated to binary), stores them in registers, adds the 2 registers, and stores it in another register. What you are saying is that the machine code operations "store '2' in register 1", "store '3' in register 2", "add register 1 and register 2 and store in register 3" are pre-compiled into the interpreter. This is grossly incorrect. That "store <this number> in register <register number>" machine code IS NOT already compiled and kept within the Python interpreter. That is just absolutely stupid. That would mean the Python interpreter is compiled full of the following code:
"Store '0' in register 0"
"Store '0' in register 1"
"Store '0' in register 2"
...
"Store '0' in register n"

"Store '1' in register 0"
"Store '1' in register 1"
"Store '1' in register 2"
...
"Store '1' in register n"

...
"Store m in register n"

"Add register 1 and 2 and store in register 0"
"Add register 1 and 3 and store in register 0"
...
"Add register 1 and n and store in register 0"

...
"Add register n and o and store in register p"

But then, who am I to argue. You assume you're right, therefore you must be. You win. Python surely must store all its code that way, like you keep saying. All I can say is, I'm glad I don't program in Python.

[z1p]

Yes, I agree with this point. But, the program doesn't add "a" and "b" and store it in "a", and there is no machine code to perform such a calculation. It takes "2" and "3" (which naturally gets translated to binary), stores them in registers, adds the 2 registers, and stores it in another register. What you are saying is that the machine code operations "store '2' in register 1", "store '3' in register 2", "add register 1 and register 2 and store in register 3" are pre-compiled into the interpreter. This is grossly incorrect. That "store <this number> in register <register number>" machine code IS NOT already compiled and kept within the Python interpreter. That is just absolutely stupid. That would mean the Python interpreter is compiled full of the following code:
"Store '0' in register 0"
"Store '0' in register 1"
"Store '0' in register 2"
...
"Store '0' in register n"

"Store '1' in register 0"
"Store '1' in register 1"
"Store '1' in register 2"
...
"Store '1' in register n"

...
"Store m in register n"

"Add register 1 and 2 and store in register 0"
"Add register 1 and 3 and store in register 0"
...
"Add register 1 and n and store in register 0"

...
"Add register n and o and store in register p"

But then, who am I to argue. You assume you're right, therefore you must be. You win. Python surely must store all its code that way, like you keep saying. All I can say is, I'm glad I don't program in Python.



I'm surprised that someone who says they have done assembly programing is not familiar with indirect addressing mode.

The machine code for "a = a + b"

Store the contents of memory @ location a into register 0
Store the contents of memory @ location b into register 1
Add register 1 to register 0
Move the contents of register 0 to memory location a

or in z80 assembly (granted this is just adding 2 16 ints, but you should get the idea)

LD HL, (a)
LD DE, (b)
ADD HL, DE
LD (a), HL

[oracle128]

Oh my, yes, how could I forget about Register Indirect? The Python interpreter is just compiled with the memory addresses hardcoded in then. And of course, since memory blocks are assigned quasi-randomly, Python also predicts the future and knows what memory addresses it will get for which variables and when. It also knows how much memory the system will have available...when the interpreter's compiled.

Now it all makes sense. Thanks for clearing that up!

[z1p]

Really, I was mistaken this whole time as I gave you too much credit in both your knowledge of computers and your maturity.

Throughout this discussion I have tried to present information (facts) and examples to support my assertions and I have been met with virtually nothing but 'that ain't so' and thats stupid. What have you presented to support you claim? Being the "Beginning and the End" of all you should be able to easily fly through the Python interpreter code and find where it generates machine code, if it was there. But, sadly its not there.

And as far as your snide comments in your last post, do you really think that programs don't have access to the addresses of their variables? And you comment about knowing future so it knows what memory to use, shows either your lack of knowledge or childishness. There is a concept of relative addressing and what did you think the "(a)" for. Its stands for the "memory location of the variable named 'a'".

Do really think that if you were to write a program in C or C++ to accept 2 number as input and add them together that it would end generating the machine code at run time based on the numbers you input?

[oracle128]

There is a concept of relative addressing and what did you think the "(a)" for. Its stands for the "memory location of the variable named 'a'".But that memory location (for any data stored in memory) is not consistent between runtimes...it's always changing, and its randomly assigned by the CPU. Python DOES NOT have direct access to the memory. Therefore, if just one variable has changed its location in memory, different from the last time the program ran, the resulting machine code will have to reference a different location in memory from which to retrieve the value of variable (a). Not only that, but whatever value (a) represents, assuming it's based on user input, is different too. If Python has to tell the CPU to store a value in memory, it has to tell it WHAT value to store. This, again, requires by basic logic that the final machine code that comes out of the interpreter is not the same every time.
Eg. if I make a program to get an integer from the user, then store it to memory - Python is already compiled with the "Store <value> in memory" instruction...but Python, at runtime, has to substitute "<value>" for "7" or whatever the user put in, and output it in machine code form. The CPU doesn't know what value the user entered, or where it's stored, only Python has that information.

And in response to Rainbow's comment:This has got to be the most off topic thread of all timesYes, I agree. It doesn't matter what interpreted languages do - the point is, they're not machine code, and neither are compiled languages (at least until they're compiled/interpreted). Therefore my original statement was indeed accurate; especially compared with the more technically correct, but much more confusing alternative in post #24, which z1p would obviously have preferred me to post - cos we're all about nitpicking at incorrect points and answering questions in a way no one would understand, here at CTH.

[bAdWaYz]

cos we're all about nitpicking at incorrect points and answering questions in a way no one would understand, here at CTH

I have seen you do your share of that Oracle. I have called your posting style pedantic in the past myself. Not that I'm picking on you or anything but sometimes its best to stop while you can. If I am wrong I'll just admit it and own up to it. I have been wrong before and I will be wrong again. There is no shame in saying that its ok to be wrong. I'd rather be happy than right any day. I don't think Z1p would have gone on this long if not for your unwillingness just to say "hey you know what I'm wrong this time". However you are very young and you have lots of time to be wrong even if you never think you are. I'm not even 100% sure you are wrong this time but I trust Z1p and know for a fact that he has forgotten more about programming than most of us here will ever know. Snurfen as well has many many years under his belt. When you put the word of those two together in agreement I am wise enough to take it as true. On the other side of this coin you are a very smart and talented person Oracle. I am in fact impressed with much that you have to say. I am very sure that with some years and time to grow you are going to be very very good at what you do. The raw talent is there for sure just don't be afraid to ask for help when you need it, admit you are wrong when and if you are, and be prepared to sit and listen when you come into contact with those more talented. There are many very sharp people here at CTH. I learn so much from people like Z1p, Snurfen, Zipulrich, Smurfy, G_Dem, degsy and others. Heck AnnMarie alone is a vault of amazing genius. So instead of trying to show off my acumen and bully my points I'm more inclined to sit and take in the wisdom of others. This post may get me in trouble with the powers that be but I had to get it off my chest. I hope this isn't taken as bashing but rather as gentle persuasion Sorry for the length of the post folks until next time...peace and love!

[Rainbow32]

until next time...peace and love!
Amen to that!

[AMH]

does this mean they aren't going to throw down and have a cage match ? :disgust:

i was just getting ready to go get some popcorn

[oracle128]

To be honest bAdWaYz, I really don't think either of us is wrong, but that we're talking about 2 different things - I'm talking about the machine code that gets sent to the CPU that results from the interpretation of a given source code - which of course logically HAS to be constructed at runtime, otherwise the same machine code output would result no matter what source code you fed it. z1p and Snurfen refer to the fact that the interpreter itself is compiled with a given, constant set of machine code instruction sets - which naturally have to exist because the interpreter/compiler itself never changes, and it somehow needs to know what commands/operations should result in what machine code being constructed.

So no, I really don't think I'm wrong, and I'd be lying if I admitted was. But if it would make everyone happier to just stop now, then so be it.

[bAdWaYz]

OK (http://www.youtube.com/watch?v=WrjwaqZfjIY)

[Snurfen]

http://img.photobucket.com/albums/v405/snurfen/ef5597c2.gif

[black mirror]

http://i129.photobucket.com/albums/p219/blackmirror2/thbird1.gif

[z1p]

In a way, it is kind of funny that this tome resulted from what I see as a few simple comments.
The Operating System was first, of course. Compilers weren't needed until programmers used interpreted languages.

Hmmm, it may just be a matter of semantics, but it seems to me that interpreted languages aren't compiled, they are interpreted at run time....

And started to go down hill quickly from here.

Java and Python are classified as "interpreted languages" (which in this usage means is interpreted by a virtual machine), but they're compiled to bytecode first. Anything which isn't compiled first into some other form, and is interpreted by a virtual machine, is basically a script (there's no real definition of "script" though). Anything which isn't interpreted or compiled is machine code.

Still losing me. Why weren't compilers needed until there were interpreted languages? A fully interpreted language (like a scripting language) doesn't need a compiler.

Now I will admit I can be stubborn and I have been called particular and a bit inflexible at work. But, those are a couple of the traits that also make me good at what I do. As the expression goes 'The devil's in the details' and I also believe in absolutes in some cases.

Now my original comment wasn't meant to come across "Hey idiot what are you saying" and I hope that it didn't. My main reason for my first post was that this is a tech forum and we should strive to provide any readers that come along with accurate information. I was hoping that my post would prompt you to clarify your statement. Regrettably, that is not what happened.

I would hate for someone that is starting in computers or software to come away with the impression that languages like Python or VBScript are compiled. Because if someone is taking a CompSci class and on a test the teacher asks "Name 3 computer languages that are compiled", they better not answer "Python, Perl, and VBScript" because they would get the question wrong.

It is also for this reason I find it hard to walk away from this thread. I know that this thread has at time turned quite technical, but I felt that that was necessary in order to clear things up for you. I strove to provide examples and facts to support my positions, but all I've seen from you is your unsupported opinion. To make it worse you present those opinions as fact and accommany them with snide remarks all in an effort to make yourself look right. Your last comment (found below here) is just more example of this and rfor the sake of not misleading anyone that comes along, I find myself once again compelled to respond to it and for that I must say 'sorry' to all you out there enduring this thread.

To be honest bAdWaYz, I really don't think either of us is wrong, but that we're talking about 2 different things - I'm talking about the machine code that gets sent to the CPU that results from the interpretation of a given source code - which of course logically HAS to be constructed at runtime, otherwise the same machine code output would result no matter what source code you fed it. z1p and Snurfen refer to the fact that the interpreter itself is compiled with a given, constant set of machine code instruction sets - which naturally have to exist because the interpreter/compiler itself never changes, and it somehow needs to know what commands/operations should result in what machine code being constructed.

So no, I really don't think I'm wrong, and I'd be lying if I admitted was. But if it would make everyone happier to just stop now, then so be it.

While I believe your original post that started this off was more inaccurate than wrong, I must say that your statement. "the machine code that gets sent to the CPU that results from the interpretation of a given source code - which of course logically HAS to be constructed at runtime, otherwise the same machine code output would result no matter what source code you fed it." is wrong. Excluding JIT compilation and self modifying code, machine code does not get generated at runtime.

The only thing I can think of doing at this point is to provide an example that that shows the process from user input to performing the requested action. I've written a simple program that accepts 2 ints and either a '+' or a '-'. Now I hope you agree this is roughly equivalent to the actions the Python interpreter would take if it was given a command to add 2 numbers or to subtract 2 numbers.

You say that the code generated by the C++ compiler is such that it will generate machine to either add or subtract depending on the inputs. However, I say the machine instructions to add and subtract are part of my executable and what happens is that the flow through the machine code varies given the inputs. This basically just as in the Python interpreter where it calls "float_add" to add 2 number when it runs across and ADD command and calls "float_subtract" to subtract 2 numbers when it get a subtraction command. The big difference between my example an the Python interpreter is I don't call functions, instead I have the instructions inline. I did it this way so we could have a manageable example.

Here is my C++ code:
#include <iostream>
#include <iomanip>
#include <string>
using namespace std;

int main()
{
//declared variables
int n1, n2, r;
char op = ' ';

//Prompt user for numbers
cout << "Enter two numbers:"; cin >> n1 >> n2; cout << endl << endl;
//Prompt user for operand
cout <<"Enter Operator:"; cout << " " "+" " " "(addition)," " " "-" " "
<<"(subtraction):" << endl;

if ( op != '+' && op != '-' && op != '*' && op != '/' ) // program reads operand
cin >> op; cout << endl << endl;

if( op == '+' ) // Program performs mathmatical request.
r = n1 + n2;
else if( op == '-')
r = n1 - n2;
cout << "answer: " << r;
return 0;
}
As you can see nothing earth shattering. ;) Now you've said that assembly and machine code is the same thing, so I'll use that to my advantage and show the assembly for this code instead of just hex.

Let's start with looking at what is happening to get the inputs into the program first. I'm not going to show all the associated assembly as it is a bit long. As a matter of fact, I'm going to look at the code for reading the operator as it is shorter because it is reading in only 1 value.
! 19 cin >> op; cout << endl << endl;

add %fp,-17,%o1
call __1cDstd2r4Ccn0ALchar_traits4Cc___6Frn0ANbasic_ist ream3CTACTB__r1_4_
mov %l3,%o0
Now I know that this looks like a bit of gibberish, but it should clear to someone familiar with assembly that not there are no hard coded values here, nor are any instructions being generated by this code.

Now let's look at the code that does the work.! 21 if( op == '+' ) // Program performs mathmatical request.

ldsb [%fp-17],%l2
cmp %l2,43
bne .L11
nop
OK, so this is where it checks to see if it was told to add together 2 numbers. Nothing much here. Its just comparing the operator read in against 43 ('+' in ASCII). If its not '+ then it is branching to the address labeled .L11. This is the important piece of the puzzle and what makes software able to do as much as it can. Instructions within an executable are not only executed sequentially, but can be (and usually are) executed in an order based on inputs to the executable.

So that means in 'op == '+' then this code gets executed
! block 7
.L10:
! 22 r = n1 + n2;
ld [%fp-8],%l0
ld [%fp-12],%l1
add %l0,%l1,%i5
! block 8
.L12:
ba .L13
nop LOOK!! There's an assembly instruction to add 2 numbers.
Now the code at .L11 is.L11:

! 23 else if( op == '-')

cmp %l2,45
bne .L15
nop

! block 10
.L14:

! 24 r = n1 - n2;

ld [%fp-8],%l0
ld [%fp-12],%l1
sub %l0,%l1,%i5

! block 11
.L13: And here we have the instructions to subtract the two values.
Also, if you look at the ADD and the SUB, you can see that they both get the value they are going to operate on from the same locations (%fp-8 and %fp12, 8 bytes off the address in the frame pointer register and 12 bytes off the address in the fp)

I think it should be obvious from this that machine is not generated on the fly and is in fact generated when the executable is built. FYI - for those really interested I have attached the full assembly listing.

I think I have passed my record for my longest single post, but I still have a couple of 'nits' to address. They are related to Therefore my original statement was indeed accurate; especially compared with the more technically correct, but much more confusing alternative in post #24, which z1p would obviously have preferred me to post - cos we're all about nitpicking at incorrect points and answering questions in a way no one would understand, here at CTH. Again, you seem to have accidentally misspoke as post #24 belongs to you, unless you are saying your post is confusing. The second is your original post is not accurate. to say 'Compilers were not needed until programmers used high-level languages' would be accurate. Or to say that 'Compilers were not needed until programmers used compiled languages' would be accurate, but redundant.

[smurfy]

I for one think it's high time this thread got moved to the programming forum and stickied (or forgotten as the case may be).

[Rainbow32]

(or forgotten as the case may be).
No problem here. I've forgotten everything in this thread including the original topic.:cool:

[black mirror]

No problem here. I've forgotten everything in this thread including the original topic.:cool:
i am still trying to understand it:D

[oracle128]

OK (http://www.youtube.com/watch?v=WrjwaqZfjIY)
Hmm, z1p looks a little unhappy there. Best he doesn't see that clip. Not to mention the ladies clothes he's wearing.

I would hate for someone that is starting in computers or software to come away with the impression that languages like Python or VBScript are compiled. Because if someone is taking a CompSci class and on a test the teacher asks "Name 3 computer languages that are compiled", they better not answer "Python, Perl, and VBScript" because they would get the question wrong.Actually,my original comments had nothing to do with compiled vs interpreted languages. "Interpreted languages" (as in, the English dictionary definition of interpret (http://www.google.com.au/search?q=define%3Ainterpret&le=en&sourceid=mozilla-search&start=0)) is a catch-all term that can, and does mean "any language other than native machine code". It was not until you turned that definition into something it isn't that this problem arose.

While I believe your original post that started this off was more inaccurate than wrong, I must say that your statement. "the machine code that gets sent to the CPU that results from the interpretation of a given source code - which of course logically HAS to be constructed at runtime, otherwise the same machine code output would result no matter what source code you fed it." is wrong. Excluding JIT compilation and self modifying code, machine code does not get generated at runtime.

The only thing I can think of doing at this point is to provide an example that that shows the process from user input to performing the requested action. I've written a simple program that accepts [...]

You say that the code generated by the C++ compiler is such that it will generate machine to either add or subtract depending on the inputs. However, I say the machine instructions to add and subtract are part of my executable and what happens is that the flow through the machine code varies given the inputs. This basically just as [...]

Here is my C++ code:
#include <iostream>
#include <iomanip>
#include <string>
using namespace std;

int main()
{
//declared variables
int n1, n2, r;
char op = ' ';

//Prompt user for numbers
cout << "Enter two numbers:"; cin >> n1 >> n2; cout << endl << endl;
//Prompt user for operand
cout <<"Enter Operator:"; cout << " " "+" " " "(addition)," " " "-" " "
<<"(subtraction):" << endl;

if ( op != '+' && op != '-' && op != '*' && op != '/' ) // program reads operand
cin >> op; cout << endl << endl;

if( op == '+' ) // Program performs mathmatical request.
r = n1 + n2;
else if( op == '-')
r = n1 - n2;
cout << "answer: " << r;
return 0;
}
As you can see nothing earth shattering. ;) Now you've said that assembly and machine code is the same thing, so I'll use that to my advantage and show the assembly for this code instead of just hex.

Let's start with looking at what is happening to get the inputs into the program first. I'm not going to show all the associated assembly as it is a bit long. As a matter of fact, I'm going to look at the code for reading the operator as it is shorter because it is reading in only 1 value.
! 19 cin >> op; cout << endl << endl;

add %fp,-17,%o1
call __1cDstd2r4Ccn0ALchar_traits4Cc___6Frn0ANbasic_ist ream3CTACTB__r1_4_
mov %l3,%o0
Now I know that this looks like a bit of gibberish, but it should clear to someone familiar with assembly that not there are no hard coded values here, nor are any instructions being generated by this code.


I think it should be obvious from this that machine is not generated on the fly and is in fact generated when the executable is built. FYI - for those really interested I have attached the full assembly listing.Yes, yes, I get it. You believe that the interpreter ALWAYS outputs this machine code, even when the need to add 2 numbers or store them in memory is not needed. God forbid, the interpreter should decide for itself which machine code operations need to be output, and generate an instruction set based on those needs. Nope, nope, if an interpreter knows how to perform a million machine code operations, it always performs them, no matter what the input source code is. How many times do I have to say it? You're right, that's how interpreters operate, the students can now pass their exams armed with that knowledge. I won't comment further, since I said I wouldn't.

I think I have passed my record for my longest single post, but I still have a couple of 'nits' to address. They are related to Again, you seem to have accidentally misspoke as post #24 belongs to you, unless you are saying your post is confusing. The second is your original post is not accurate. to say 'Compilers were not needed until programmers used high-level languages' would be accurate. Or to say that 'Compilers were not needed until programmers used compiled languages' would be accurate, but redundant.I was in fact talking about the following statements:The action is exactly the same, the only difference is when. Since the answer to the OP's question regarded only the process which took place, and not the point in time that process takes place with regards to the time between creating the source code and running it (which is negligable, in these circumstances), then an answer of either "compiled languages" or "interpreted languages" would have sufficed, since they are both the same concept. I could have said "compiled languages", but then that would have made unlearned viewers wonder if perhaps batch files or VBScript were created before operating systems. "Interpreted languages", I felt, gave more of an impression of "anything other than machine/assembly code" (a machine to assembly translator is little more than a lookup table; not a compiler, and not an OS - though one would likely embed an OS to interface it) than "compiled languages" would have.

If you would prefer, I could change my answer to "either compiled, interpreted, interfaced, translated, virtualized, or otherwise 'not directly transmitted to the processor' languages, scripts, instructions other than the native instruction set(s), commands, source code, markup, or other programmatic input that isn't a native instruction set". I chose not to confuse the people.Which is, clearly, what you would have preferred my answer to look like, even if nobody understood it but you and I.
It is also for this reason I find it hard to walk away from this thread. I know that this thread has at time turned quite technical, but I felt that that was necessary in order to clear things up for you. I strove to provide examples and facts to support my positions, but all I've seen from you is your unsupported opinion. To make it worse you present those opinions as fact and accommany them with snide remarks all in an effort to make yourself look right. Your last comment (found below here) is just more example of this and rfor the sake of not misleading anyone that comes along, I find myself once again compelled to respond to it and for that I must say 'sorry' to all you out there enduring this thread.My totally (http://www.everything2.com/index.pl?node_id=1087721) unsupported (http://blogs.msdn.com/ptorr/archive/2003/09/14/56184.aspx) view (http://www.8052.com/faq.phtml?FAQ=10).

[z1p]

... is your original post is not accurate, to say 'Compilers were not needed until programmers used high-level languages' would be accurate. Or to say that 'Compilers were not needed until programmers used compiled languages' would be accurate, but redundant.


Actually,my original comments had nothing to do with compiled vs interpreted languages. "Interpreted languages" (as in, the English dictionary definition of interpret (http://www.google.com.au/search?q=define%3Ainterpret&le=en&sourceid=mozilla-search&start=0)) is a catch-all term that can, and does mean "any language other than native machine code". It was not until you turned that definition into something it isn't that this problem arose.Thank you for providing that wonderful reference to the definitions of interpret. But, if I remember correctly the original question pertained to computer operating systems and compiled computer languages. And, you response referred to compilers and interpreted languages, I guess was just mistaken when I thought you were referring to compilers for computer languages and interpreted computer languages. (See you're not the only one that can use sarcasm to 'say' one but get a completely different meaning across.)


I was in fact talking about the following statements:Which is, clearly, what you would have preferred my answer to look like, even if nobody understood it but you and I.
I thought I made it clear what I thought would be an accurate and clear statement in my last post. But, as throughout this thread you chose to ignore that.... is your original post is not accurate, to say 'Compilers were not needed until programmers used high-level languages' would be accurate. Or to say that 'Compilers were not needed until programmers used compiled languages' would be accurate, but redundant.

My totally (http://www.everything2.com/index.pl?node_id=1087721) unsupported (http://blogs.msdn.com/ptorr/archive/2003/09/14/56184.aspx) view (http://www.8052.com/faq.phtml?FAQ=10).

Now these are interesting links to look at, but before doing that I'd like to point out what I see as the crux of this disagreement. You see to be under the misguided impression the run-time interpreters generate machine code and I say that don't. Or looking at in the context of your original statement. I saw the using the term compiler when referring to 'interpreted [computer] languages' is incorrect because compilers are software programs that generate machine from a high-level computer language and 'interpreted [computer] languages' are not converted to machine code.

I'll step down from my soap box and address your links.
#1 If you go to that one, it provides a link to right at the top to another page on the same site, (http://www.everything2.com/index.pl?node_id=66328), which says
An interpreted language is a programming language that is run by an interpreter which directly performs the actions implied by the code, rather than emitting a machine code translation.1 This is contrasted to a compiler, which reads the program and then translates it (and possibly optimizes it) and saves the result as object code or an executable before the program can be run. Oops, that seems to support my position. Sorry:D

#2 Now this is a blog from someone that says they have never taken compiler design or worked on a compiler, unlike some of the folks here. Also, No where do I see mention of runtime generation of machine code.
#3 This is just poorly written and personally I same on the person that put it out there. I assume you are putting the first paragraph out as supporting you positionAn interpreted program is one in which the program must be analyzed each time the program is run to determine what actions the processor should execute. Since the program is essentially "compiled on the fly," program execution is generally slow in comparsion to other options. Code size is often larger, too, since not only is your program held in code memory but also the "kernel" which actually interprets and executes your program. Interpreted languages are usually only useful for learning purposes and are seldom used in commercial projects. An example of an interpreted option with the 8052 is 8052-BASIC. And from this paragraph I assume your focusing on the phrase "compiled on the fly". Notice that it is quoted, theres a reason for that... Also, don't miss the reference to "kernel". Both phrases are inaccurate and are referring to the language being converted to bytecodes which are then interpreted by the interpreter.

While we're throwing links out there, how about the definition of a compiled language. (http://www.google.com.au/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=define:compiled+language&spell=1)

# A compiled language is a programming language whose implementations are typically compilers (translators which generate machine code from source code), and not interpreters (step-by-step executors of source code, where no translation takes place).
en.wikipedia.org/wiki/Compiled_language

There I'm done for now and oracle take note as this is how one reasonably supports their view, with facts and relevant references. Not with snide comments and unrelated references.

ta-ta for now :cool:

[oracle128]

interpreters (step-by-step executors of source code# run: carry out a process or program, as on a computer or a machine; "Run the dishwasher"; "run a new program on the Mac"; "the computer executed the instruction"Execute a program: as in, to generate/construct/create/output machine code based on the source code? Because the only other alternative is to generate machine code not based on the source code - the option that you go for - meaning that the source code one feeds to an interpreter is irrelevant. Do take note of the terms I'm using, and their proper meaning.

If I were to "construct" a house from building materials, do I have to make the bricks and lumber? - no, I can buy those materials pre-created - but I'm still "constructing" a house.
If I "output" power using a nuclear reactor and Uranium, does the reactor have to mine the Uranium and purify it during the process? - no, these activities are done separately, usually by different companies and at geographically different locations - but the reactor still "outputs" power.
If I "generate" machine code on an interpreter using source code input, does the interpreter have to generate each individual instruction at run time? - no, the individual instructions can be pre-compiled into the interpreter - but it's still "generating" machine code.

[z1p]

Lets look at the full excerpt from the page, which I included in my post. # A compiled language is a programming language whose implementations are typically compilers (translators which generate machine code from source code), and not interpreters (step-by-step executors of source code, where no translation takes place).
en.wikipedia.org/wiki/Compiled_languageand then look how you clipped the quote to make it seem as though it had a different meaning.interpreters (step-by-step executors of source codeNow, I wonder if there is anyone besides me that sees the reason you left out "where no translation takes place" from the quote. Could it be because including it would leave you with a quote that didn't support you position?
And as far as the rest of your post again, its BS, misleading wrong and included just as an attempt to mislead readers of the thread.

Execute a program: as in, to generate/construct/create/output machine code based on the source code? Because the only other alternative is to generate machine code not based on the source code - the option that you go for - meaning that the source code one feeds to an interpreter is irrelevant.

Can I ask where you got this "definition" of 'Execute a program'? It appears that is just one more 'fact' that you have made up as executing a program has nothing to do with machine code generation, unless of coarse you are executing a COMPILER.

And since an interpreter doesn't generate machine code at all your last statement is wrong.

I'm still waiting for proof or supporting facts of your assertion that interpreters generate machine code.

[oracle128]

Can I ask where you got this "definition" of 'Execute a program'? It appears that is just one more 'fact' that you have made up as executing a program has nothing to do with machine code generation, unless of coarse you are executing a COMPILER.Define:ExecuteTo run something on a computer, especially a command or program.(www.vvm.com/~jhunt/compupedia/comp_glos/e_f.htm)
run: carry out a process or program, as on a computer or a machine; "Run the dishwasher"; "run a new program on the Mac"; "the computer executed the instruction"(wordnet.princeton.edu/perl/webwn)
Computers. to run (a program or routine) or to carry out (an instruction in a program).(http://dictionary.reference.com/browse/execute)Though it doesn't specifically mention "machine code", one can assume it implies it, because a machine cannot understand anything else. One can therefore, by logic, also assume that, should the set of instructions not be in machine code, there is a system in place that will produce a set of machine code - preferably based on the programming/scripting language's input.
And since an interpreter doesn't generate machine code at all your last statement is wrong.That statement implies that no machine code is output from the interpreter (output being a synonym for generate, create, construct - http://thesaurus.reference.com/browse/output), which of course is impossible if the system is to actually work. Haven't we already been through this? These are really simple terms that I thought you would know - layman's terms, even. One doesn't need to know a programming language to understand them. It's basic English, and I really don't know how to word it any other way to make it any simpler. What makes it so difficult that you don't understand it? If an interpreter produces a set of machine code instructions (whether the final instructions presented to the machine are hard-coded at compile time, are selected from a repository at runtime based on an input, or are constructed from scratch at runtime is irrelevant) it's therefore, according to English dictionary definitions, generating them (unless we're using some dictionary other than a standard English one, in which case I'd like to know which one you're using, so we can perhaps remain on the same track).

I thought you would have got it when I worded it like this:If I were to "construct" a house from building materials, do I have to make the bricks and lumber? - no, I can buy those materials pre-created - but I'm still "constructing" a house.
If I "output" power using a nuclear reactor and Uranium, does the reactor have to mine the Uranium and purify it during the process? - no, these activities are done separately, usually by different companies and at geographically different locations - but the reactor still "outputs" power.
If I "generate" machine code on an interpreter using source code input, does the interpreter have to generate each individual instruction at run time? - no, the individual instructions can be pre-compiled into the interpreter - but it's still "generating" machine code.But I guess not...Perhaps I'm a little slow, but I really don't know just how you expect any programming language to work (compiled or interpreted) if the executor of that code (the OS/machine itself, a compiler, or an intermediary interpreter/translator) doesn't output machine code like you keep saying it doesn't...

[z1p]

You really should not make assumptions... because all too often they are wrong. As you so kindly showed the definition of execute doesn't mention machine code generation at all.

Easy concepts here.

The machine code is created at COMPILE time. Now when a program is executed (run), this machine code is loaded into memory, typically RAM. Also, the starting address of the machine code is loaded into the 'program counter' register (PC). The PC keeps track of the machine instruction that is to be run. When an instruction has been executed the PC is advanced.

Now in a simple program with no flow control constructs like 'ifs' and 'loops' the machine that was generated at COMPILE time will be executed from 1st instruction to last. However, with 'ifs' and 'loops' 'branch' or 'jump' instructions are generated at compile time this results in program can perform different actions depending on inputs and all this without it being self modifying.

No machine code generation in this process at all. If we go with your analogy . Let's say the machine code is 'nails and wood' and the executing a program is 'using nails and wood'. That leaves us with this statement. "When using nails and wood we are generating 'nails and wood'. Now you may want to come along and say that the sentence should read "When using nails and wood we are outputting 'nails and wood." You could argue that this statement is valid depending on the definition of output you use. But, if you were to say that output means create, this statement would be false. Just because words are synonyms do not mean that they can be interchanged in all contexts.

But I guess not...Perhaps I'm a little slow, but I really don't know just how you expect any programming language to work (compiled or interpreted) if the executor of that code (the OS/machine itself, a compiler, or an intermediary interpreter/translator) doesn't output machine code like you keep saying it doesn't...
I at the point of saying more than a little slow. Come on now, more basics here.
#1, compilers don't execute code, they generate code
#2, interpreters and OS do not generate machine code.

You still refuse to answer my assertions with proof that they are wrong. You keep dancing around the issue, misquoting sources, and referencing unrelated material. When I discredit your sources, most time using material from the same source, you just dance in a lame attempt to make it appear that you are present a plausible assertion.

[spunkie1]

So does this mean the chicken didn't come first:confused:

i think the dinosaurs came first...