similar to: [LLVMdev] Iterator protocols

On May 12, 2008, at 6:49 PM, Talin wrote: > So the question is, what's the trade-off. In most languages that > support > exceptions, you tend to think of exceptions as expensive operations > that > should only be thrown if something truly "exceptional" happens. OTOH, > the Java case is also made worse by the fact that a large part of the > time you'll be

On May 13, 2008, at 18:28, Dan Gohman wrote: > On May 12, 2008, at 6:49 PM, Talin wrote: > >> So the question is, what's the trade-off. In most languages that >> support exceptions, you tend to think of exceptions as expensive >> operations that should only be thrown if something truly >> "exceptional" happens. OTOH, the Java case is also made

On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > On May 13, 2008, at 18:28, Dan Gohman wrote: > >> On May 12, 2008, at 6:49 PM, Talin wrote: >> >>> So the question is, what's the trade-off. In most languages that >>> support exceptions, you tend to think of exceptions as expensive >>> operations that should only be thrown if something truly

It was a little over two years ago that I saw Chris give a tech talk on LLVM at Google, and that was when I knew that there was a way that I could actually build the programming language that I'd been thinking about for so long. Well, the compiler is still not done, even though I've been plugging steadily away at it in my free time. However, a lot of progress has been made recently,

Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner: > On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > > > On May 13, 2008, at 18:28, Dan Gohman wrote: > > > > I wonder if it would be worthwhile to have a flag on loads to mark > > them as immutable. A flag from the source language stating "this load > > never aliases any subsequent

On May 16, 2008, at 7:50 AM, Joachim Durchholz wrote: > > Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner: >> On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: >> >>> On May 13, 2008, at 18:28, Dan Gohman wrote: >>> >>> I wonder if it would be worthwhile to have a flag on loads to mark >>> them as immutable. A flag from the

A question about the layout of structs: I decided to make my vtables out of structs rather than arrays. In other words, instead of being a table of opaque pointers, I decided to individually declare each entry with the correct type for that method. I figure that the various optimizers could do a better job if I preserve the type info. OK, so we come to the issue of inheritance: Suppose I have

2009/9/15 Talin <talin at acm.org>: > For example, here's what the "Iterator" interface looks like: > >   interface Iterator[%T] { >     def next -> T or void; >   } So this would be something like: template <class T> virtual class Iterator { T next(); // or void? }; So the power of having two types of return parameters is that you save function

Hi Kevin, To elaborate on Philip's point, depending on the state Pyston's runtime already is in, you may have the choice of using a hybrid of a "pending exception" word in your runtime thread structure, and an implicit alternate ("exceptional") return address for calls into functions that may throw. This lets you elide the check on the pending exception word after

I'm working on implementing a simple functional language in LLVM. It's statically typed, but I'd like to a have some simple multimethods involved. Does LLVM have some intrinsics for handling something like C++ vtables? Or do I need to implement my own way of handling single-dispatch functions? Thanks, Timothy -- “One of the main causes of the fall of the Roman Empire was

On 2011-02-14 20:39, Talin wrote: > > > On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin <rengolin at systemcall.org > <mailto:rengolin at systemcall.org>> wrote: > > I think this deserves a blog post... > > I'd like to wait until I get some feedback - I don't know yet if anyone > is having trouble building or running the thing... Hi Talin,

On Tue, May 19, 2009 at 9:45 AM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Talin wrote: >> I see. OK, I will try that. >> >> I was hoping to be able to test the exception type in the personality >> function - the language I am working on has its own type system, >> unrelated to C or C++, so I want to minimize reliance on C++ exception >>

On 2011-02-14 20:58, Török Edwin wrote: > On 2011-02-14 20:39, Talin wrote: >> >> >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin <rengolin at systemcall.org >> <mailto:rengolin at systemcall.org>> wrote: >> >> I think this deserves a blog post... >> >> I'd like to wait until I get some feedback - I don't know yet if

Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the

I've read and re-read the LLVM exception handling doc, and there are a number of things that aren't clear to me. In the section describing llvm.eh.exception, it says "The backend replaces this intrinsic with the code that accesses the first argument of a call." I don't understand this sentence. A call to what? What is meant by 'accesses' - do you mean

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

I've been struggling for several days, trying to get native exceptions to work in my code. I managed to boil down the IR to the simplest possible example that I can think of. If anyone on this list can tell me what changes I need to make to the following code to get it to work (i.e. return 0 instead of a bus error), it would make my life immensely better. ; ModuleID =

OK I figured out what the problem was - I assume you are trying to compile under Snow Leopard? There is a problem with linking against wxWidgets because the prebuilt binaries for wxWidgets are compiled in 32-bit mode, and the default compilation mode in Snow Leopard is 64 bits. See this article for an explanation: http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard

Hello, Consider this : > setClass("track", representation(x="numeric", y="numeric")) [1] "track" > o <- new( "track", x = 1, y = 2 ) > for( i in o ){ + cat( "hello\n") + } Error: invalid type/length (S4/1) in vector allocation This happens at those lines of do_for: n = LENGTH(val); PROTECT_WITH_INDEX(v =

Hi Talin, You're not using the llvm intrinsics for exception handling, so your code won't work. Using _Unwind_RaiseException should be OK, but your main function must at least use llvm.eh.exception, llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. Nicolas Talin wrote: > I've been struggling for several days, trying to get native exceptions > to