MooseFET said:
Yes .net is as bad in 64bit as it is in 32bit. Since it isn't really
CPU instructions it doesn't qualify. It is a very slow way to get any
complex task done.
well, .NET can be made faster by employing a more involved translator.
for example, an essentially braindeded direct-JIT, would be fairly slow.
if it reworks it, say, into SSA form and handles the stack and variables
partly through register allocation, then, very likely, you will get faster
results.
can't say exactly what the various .NET VMs do, as I haven't looked too much
into this.
for example, my compiler uses a language I call RIL (or RPNIL), which is
essentially a vaguely postscript like language. now, it is a more or less
stack machine model. so, I compile C to this language, and this language to
machine code.
and, the spiffy trick:
the RIL stack, increasingly, has less and less to do with the true (x86)
stack. part of the stack is literals (only in certain situations are they
actually stored on the machine stack), part is registers (look like stack,
but really they are registers), and soon, part may be in variables (needed,
for technical reasons, to get my x86-64 target finished).
so, it looks like a stack machine, but a lot goes on that is not seen...
I chose a stack machine model because it is easy to target (and was
fammiliar), but this does not mean strictly that the internals, or output,
have to work this way.
and, odd as it may sound, only a very small portion of the RIL operations
actually generate CPU instructions, and typically then, it is for something
that happened earlier in the codestream...
There was an effort a while back to make a CPU that spoke Java
bytecode directly. I don't think they could get good speeds out of
it.
yes, a few possible reasons come up...
A far better way to go would be to standarize on the instruction set
of a real CPU. Ideally it should be a small and simple one so that
anyone who wanted to could add a special section of control store to
their processor to allow it to be run directly.
I don't understand exactly how this differs that much from current
approaches.
another CPU is, another CPU.
x86 and, soon x86-64, are the most common (at least for normal computers).
This would require that a standard way of doing the GUI also be
created. It needs to be a very simple GUI so that even simple
machines could do it.
yes.
for PCs, a standardized GUI would work.
for non-PCs, it is probably a lot harder (given the wide variety of physical
interfaces).
now, a very simple and general UI, makes a usability problem on a normal
computer, as often these kind of UIs end up treating the keyboard like a
paper weight (for many kinds of apps, the keyboard serves its purpose well).
now, in my case, I typically do my GUIs custom via OpenGL...
this gives a good deal of portability at least (stuff still works on linux,
to what extent it works...).
yeah...
