Re: Mono and GNOME. The long reply.

[Miguel de Icaza <miguel ximian com>]

> > Java byte codes are powerful enough that you can run anything on that. 
> > But a series of languages will be very hard to support efficiently (C,
> > C++, Fortran in one end and Haskell and Lisp on the other one).
> 
> You can support C efficiently in Java byte code.  Fortran even more so,
> not that anyone in the fortran world would care[1]. Lisp is already available
> efficiently on java, as is python and even cobol and APL.

I would like to see how the libc qsort can be compiled to java byte
codes (function pointers), or how typecasts will work there (efficiently
as you said).  Inquiring minds want to see ;-)

Specifically, I want to see the efficient translation of:

	char buffer [1024];
	...
	int *p = &buffer;
	...
	if (*p == ...)
		...

The Fortran guys at the PDC said they could not compile Fortran-77 or
Fortran-9something to Java.  I do forget the details, but I remember
vaguely something about `common blocks'.  

The Lisp and Haskell people said that the `tail call' was missing and
they could not do without it.  Maybe they are idiots, but thats what the
compiler vendors said ;-)

> Which adds instructions that allow compilers to be written more easily at
> a horrible cost in run time execution efficiency.

What is this horrible cost of runtime execution efficiency you are
talking about?    

What I am specifically talking about is:

	* call-by-pointer.
	* load-address-of.
	* tail-call (translates into sort of a jmp)
	* dereference pointer.

None of those are particularly hard to execute.  Indeed, in Mono they
barely take any space in JIT engine.  

Another feature in the CLI is the fact that local variable slots are
never reused for different data types.  This means that a JIT does not
need to perform data flow analysis to find the liveness of the local
variable slots before it can JIT.  

Miguel.