From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: A vm for native code in guile Date: Tue, 3 Jul 2012 16:24:21 +0200 Message-ID: References: <87obnxreq5.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f234cbfb1444804c3edab43 X-Trace: dough.gmane.org 1341325488 5704 80.91.229.3 (3 Jul 2012 14:24:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2012 14:24:48 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jul 03 16:24:46 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sm41x-0007UI-Mf for guile-devel@m.gmane.org; Tue, 03 Jul 2012 16:24:41 +0200 Original-Received: from localhost ([::1]:59273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm41w-0004UJ-Er for guile-devel@m.gmane.org; Tue, 03 Jul 2012 10:24:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm41q-0004Ty-3b for guile-devel@gnu.org; Tue, 03 Jul 2012 10:24:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sm41h-0007ZX-I4 for guile-devel@gnu.org; Tue, 03 Jul 2012 10:24:33 -0400 Original-Received: from mail-gh0-f169.google.com ([209.85.160.169]:65203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm41h-0007Z1-9F for guile-devel@gnu.org; Tue, 03 Jul 2012 10:24:25 -0400 Original-Received: by ghrr18 with SMTP id r18so6235182ghr.0 for ; Tue, 03 Jul 2012 07:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uIwEDUnddDuoq3HynrDW6L0ZdHWTxQACJUFv4WM2rEA=; b=vVAq3tpgZBiU+wMkupajrnkqLEjJvHuWEFGy7I0QerKpRRlt8nXzxZQBMUMo3yhVk1 aPeSseCawDC8ptu05Awv1056feE75LtIoZ4ZcuLkmn0ygOSQrwGX+sJt+DjBl7ZB0rkz lLPI4hwojUBX8bB8vgH9IOetr31FirGb6y+Uf50jU/sX7vwUwZhy39OJ++GhN/1S2vxY 1NN2CfGRe5G9MfhW0PUv7exENOANiyNLsSpXzXIvDeO0XcvJaXwaUESGAwbC3fbty6tT yMZ91Mf54+3E3yAmF8+mCN8HS9BGFhLjJtmCuEE/s3BlMzI2ArmQLmldpTypX8mi8Hpi t38w== Original-Received: by 10.50.104.228 with SMTP id gh4mr8300569igb.71.1341325462029; Tue, 03 Jul 2012 07:24:22 -0700 (PDT) Original-Received: by 10.50.41.196 with HTTP; Tue, 3 Jul 2012 07:24:21 -0700 (PDT) In-Reply-To: <87obnxreq5.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14696 Archived-At: --e89a8f234cbfb1444804c3edab43 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 12:16 AM, Andy Wingo wrote: > On Mon 02 Jul 2012 09:53, Stefan Israelsson Tampe > 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. > > Where is this code? Sorry for not following the context. > https://gitorious.org/aschm > 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/ > /Stefan --e89a8f234cbfb1444804c3edab43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2012 at 12:16 AM, Andy Wi= ngo <wingo@pobox.com> wrote:
On Mon 02 Jul 2012 09:53, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wri= tes:

> Anyway I can now compile simple functions to native sequences of machi= ne code but with some
> tools around it so let me explain the setup.

Where is this code? =A0Sorry for not following the context.
I agree with you that maintenance is the challenge. =A0Have you looked at wip-rtl, Stefan? =A0It should be easier to compile. =A0However it's not=
fully baked yet, unfortunately.

The problem with r= tl 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!

=A0
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. =A0Howev= er,
with my conservative Guile co-maintainer hat on I still have hesitations as to its applicability to mainline Guile. =A0You are very good at getting<= br> Guile to work for you, but I would like to see more incremental
patches.

No problemo, The worst thing that can hap= pen 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 di= scussions about how to setup a native environment, If you look at the vm.sc= m file in the repo
you will get the impression of a proposed design, I also propose to still k= eep some of the old VM's philosophy in using named goto when we can amo= rtize the cost of doing it for the sake of a more compact compiled procedur= es. And many more things. However the assembler is a stand alone applicatio= n independent of guile and there is a connection that hook into guile but t= hat's just an incrementation away from plain guile. So you see, there i= s this although bloated chunk of 10000 row scheme code that is standalone a= nd 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 exe= cutable
2. code to set a native bytevector on the objcode
3. hooks in vm-i-syste= m.c to check for the native flag and if so executre the native code.
(th= is is a half hearted implementation)
4. Implement some support functions= on the C level to avoid writing all code in assenmbler but this is orthogo= nal 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 MI= T/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= 9;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)
=A0=
I know that we have gone back and forth over the past couple years and
this is probably frustrating to you. =A0At the same time I think that your<= br> code, commits, and communication have gotten a _lot_ better over that
time. =A0If you have a complaint, please voice it. =A0Otherwise we keep wit= h
this code review thing.

Actually I have a really f= un 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 t= ime
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 i= deas and question is not good
so I can't demand that all should gath= er 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.
=A0
What do you think about this situation?
=A0
I enjoy it currently so why change!

<= blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Peace,=A0
Andy
--
http://wingolog.org/=

/Stefan
--e89a8f234cbfb1444804c3edab43--