[Sbcl-devel] SBCL on LLVM
James Y Knight
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
Matthew Swank
>
> 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
Christophe Rhodes
> 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
James Y Knight
> 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
Andreas Fuchs
> 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:asf@)boinkor.net, antifuchs
Nathan Froyd
> 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
Andreas Fuchs
> 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:asf@)boinkor.net, antifuchs
------------------------------------------------------------------------------
James Y Knight
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
Neil T. Dantam
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
dher...@tentpost.com
approach. Another is to have a well-known wiki page where people can link
to their repos and describe the heads of interest.
- Daniel
Nikodemus Siivola
* 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
Daniel Herring
> * 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