search for: mattgiuca

On Mon, Sep 29, 2008 at 8:49 PM, Matt Giuca <mattgiuca at gmail.com> wrote: > /* snip */ The language I am making is not a traditional scripting language, it is designed for heavy math work. It has not classes, the basic data structure is a struct, yet even those are only used to pass messages. It is using the Actor-Oriented model, not Object-O...

OvermindDL1 wrote: > > I know why it was removed, and it does make sense, just would be nice > if there was an option to be able to get two pointer to a specific > llvm::IntegerType, functionally they would be identical, but for user > code (hence, my code) would be useful as I could match it for the > different ones at generate different code for each. > Well a language

On Mon, Sep 29, 2008 at 9:48 PM, Matt Giuca <mattgiuca at gmail.com> wrote: > It seems like your language is very high level indeed (it almost sounds > dynamic). If you can pass arbitrary messages without needing to statically > know the type of anything, and pass data transparently from one machine to > another. It is in no way dynamic,...

OvermindDL1 wrote: > > It is using the Actor-Oriented model, not Object-Oriented. > /* snip */ > By keeping the type system based on the actual types it allows > arbitrary message passing to any other actor without needing to load > any code relating to the actors, you can just send a structure with > the appropriate ID and format and it will 'just work' as the

Duncan Sands wrote: > > since libgcc is available everywhere llvm is, it's as multi-platform > as llvm! If we didn't use libgcc then we'd have to introduce an llvm > runtime library. Since it would just duplicate the functionality of > libgcc, it would introduce an additional maintenance burden without > bringing any real advantage AFAICS. > So if there's

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me

Jon Harrop wrote: > > Is it? I was just reading the documentation about LLVM's exception > handling > and it sounded ideal for my needs. How much of it does not work as the > docs > imply? > Jon, I ran into this issue in September and re-ignited this discussion in another thread, here: http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html

Marc de Kruijf wrote: > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > definitely not inside the caller's unwind block My target is x86. > > As a simple test, I tried to compile the following code and I got a > segmentation fault. It looks good to me.