Uri Guttman wrote: > that is good. i wasn't disagreeing with your alternative architecture. > i was just making sure that the priority was execution over compilation > speed.
I use a snazzy quintuple-pass object-oriented assembler written in equal parts spit and string (with a little RecDescent thrown in for good measure). A real speed demon it is... ;) The real motivation of my work is to see if a storage-to-storage machine ends up using cache better and with less compiler effort than a register machine. When I read about CRISP, the first thing that came to mind was the "top-of-stack-register-file" could be simulated exactly with high-speed cache in a software VM. Dropping the stack-machine instructions in favor of Parrot's 3 operand ones made it sound even better. > ... then be mmap'ed in and run with hopefully impressive speed. I'm impressed with the possibilities of the pbc->C translator. The core modules on my system probably won't be mmap'ed byte code -- they'll be mmap'ed executable. Reducing memory foot-print this way might take some of the pressure off the need to share byte code. Lots of really nice optimizations require frobbing the byte code, which definitely hurts sharing. - Ken
