> First there is no "If .Net compilers...", what you described is how .Net high level language compilers work.
IronPython clearly doesn't work this way. Proceed to tell me that IronPython doesn't compile, that Lisp doesn't compile, and that if the result isn't a dot-exe file, compilation didn't take place.
> That's makes no sense [compiling a high level language like lisp to a machine (virtual in this case) assembly language would make the language difficult to implement.]
You cannot fathom how writing the opcodes to a textfile, performing some API to operate on the textfile, and negotiating the compiled result into the current address space is more difficult than simply writing to the current address space directly?
> >There is a plain-text assembly format for .NET. Few people actually use it when making compilers because there are better APIs.
> What magic is this? .Net understands all languages through API calls?
Why are you arguing about something you clearly do not understand very well?
Interactive .NET compilers almost always use Reflection.Emit and AssemblyBuilder to construct the assembly in memory, and simply run it. They don't usually mess with the asssembly-mnemonics any more than JVM-targetting compilers do.
> You keep saying there is some magic translation from high level languge to bytecode through some existing API that understands everything.
I said nothing of the sort. You clearly do not understand this very well.
Compilers lex and parse as they like, then call GetILGenerator() for the method. They then emit the operations they want to perform. They can then call the method directly. This is clearly better than the officially prescribed method JVM-targetting compilers perform, but not significantly different, and as I still maintain: the fact that there is an assembly mnemonics and a IL assembler is practically meaningless.
> >Your PC will execute anything you put under its instruction pointer- whether it comes in a text file or not.
> You just said that the text file of assembly instructions is directly executable by your machines processor. That is just stupid. The binary of the ASCII codes that make up a text file are not the same binary used for instructions.
I said nothing of the sort. You put the following:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*in a text file (see http://www.eicar.org/download/eicar.com.txt if your browser, or you, are brain-damaged) in a text file, rename it to dot-com, and your computer will run it. It will even do something meaningful.
These character have a 1:1 relationship with their mnemonics. For example "X" is pop %eax. This is what makes direct input buffer overflows possible.
> You are having huge problems following along.
I am. You should be clearer.
What exactly is your point again? IL bytecodes are significantly better than JVM bytecodes because .NET ships with an assembler for them?
I disagree that it is significant.
> CIL contains symbols that are not instructions for the .Net runtime.
x86 assembly files contain symbols that are not instructions for the x86 cpu.
> CIL files are not executable binaries
So what? JPEG files are not executable binaries. Do you have a point in there?