• Ant <duitoolkit yahoo.ca> Dec 27 2003
• "Walter" <walter digitalmars.com> Dec 28 2003

Did you guys follow this discussion at slashdot?

"New Intermediate Language Proposed"
http://developers.slashdot.org/developers/03/12/26/1749253.shtml?tid=126&tid=156

The posting itself is not very interesting and the guy seems a bit
confused but on the discussions there are considerations on why
a IL is necessary. Mainly on the threads
"Didn't we do this once before?" and
"What's the point?"

As I understand it the general idea is that you need a IL/byte-code
to do a "optimized optimazation" (I hope it sounds ridiculous)
of the code generated (for multiple platforms at least)
and that the optimization must be done at run time.

I'm not convinced. At least for now it doesn't work for me
(I mean java, never tried C# and, many years ago, pascal p-code
was also very slow, I guess JIT compilation is a recent idea/implmentation).
So, is that for specialized environments only?
How does dmd does it? no IL? I don't mean runtime IL but compile to an IL
before the actual system dependent machine code. is that why it's hard to create
dmd ports for new systems?

before this get too much out of topic let me ask,
are compiled languages getting out of style?
some of the posters on that discution claim that a compiled
language can never be as efficient (speed and size for instance)
as a VM with JIT.

hummm... most of you probably follow /. anyway.

I bet your comments would be very interesting.

--------- now we're getting really OT ---------

As I posted recently I once created an interpreted language
(almost 20 years ago, can't remember the details exactly,
actually I didn't even remember I had done it...).
The thing would parse the source code into something easy and very
fast to parse and then execution was done by (you guess) an interpreter.
The interpreter was much "higher level" the the JVM or the "Parrot".
(parrot at http://www.perl.com/pub/a/2001/09/18/parrot.html)
The concept of register, for instance, didn't exist.
But of course I needed a pointer to next instruction to execute.
I never intended the interperter to be close to an hardware implementation.
(Does it make sence to have registers if the thing is not to have
a hardware implementation? of course not!(?))
Execution was just getting an instruction code, parameters
and calling a correspondent routine, in the end exactly as any CPU, I guess.

So what did I do? Is that fundamentally different from a VM?
Are all interpreters just a kind of VM?

I've try to find out what are the fundamental differences between an
interpreter and a VM through google but so far can't find anything...

Ant

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2003.12.27.17.25.14.107279 yahoo.ca...
 Did you guys follow this discussion at slashdot?


I looked at it briefly.

 "New Intermediate Language Proposed"


=156
 The posting itself is not very interesting and the guy seems a bit
 confused but on the discussions there are considerations on why
 a IL is necessary. Mainly on the threads
 "Didn't we do this once before?" and
 "What's the point?"

 As I understand it the general idea is that you need a IL/byte-code
 to do a "optimized optimazation" (I hope it sounds ridiculous)
 of the code generated (for multiple platforms at least)
 and that the optimization must be done at run time.

 I'm not convinced. At least for now it doesn't work for me
 (I mean java, never tried C# and, many years ago, pascal p-code
 was also very slow, I guess JIT compilation is a recent


 So, is that for specialized environments only?
 How does dmd does it? no IL? I don't mean runtime IL but compile to an IL
 before the actual system dependent machine code. is that why it's hard to


 dmd ports for new systems?


dmd has an intermediate representation. The reason it's hard to do ports to
new systems is one must write a code generator for that system.

 before this get too much out of topic let me ask,
 are compiled languages getting out of style?
 some of the posters on that discution claim that a compiled
 language can never be as efficient (speed and size for instance)
 as a VM with JIT.


A VM with a JIT does have some advantages over static compilation. There are
some major disadvantages, however, like inability to test and verify that
the customer's JIT generated a bug-free executable. Instead of the developer
debugging the apps on the developer's machine, he has a major support
problem debugging it on every JIT his customers possibly can have. A similar
problem exists with a VM - the developer has to contend with every buggy VM
variant in the wild. For a small app this is manageable, but I suspect it is
not for a major, complex app.

 Are all interpreters just a kind of VM?


Yes.

 I've try to find out what are the fundamental differences between an
 interpreter and a VM through google but so far can't find anything...


All interpreters are a VM, but not all VMs are interpreters (a VM with a JIT
doesn't interpret the code).