>:>: A proper VM will execute only slightly slower than a nativce machine. I
>:>: see no reason to think that hardware will buy much, and the cost of
>:>: going to new technology for speed is high.
>:>Not necessarily true.
>:>Current RISC chips  are optimized to run C and C-like
>:>languages very fast. Of course, that's because C is probably
>: Processors are NOT C based, C is really a close relative to assembler,
>: which has a direct relation to machine language. Garbage collection,
>: functional evaluation, et al, are functions of a specific language, so
>: including them in the processor, has to be a very careful decision,
>: processor real-estate is very tight, so if that space can be used for
>: non-language specific functionality then that is a better idea.
>I don't believe I said anything about processors being ``C
>based''. Please reread what I said. Clearly current RISC
>processors are *optimized to run C-like languages very
>fast*. If you don't believe me, go back and read the
>original thesis on RISC chips [I'll dig up the reference if
>you want it].
Semantics, you really ended up saying the same thing, and I still don't
agree, languages are often designed to make use of certain processor
design aspects, for example C makes heavy use of the stack, most
processors have some form of stack based process....
Quote:>Nor did I say anything about including garbage collection,
>functional evaluation et al in the chip directly. Please
>reread what I said. I merely stated that to support GC
>(etc.) and support it well, you would need to quantify the
>kind of operations that are commonly generated by the
>compiler and optimize for these common cases. If necessary,
>iterate the process by changing the compiler to suit the
>processor and so on. Make the common case fast, and the
>fast case common, as they say ...
Okay, but you might as well have said it, because that is the intent
that came across, designing aspects into the processor that make
specific tasks easier. Unfortunately the garbage collector or function
evaluator for one language, can be very different from the same component
of another language. For example the GC for Java and the GC for BASIC do
the same function, but do it quite differently.
Quote:>As a made up example, it might be that GC is performed 20%
>of the time and that triple pointer indirections account for
>50% of the time taken to do GC. You could therefore (by
>Amdahl's law) get a ~11% speed up (maximum) by introducing a
>new instruction which does triple pointer indirections
>really fast. All things being equal. In reality, all things
>are not equal, and adding such an instruction would add
>considerable complexity to the chip and lengthen the clock
>cycle. But you get the idea ...
Okay do we optimize for the GC in Java, and watch performance in BASIC go
to hades, or do we optimize for Basic and watch Java performance suffer,
or do we optimize for both, and watch the whole system go down the
Quote:>Nothing here about putting full generational GC engines into
>the chip ...
Okay, but you implied it originally....
Quote:>Don't take my word for it, however. It turns out that the
>next generation of Sun's Java chips will take exactly the
>approach I have outlined above. The first generation, you
>will recall, attempted to implement a subset of the JVM
>directly, which was a daft idea.
Yeah, but those are designed to run a specific language, Java, running
software written in other languages, isn't a concern here....
Your Computer is our Business
web : www.interlog.com/~pschmidt