Well, speaking this. I have a question that, is there any convenient way to add multi-backend in Guile? We can add multi-frontend in Guile easily. But if we can do so with backend, we may add more interesting things, include assembler you mentioned, and I'm interested in porting the part of GNU Kawa, which may compile Guile code into Java bytecode at user's will.
Besides, I think there's a way to compile native code taking advantage with GCC framework. Though we should create our own AOT compiler first according to the plan this year. On Sun, May 27, 2012 at 2:34 AM, Stefan Israelsson Tampe <stefan.ita...@gmail.com> wrote: > I got an idea, > > why not design a portable assembler that have a unifying simple core and try > to model a VM on that e.g. simple things will be naitive and complex > instructions > can be dispatched via a named goto. > > The solution would fix a few registers like the bp and then have enough > instructions > to be able to dispatch and move objects in memory and implement correct > function call > semantics. > > I would use two fixed hardware - registers. > 1. bp: to track the function stack > 2. vm: to track vm local data. > > It would be cool if we could say to gcc to not clobber those registers and > compile the vm as before without > changing especially much but with some assembler to do the needed jump > correctly and also reach the register > associated data. > > > One idea was to use sassy, but it does only support x86. > > Another idea is to port the sbcl assembler to scheme. This means that we > will get > assemblers for a larger set of targets but still not enough to be portable. > > The final idea I got was to use the information in gcc or gas somehow. > > Anyway I need somthing new to chew on, so why not port the sbcl assembler at > some level. > > Regards > Stefan > > > >
