[Sbcl-devel] SBCL on LLVM

Showing 1-12 of 12 messages
[Sbcl-devel] SBCL on LLVM James Y Knight 12/20/09 8:43 PM
At the SBCL10 conference, I worked on an LLVM backend for SBCL, as  
well as the supporting work of CL bindings to the LLVM C API. I've now  
cleaned up CL-LLVM a slight amount, and added some READMEs to both it  
and SBCL/LLVM.

CL-LLVM (bindings to the LLVM C API):
http://repo.or.cz/w/cl-llvm.git

SBCL branch with LLVM support:
http://repo.or.cz/w/sbcl/llvm.git

This README summarizes the current status:
http://repo.or.cz/w/sbcl/llvm.git/blob/HEAD:/README.LLVM

But, in short, you can do this:
  (llvm-compile '(lambda (x) (let ((y (* x 3))) (+ x y))))
  (run-fun * 7)
and have it return 28. Woo!

...and that's just about as complex a function as is currently  
supported. Note also that it's doing a full-call of the plus and times  
functions: there's currently no handling of known functions.

Also, the #'+ and #'* functions aren't stored in a load-time-constant  
vector as they should be, instead (symbol-function (intern "+")) is  
called every time. I'll fix that soon.

I've developed it on Linux/X86-64. If it works on anything else I'd be  
rather surprised: there's some hardcoded 64s and 8s in there right now.

Anyways, at least it's something. :)

James

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] SBCL on LLVM Matthew Swank 12/21/09 11:41 AM
James Y Knight <foom <at> fuhm.net> writes:

>
> At the SBCL10 conference, I worked on an LLVM backend for SBCL, as  
> well as the supporting work of CL bindings to the LLVM C API. I've now  
> cleaned up CL-LLVM a slight amount, and added some READMEs to both it  
> and SBCL/LLVM.
>

I don't know too much about LLVM, but some preliminary reading seems to indicate
LLVM should be able to abstract multi-threading support across host platforms.
Does that seems reasonable to the people here with more experience using it?

Matt


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) Christophe Rhodes 12/21/09 1:02 PM
James Y Knight <fo...@fuhm.net> writes:

> At the SBCL10 conference, I worked on an LLVM backend for SBCL, as  
> well as the supporting work of CL bindings to the LLVM C API. I've now  
> cleaned up CL-LLVM a slight amount, and added some READMEs to both it  
> and SBCL/LLVM.

One thing that was discussed at SBCL10 was the (lack of) ease of
discovering the interesting stuff that is out there, either developing
slowly or finished but unmerged for whatever reason.  In the olden days,
at least committers' branches would be discoverable, because they would
be right there in the CVS; however, these days, it's just so much easier
to develop from the DVCS of choice -- but the consequence of that is
that much of it is invisible.

One solution to that is to collect links to people's git repositories
and publish them somewhere (say, on the website, with all the usual
attendant problems).  At SBCL10 there was (I think it's fair to say) a
certain amount of consensus that we should do this, but also switch to
using git as the VCS for the canonical sbcl repository, moving away from
CVS.  This would have the side-effect that committers could once again
make their branches discoverable, by virtue of having branches in the
main repository.

Firstly, is there anyone out there that this change would inconvenience,
or even make nervous?  Secondly, is there someone out there with actual
experience of working in such a project who knows what works (or at
least one thing that works)?  I think having some precise documentation
of efficient ways of working in this kind of project should be a
prerequisite; the stuff in "git help workflows" is a little bit too
high-level and general -- not prescriptive enough for the git newcomer.

Cheers,

Christophe

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) James Y Knight 12/21/09 1:46 PM
On Dec 21, 2009, at 4:02 PM, Christophe Rhodes wrote:
> James Y Knight <fo...@fuhm.net> writes:
>
>> At the SBCL10 conference, I worked on an LLVM backend for SBCL, as
>> well as the supporting work of CL bindings to the LLVM C API. I've  
>> now
>> cleaned up CL-LLVM a slight amount, and added some READMEs to both it
>> and SBCL/LLVM.
>
> One thing that was discussed at SBCL10 was the (lack of) ease of
> discovering the interesting stuff that is out there, either developing
> slowly or finished but unmerged for whatever reason.  In the olden  
> days,
> at least committers' branches would be discoverable, because they  
> would
> be right there in the CVS; however, these days, it's just so much  
> easier
> to develop from the DVCS of choice -- but the consequence of that is
> that much of it is invisible.


This page:
http://repo.or.cz/w/sbcl.git
has a list of forks it knows about at the bottom.

Unfortunately, that is only telling about repositories; it doesn't  
tell you about branches (...I mean "heads"), or what the branches  
might be about. You have to drill down into each fork and look at the  
list of heads at the bottom for that. And even so, they don't have  
descriptions. So it's kinda less useful than one might hope.

I kinda like what GCC has here, although note it's manually maintained:
http://gcc.gnu.org/svn.html

James

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) Andreas Fuchs 12/21/09 3:19 PM
On Mon, Dec 21, 2009 at 22:02, Christophe Rhodes <cs...@cantab.net> wrote:
> Firstly, is there anyone out there that this change would inconvenience,
> or even make nervous?  Secondly, is there someone out there with actual
> experience of working in such a project who knows what works (or at
> least one thing that works)?  I think having some precise documentation
> of efficient ways of working in this kind of project should be a
> prerequisite; the stuff in "git help workflows" is a little bit too
> high-level and general -- not prescriptive enough for the git newcomer.

First, I'm excited that this change is getting made (and not nervous
at all). If there's anything I can do to help with the transition,
I'll be happy to do it.

