On Thu, Mar 3, 2011 at 11:35 PM, Ben Kloosterman <[email protected]> wrote:
> Put the time in a VM ( which shouldn’t be much) , better static memory > management and a fast Nursery based Gen Mark/Sweep and you have an excellent > initial solution. You can use the VM for most things and also static memory > managed native code where needed and it’s the same language. > Ben: I'm concerned that we are talking past each other. *I'm* talking about putting in time to use an *existing* VM such as mono or CLR. *You* seem to be suggesting that we scratch-build a VM and do one good collector. The focus of current attention for BitC is native compilation. There are many many people working on VMs and many complex issues to address there. > This would IMHO be less resources and simpler than say a pause-less GC > and static memory management. This should IMHO be a phase 2 ( which you > have already stated anyway ) . > Perhaps so, but given that the mono VM (and others) already exists, it strikes me as a diversionary activity in the near term. A better approach is to simply emit MSIL and compile to mono. It also lets us do direct performance comparisons against other languages running in the same runtime ecosystem. The mono VM may not be good enough, but it's pretty easy to target from where we are, so I think it's worth finding out. > - Compile and dev as a VM then compile native for final. > But of course for a lot of embedded and OS code compiling to VM simply isn't an option. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
