similar to: [LLVMdev] Directly emit LLVM IR?

On Feb 22, 2008, at 11:11, Eric Jonas wrote: > Hello! I'm interested in using LLVM as a target for a compiler I've > written in common lisp (SBCL). While I looked at perhaps wrapping > the LLVM C++ interface, wrapping C++ in, well, anything not C++ is a > pain. Someone on IRC mentioned that they didn't think I'd miss out > on any functionality by directly

Hello! I'm interested in using LLVM as a target for a compiler I've written in common lisp (SBCL). While I looked at perhaps wrapping the LLVM C++ interface, wrapping C++ in, well, anything not C++ is a pain. Someone on IRC mentioned that they didn't think I'd miss out on any functionality by directly emitting IR, but suggested I query the list. Do I miss out on any optimizations

> • Emit LLVM assembly from your compiler's native language. > for: very straightforward to get started > against: the .ll parser is slower than the bitcode reader when > interfacing to the middle end > against: you'll have to re-engineer the LLVM IR object model > and asm writer in your language > against: it may

Hi, > • Emit LLVM assembly from your compiler's native language. > for: very straightforward to get started > against: the .ll parser is slower than the bitcode reader when > interfacing to the middle end > against: you'll have to re-engineer the LLVM IR object model and asm > writer in your language > against: it may be harder to track changes to the IR One more

Yes, indeed! The SBCL lisp compiler (not llvm based) used to emit functions which would return either via ret to the usual instruction after the call, or else load the return-address from the stack, then jump 2 bytes later (which would skip over either a nop or a short jmp at original target location). Which one it used depended upon whether the function was doing a multi-valued return (in which

thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore

In working on an LLVM backend for SBCL (a lisp compiler), there are certain sequences of code that must be atomic with regards to async signals. So, for example, on x86, a single SUB on a memory location should be used, not a load/sub/store sequence. LLVM's IR doesn't currently have any way to express this kind of constraint (...and really, that's essentially impossible since

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are

Responding to the original email... On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. Can you define exactly what 'atomic with regards to async signals' this entails? Your descriptions led me to think

On Jan 3, 2010, at 10:10 PM, James Y Knight wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. So, for example, on x86, a single SUB on a memory location > should be used, not a load/sub/store sequence. LLVM's IR doesn't > currently have any way to express this

Well, nothing has changed in the issues that I brought up earlier, except that I can confirm core dumps in non-threaded lisps as well (CLISP), using svn version 37840 (this morning, Seattle time) for R-2-3-patches. I've not tried Thomas' suggested fixes, as I'm hesistant to go down the road of fixing R in such a way that would require constant patching. (so for those counting,

Scott Michel <scottm <at> rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. >

I''m looking to write a javascript heavy clientside program with a something serverside backend that connects to the free maxima math program. I have extensive knowledge of ruby on rails, so I would prefer to call Maxima with ruby, but I don''t know if this is even possible. Its fairly easy to call Maxima (with a lisp implementation) using ANSI C, it is a little less easy to

With regard to Bartlett-style collectors, they are also used in CMUCL/SBCL, OpenDylan, and various products based on Ravenbrook's Memory Pool System. Also, while Mono doesn't use a Bartlett-style collector, it does support pinning objects referenced from ambiguous stack roots, in an otherwise copying collector. While ITA has expressed concerns with SBCL's GC, they seem to involve the

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what

Hi, This is just to report about the "alignment check: 0000 [#1] SMP" kernel messages in one of my build system (domU) running Scientific Linux 6.1. I am compiling/rpm package for sbcl (http://sbcl.sourceforge.net/) in my build system (domU) and hit the following kernel messages although the domU in question still running and compilation still in progress. I have done some searching

Hi Our front end is written in a CLR language, and we're currently interacting with the middle/back-end by writing out .ll files. This was convenient to get started with, but they're getting to a "huge and unwieldy" stage now. I was wondering if anyone's attempted writing proxy/wrapper C++/CLI classes so that the IR API can be used directly from managed languages. Any

On Aug 12, 2008, at 19:38, Scott Graham wrote: > Our front end is written in a CLR language, and we're currently > interacting with the middle/back-end by writing out .ll files. This > was convenient to get started with, but they're getting to a "huge > and unwieldy" stage now. Yup. This is in the FAQ now: http://llvm.org/docs/FAQ.html#langirgen > I was

> From: Wensui Liu <liuwensui at gmail.com> > Just curious how xlispstat is used in the industry and what's it strengthen > compared with other computing languages such as R or matlab? Almost not at all, though there are a few holdouts. On a related note, I've been doing some interesting things with a branch of LispStat for CommonLisp. It'll be more interesting when

On 7/23/19 8:42 PM, John McCall via llvm-dev wrote: > > On 21 Jul 2019, at 12:29, James Y Knight via llvm-dev wrote: > > Yes, indeed! > > The SBCL lisp compiler (not llvm based) used to emit functions > which would > return either via ret to the usual instruction after the call, or > else load > the return-address from the stack, then jump 2