Second, the task of gathering the various topical branches is already
done very nicely by github: Several software projects rely on it to
allow easy access to the various branches, and to give a neat of what
was merged when. http://github.com/rentzsch/clicktoflash/network is a
nice example of how the complex relationships look.

Possible negative effects: Contributors who want to be listed there
have to have a free account there (and push their repos there). Main
repo would have to be kept on github.

Positive: No effort required on the part of SBCL maintainers for
keeping track of topic branches.

Cheers,
--
Andreas Fuchs, (http://|im:asf@|mailto:a...@)boinkor.net, antifuchs

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) Nathan Froyd 12/21/09 6:46 PM
On Mon, Dec 21, 2009 at 6:19 PM, Andreas Fuchs <a...@boinkor.net> wrote:
> Second, the task of gathering the various topical branches is already
> done very nicely by github: Several software projects rely on it to
> allow easy access to the various branches, and to give a neat of what
> was merged when. http://github.com/rentzsch/clicktoflash/network is a
> nice example of how the complex relationships look.

This is quite useful; it is worth noting that github free accounts
only have 300MB of free space.  (More can be acquired, but you have to
pay for it.)  My sbcl.git (with a couple of personal branches) is
~240MB, which is, IMHO, a little too close to the limit for comfort.
OTOH, it's possible that forks of projects use hard links, in which
case somebody forking sbcl.git on github would pay a negligible amount
of space for their twiddling around.

-Nathan

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) Andreas Fuchs 12/22/09 12:18 AM
On Tue, Dec 22, 2009 at 03:46, Nathan Froyd <fro...@gmail.com> wrote:
> This is quite useful; it is worth noting that github free accounts
> only have 300MB of free space.  (More can be acquired, but you have to
> pay for it.)  My sbcl.git (with a couple of personal branches) is
> ~240MB, which is, IMHO, a little too close to the limit for comfort.

They count only the size of the .git directory, which is currently
21MB for my repacked mirror of the SBCL repo (-:

> OTOH, it's possible that forks of projects use hard links, in which
> case somebody forking sbcl.git on github would pay a negligible amount
> of space for their twiddling around.

You could try "git repack -Ad" and see what space you can save with that (-:

Cheers,
--
Andreas Fuchs, (http://|im:asf@|mailto:a...@)boinkor.net, antifuchs

------------------------------------------------------------------------------


This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] SBCL on LLVM James Y Knight 12/22/09 8:00 AM

On Dec 21, 2009, at 2:41 PM, Matthew Swank wrote:

> James Y Knight <foom <at> fuhm.net> writes:
>
>>
>> At the SBCL10 conference, I worked on an LLVM backend for SBCL, as
>> well as the supporting work of CL bindings to the LLVM C API. I've  
>> now
>> cleaned up CL-LLVM a slight amount, and added some READMEs to both it
>> and SBCL/LLVM.
>>
>
> I don't know too much about LLVM, but some preliminary reading seems  
> to indicate
> LLVM should be able to abstract multi-threading support across host  
> platforms.
> Does that seems reasonable to the people here with more experience  
> using it?

I don't think it really has anything that would make it any easier  
than it is currently. As far as I know, the hard part is integrating  
GC and threading, which I don't think LLVM helps at all. But I haven't  
looked into it really.

James

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] SBCL on LLVM Neil T. Dantam 12/22/09 12:09 PM

James Y Knight wrote:
> On Dec 21, 2009, at 2:41 PM, Matthew Swank wrote:
>
>> James Y Knight <foom <at> fuhm.net> writes:
>>
>>> At the SBCL10 conference, I worked on an LLVM backend for SBCL,
>>> as well as the supporting work of CL bindings to the LLVM C API.
>>> I've  now cleaned up CL-LLVM a slight amount, and added some
>>> READMEs to both it and SBCL/LLVM.
>>>
>> I don't know too much about LLVM, but some preliminary reading
>> seems  to indicate LLVM should be able to abstract
>> multi-threading support across host  platforms.  Does that seems
>> reasonable to the people here with more experience  using it?
>
> I don't think it really has anything that would make it any easier
> than it is currently. As far as I know, the hard part is
> integrating  GC and threading, which I don't think LLVM helps at
> all. But I haven't  looked into it really.

LLVM does have hooks to portably integrate precise GC (for barriers,
scanning, I think).  Not sure about threading.

--
Neil

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) dher...@tentpost.com 12/22/09 8:13 PM
Centralizing everything on github or repo.or.cz or wherever is one
approach.  Another is to have a well-known wiki page where people can link
to their repos and describe the heads of interest.

- Daniel


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes (was Re: SBCL on LLVM) Nikodemus Siivola 12/23/09 2:05 AM
My requirements for specific git hosting for mainline SBCL:

 * Automated emails to sbcl-commits. (I don't really care if this is
   done with a commit-hook, or if someone runs a cronjob.)

 * Single shared "official" repository that people with commit bit
   can push to, where the master is set as fast-forward-only.

Tracking other people's topic branches is important too, though, but
more of a social issue I suspect.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] discoverable branches and DVCSes Daniel Herring 1/16/10 9:11 PM
On Wed, 23 Dec 2009, Nikodemus Siivola wrote:

> * Automated emails to sbcl-commits. (I don't really care if this is
>   done with a commit-hook, or if someone runs a cronjob.)

FYI, ABLE's git repository on common-lisp.net uses a commit hook to send
emails to able-cvs.  It took a couple tries to get the subject line
looking good, but it was not difficult.

- Daniel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev


_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel