[Mono-list] PHP# - feasibility study so far - for comment

[Miguel de Icaza]

Hello Alan,

> I've just put up a short description of the current state of the 
> research on the feasibility on PHP#, developing a .net CIL bytecode 
> compiler for PHP. If anyone wants to add 'constructive comments' to it, 
> please fire away..
> 
> http://www.akbkhome.com/Projects/PHP_Sharp

This is an interesting effort, here are some bits that you might find
useful:

	* Microsoft's JavaScript compiler is also a dynamically typed
	  language.  You might want to look at the compiler output for
	  `jsc' to see which tricks they use to deal with dynamic types.

	* Microsoft VB.NET compiler also does tricks like that, for
	  example if the compiler can infer the types of variables,
	  it will use the most efficient mechanism possible.

	  For example, `int + int' can be encoded directly using CIL
	  instructions:
	
		load-integer a
		load-integer b
		add

	  but when the compiler can not decide what to
	  do, it has to call a support routine in the runtime:

		load-thing a
		load-thing b
		call Add_two_unknown_objects

	  Or even:

		load-integer a
		load-thing b
		call Add_Integer_And_Unknown
		
	* The Microsoft JSC compiler is interesting, because its
	  implemented in C#, and is available as a runtime class
	  this allows `eval' to actually compile code freshly.

* Optimizing dynamic typed languages

        It has been debated that the CIL is a language that is good for
        statically typed languages, but a poor choice for dynamic
        languages.  I think that this is a gross miss-representation.
        
        In fact every computer architecture works better with statically
        typed languages than dynamic languages (ie, the x86 is not an
        architecture for "hosting" dynamically typed languages), but
        clever tricks can be used to host any language on them. 
        
        For example the Mono JIT inlines a few calls (Math.Sin,
        Math.Cos) with direct FPU instructions.  
        
        I would be entirely possible to extend this mechanism in the
        future to handle particular calls to supporting routines in the
        runtime to inline the code directly (if we believe that they
        make sense, or that they are a performance improvement).  
        
        So say your language needs to do an indirect call, and you use a
        helper function for this:
        
        	load-args
        
        	ldobj TheObjectToCall
        	ld-int some-index.
        	call IntPtr [MyPHPRuntime]Runtime.ExecuteMethodByLookingMethodUp(object,string)
        	call-by-pointer
        
        And lets imagine that the routine above returns a pointer, and
        that it could be inlined nicely by doing some kind of static
        lookup, we could extend the JIT (or have a JIT plugin mechanism)
        that would inline the above call into, say, an indirect call
        with an offset without having to call the lookupmethod routine.
        
Miguel