search for: unboxes

So I now have a working first-order language that uses conventional boxing to handle polymorphism and with ints, floats and ('a -> 'a) functions. After a huge amount of detailed benchmarking in OCaml and F# I have decided that it is very important to be able to unbox complex numbers but no other compound types. As LLVM provides a vector type for power-of-two dimensionalities that

On Nov 29, 2007, at 16:06, Jon Harrop wrote: > So I now have a working first-order language that uses conventional > boxing to handle polymorphism and with ints, floats and ('a -> 'a) > functions. Cool. > After a huge amount of detailed benchmarking in OCaml and F# I have > decided that it is very important to be able to unbox complex > numbers but no other

On 10/25/13 1:10 PM, Ben Karel wrote: > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com > <mailto:sanjoy at azulsystems.com>> wrote: > > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects

On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote: >>> I don't think you would want to build discriminated unions on top of >>> C-style unions though. >> >> Why? > > Uniformity when nesting and space efficiency. Users of a language > front-end > will want to nest discriminated unions, e.g. to manipulate trees. Okay, so you're just talking about boxed

On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects are invalidated at every > safepoint" somehow in the IR itself. So, if %a and %b are values the > GC is

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves

On Friday 02 January 2009 20:48:25 Chris Lattner wrote: > On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: > >> Exactly. I'm not especially interested in C-style unions, I'm > >> interested in discriminated unions. But the actual discriminator field is > >> easily represented in LLVM IR already, so there's no need to extend the > >> IR to support

On Sunday 04 January 2009 01:25:05 Chris Lattner wrote: > On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote: > >>> I don't think you would want to build discriminated unions on top of > >>> C-style unions though. > >> > >> Why? > > > > Uniformity when nesting and space efficiency. Users of a language > > front-end > > will want to

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: >> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

In the creation of dynamic languages we often have to box values together. For instance, take the following expression: IntObj c = sqrt((a*a)+(b*b)); Here, most likely, a bytecode interpreter would execute this as "mul_ints", "add_ints", "sqrt", etc. Inside these primitive functions we would have to unwrap our IntObj types, add the values, allocate a new object and

Hi, At the code below from ./bindings/ocaml/executionengine/executionengine_ocaml.c, we create an OCaml Variant from C. It is from 2.6, the latest 2.7 has the same code. Line 240 Option = alloc(1, 1) assigns tag1 to the 'some' constructor. In term of http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html, I think the 'some' should have a tag 0. We dont have a runtime error for

...ethod with the right argument > types. > > One obvious way to do this is to generate two stub functions for every > function emitted by the compiler, one that takes the original argument > signature and creates a list of boxed objects, and one that takes a list > of boxed objects, unboxes them and then calls the function. However, > that's a lot of extra code to generate, and I am concerned about the > amount of code bloat that would create. > > What would be better is if there was some way for the generic handler > function to be able to dynamically get a picture...

.... >>> >>> One obvious way to do this is to generate two stub functions for every >>> function emitted by the compiler, one that takes the original argument >>> signature and creates a list of boxed objects, and one that takes a list >>> of boxed objects, unboxes them and then calls the function. However, >>> that's a lot of extra code to generate, and I am concerned about the >>> amount of code bloat that would create. >>> >>> What would be better is if there was some way for the generic handler >>> function...

I need some advice on "forwarding" arguments to a callee. Suppose I have a function F that is called at the beginning of all other functions in the module. From F I need to access (read) the arguments passed to its immediate caller. Right now I do something like boxing all arguments in the caller inside a struct and passing a pointer to the struct to F, alongside an identifier

On Sun, Feb 28, 2010 at 8:38 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Hi, > > At the code below from > ./bindings/ocaml/executionengine/executionengine_ocaml.c, > we create an OCaml Variant from C. It is from 2.6, the latest 2.7 has > the same code. > > Line 240 Option = alloc(1, 1) assigns tag1 to the 'some' constructor. > In term of

Move the code for handling machine readable up in the file, so it can be used by other functions. Only code motion, no behaviour changes. --- common/mltools/tools_utils.ml | 60 +++++++++++++++++------------------ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/common/mltools/tools_utils.ml b/common/mltools/tools_utils.ml index 24641369e..5a35708cd 100644 ---

On Sunday 25 November 2007 21:00, Chris Lattner wrote: > >> Lexing is the one issue though. > > > > How do you mean? > > I think he's observing that a majority of the tutorial code is > actually spent on the lexer and parser, not on the llvm-specific pieces. Right. > > I'm just fiddling around with it now. The lexer, parser and AST > > written

To illustrate the value of value types to the OCaml community I recently did a couple of benchmarks. The first was similar to a hash table and stores key-value pairs unboxed in an array: http://groups.google.com/group/fa.caml/msg/8430ebdb687b9268 The second is the hailstone benchmark that the Haskell guys found gave huge performance improvements when using LLVM from GHC: