Quote:
|
However, it is interesting you have written a 64bit one. Wouldn't it make more sense to write one that is independent of the bitsize? Could your VM compile on a 32bit machine? 64bit is still not big yet and working on other architectures is important.
|
sure. i dont have a 64bit machine myself. the VM is 64bit and runs fine on my 32bit machine. I have no interest in doing a 32bit VM on 32 and 64bit on 64. Makes running VM code a hassle when it was compiled on different machines. thats the whole point of a VM... So i went with full 64bit.
I think your wrong about 64bit not being plenty big enough.
Endianness is enforced in the VM so running it on sparc vs alpha vs sgi vs x86 makes no difference. What do you need a bigger size for? What are you doing that needs a 128bit VM or that??
Quote:
|
Small's main problems are a lack of dynamic allocation (heap + intelligent garbage collection), and a terrible/buggy compiler. So far I've added new debugging features to Small and made an embeddable assembler for it, but I haven't written a new compiler yet. In the future I plan to do so, but not yet. Small has other problems, such as very messy code and beta code - so I agree a rewrite of everything is necessary (but I don't have the time yet). My additions to Small (Small++?) would be:
|
things like garbage collection etc are down to the language and not the VM. My compiler willl do dynamic allocation/garbage compaction etc. since that is not the job of the VM. Most of all things in your list are compiler enhancehments, and your right about that, the compiler is harder than the vm and assembler, but I am getting there
It wll be very interesting to see how MetaEng develops and I am going to keep an eye on it! good luck guys!
ps, you go to wpi?? cool! home of megazone, gryphon and undocumented features...