On Tue, Jul 3, 2012 at 12:16 AM, Andy Wingo
<address@hidden> wrote:
On Mon 02 Jul 2012 09:53, Stefan Israelsson Tampe <
address@hidden> writes:
> Anyway I can now compile simple functions to native sequences of machine code but with some
> tools around it so let me explain the setup.
I agree with you that maintenance is the challenge. Have you looked at
wip-rtl, Stefan? It should be easier to compile. However it's not
fully baked yet, unfortunately.
The problem with rtl is that it is not fully baked and that I expect that the hard part is to get
the framework correct so that you do not shoot yourself in the foot all the time with the
assembler - it's really hard to use!
To speak honestly I am very impressed with your work.
Thx, dito for many other guile hackers, including you, I really like this community!
I leave that as its own paragraph because that's what I think. However,
with my conservative Guile co-maintainer hat on I still have hesitations
as to its applicability to mainline Guile. You are very good at getting
Guile to work for you, but I would like to see more incremental
patches.
No problemo, The worst thing that can happen is that I get a well tested assembler framework running that people can download and use at their will which is not too bad. I do hope to start discussions about how to setup a native environment, If you look at the vm.scm file in the repo
you will get the impression of a proposed design, I also propose to still keep some of the old VM's philosophy in using named goto when we can amortize the cost of doing it for the sake of a more compact compiled procedures. And many more things. However the assembler is a stand alone application independent of guile and there is a connection that hook into guile but that's just an incrementation away from plain guile. So you see, there is this although bloated chunk of 10000 row scheme code that is standalone and there is a patch of <100 rows that makes it possible to execute
a procedure as native. Not sure how to make the 10000, row beasty creature incremental but surely
the other part should be fine to increment in. It's basically
1. An extra flag for marking a procedure native executable
2. code to set a native bytevector on the objcode
3. hooks in vm-i-system.c to check for the native flag and if so executre the native code.
(this is a half hearted implementation)
4. Implement some support functions on the C level to avoid writing all code in assenmbler but this is orthogonal code compared to plan guile. I expect this to grow
look in the guile directory to see the file'a I've been touched in the guile-repo
Also the assembler needs to go at some point because it's not GNU owned code. And Ludo suggested that we try to port over MIT/GNU Scheme over to guile, which is not a bad idea
Also I do know enough, (after porting SBCL's assembler) to implement a Assembler from scratch
but of cause that will take a couple of month's. I'll keep the aschm assembler for now though because I really want to play with the native execution issues. (sassy is also a possibility
but that is only for x86 assembler and I wanted x86-64 to play with)
I know that we have gone back and forth over the past couple years and
this is probably frustrating to you. At the same time I think that your
code, commits, and communication have gotten a _lot_ better over that
time. If you have a complaint, please voice it. Otherwise we keep with
this code review thing.
Actually I have a really fun time hacking, so that I really do not care much about
thumbs down or nit pickling, I can cope with that. Also I'm realistic about how much time
people can spare and I do care that you continue with your own work for the benefit of the
project. Also my own time commenting on other peoples ideas and question is not good
so I can't demand that all should gather around and cheer the ideas I try to bring. But I do
try to read in some of what you do and sometimes takes a detour in the wake of that information.
What do you think about this situation?
I enjoy it currently so why change!
Peace,
Andy
--
http://wingolog.org/