Re: assembler in scheme
On Sat, May 26, 2012 at 10:58 PM, Nala Ginrut wrote: > Well, speaking this. I have a question that, is there any convenient > way to add multi-backend in Guile? It depends on what you mean by that. You can add as many low-level languages as you like, including a GCC interface, machine code, and JVM bytecode. The compiler framework doesn't know the difference between frontends and backends (I think) - it just compiles from one language to another, using the compilers it knows about. When you're actually running Guile, only one of those languages can be executed, and it's the one corresponding to the actual virtual machine running Guile. But you could use the framework to statically compile JVM bytecode just fine, I think. It would be very cool to be able to run Guile on the JVM. I think it would really show the advantages of the compilation framework, because the Guile VM and JVM implementations would use the same intermediate language, with the same optimizations. However, I think that would be a lot of work. Noah
Re: assembler in scheme
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 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 > > > >
assembler in scheme
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
