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. I admit I'm not the clearest person in email .No I was saying use Mono or the CLR , even though its easy , to me that provides more incentive to deliver it early rather than saying we get around to it because its easy maybe when you self host and consider IR .. There may be some nastiest and its better to find it out early and it sets a nice bench mark for static compilation to beat. 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. Well you can debug and build on a PC ( for an OS with a virtual HAL) and deploy to a device , saves a lot of time . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
