unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: A vm for native code in guile
Date: Tue, 3 Jul 2012 16:24:21 +0200	[thread overview]
Message-ID: <CAGua6m0zvso2P0nZn9_5n_6B=ADApFfWkHPFntymSiieEwgsmw@mail.gmail.com> (raw)
In-Reply-To: <87obnxreq5.fsf@pobox.com>

[-- Attachment #1: Type: text/plain, Size: 4306 bytes --]

On Tue, Jul 3, 2012 at 12:16 AM, Andy Wingo <wingo@pobox.com> wrote:

> On Mon 02 Jul 2012 09:53, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> 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

[-- Attachment #2: Type: text/html, Size: 6060 bytes --]

  reply	other threads:[~2012-07-03 14:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-02  7:53 A vm for native code in guile Stefan Israelsson Tampe
2012-07-02 22:16 ` Andy Wingo
2012-07-03 14:24   ` Stefan Israelsson Tampe [this message]
2012-07-07 20:12     ` Stefan Israelsson Tampe
2012-08-01 20:59   ` Stefan Israelsson Tampe
2013-01-14  2:51     ` Nala Ginrut
     [not found]       ` <CAGua6m0x-W4kdWCSoonjn-+xY=RvSjvniN=wQH53h+MzEQPpbw@mail.gmail.com>
2013-01-14  9:10         ` Nala Ginrut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGua6m0zvso2P0nZn9_5n_6B=ADApFfWkHPFntymSiieEwgsmw@mail.gmail.com' \
    --to=stefan.itampe@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).