search for: spnz

I'm writing an ML-like language, and using LLVM as my target back end. I have one question though, and thought I'd throw it out onto the list. In my language, variables aren't mutable- once assigned, they can be shadowed, but not changed. And shadowing of variables is handled by alpha-renaming. What I mean by this that when I see: let x = 3 in ... the value of x can not be

...Also, IIRC debug metadata must be attached to stack slots. But these issues are not worth worrying about yet. Do the simple, clear, and obvious thing first, then change tack if it proves to be insufficient for your needs. Have fun! -- Ben On Mon, Feb 7, 2011 at 6:28 PM, Brian Hurt <bhurt at spnz.org> wrote: > > I'm writing an ML-like language, and using LLVM as my target back end. I > have one question though, and thought I'd throw it out onto the list. In > my language, variables aren't mutable- once assigned, they can be > shadowed, but not changed. And...

On Thu, 23 Jun 2011, Joerg Sonnenberger wrote: > On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: >> Segmented stacks are exciting to me, but only if the stacklets can be >> freed. Here's why: if segmented stacks allow for "infinite" stacks, tail >> call optimization becomes a lot less important in functional languages- >> still useful, but not

On Tue, 5 Feb 2008, Chris Lattner wrote: > On Mon, 4 Feb 2008, Brian Hurt wrote: >> Another possibility, and I'm not sure how to do this in LLVM, would be to >> sacrifice a register to hold the pointer to the unique per-thread >> structure. This would be worthwhile to me even on the register-starved >> x86-32. I suppose I could also just add a "hidden"

Sorry for the delay in responding. On Mon, 13 Jun 2011, Rafael Avila de Espindola wrote: > On 11-06-02 07:47 PM, Peter Lawrence wrote: >> Guys, >> regarding alloca. >> >> not only are exceptions a problem here, but just plain old "longjmp". > > Yes, > On IRC Sanjoy pointed out that it should be possible to handle this by > changing longjmp. I am

Hello- I'm looking to implement a new programming language using LLVM as a back-end. Generally it's looking very good, I only have one question. The language is going to be an ML-style language, similiar to Haskell or Ocaml, except explicitly multithreaded and (like Haskell but unlike Ocaml) purely functional. But this means that speed of allocation is essential- purely functional