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"
>
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?

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).