search for: cdecls

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for

Hi - I wrapped R.dll up using somebody code online (see below). I am comparing R on .NET IPC with R(D)COM. I got it all working. Except, I realize that in my client code of the IPC remoting, if I call 'plot' function in R via EvaluateNoReturn, I don't seem to see any results on the R plot window (although the window pops up). Is there anything to do with the code of R.dll wrapper

Hello all, I am a beginner of LLVM and I want to add a new backend into LLVM. The calling convention of the target I ported is CDECL. I am wondering to know whether there is already CDECL calling convention implemented in LLVM?? Which CallingConv.td file should I copy and modify for my target?? thanks a lot Mitnick -------------- next part -------------- An HTML attachment was scrubbed... URL:

What is the correct procedure for translating a function signature from a high-order language to LLVM? It looks like I replace each struct/array parameter with a 'byval' pointer parameter, and I replace a result struct/array with an 'sret' pointer parameter. The reason I ask is that each calling convention has subtle variations for each architecture and platform. For

Hi, I'm trying to load a dynamic link library and it seems to work (is.loaded -> TRUE). When I run the function, which calls the .Fortran subroutine, R crashes! I'v tried the same in S-Plus 2000 and it worked. Therefore I suppose that the dll has been compiled with the stdcall calling convention (and not cdecl). But the problem is that I don't have access to the source code,

I am trying to write a dynamic linked library for R, in Pascal. (This is to speed up the execution of a simulation that I am running in R.) I know Pascal might not be the perfect language for this (C or Fortran being more natural), but from what I have read I think it should work. Though I should point out that I am a neophyte when it comes to DLLs. From R I want to hand a function in

Hi, I am happy to announce that I finished the translation of almost all LGPL'ed R headerfiles to Delphi. As a test I did several demos which basically contain delphized versions of all the examples of chapter 5 in "Writing R Extensions". Please have a look in the attachments for details (DemosAndHeaders.txt), more information (Readme.txt) and an example of how it looks

In preparation for the release, I've compared the llvm-test results for current SVN and the 2.0 release to see how many regressions we have currently. Things are looking really good! Darwin/x86: 2 llvm-test regressions MultiSource/Benchmarks/MiBench/office-ispell/office-ispell (CBE) MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl (CBE) Linux/x86: 5 llvm-test failures

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

Hi Jon, > What is the correct procedure for translating a function signature from > a high-order language to LLVM? you have to do it carefully so that LLVM will end up producing object code that conforms to the platform ABI. For example, suppose you are using cdecl with a small struct (a pair of ints, say). Then your function should get two integer parameters, which LLVM will assign to

Everything builds fine on sparc. The configure script needs to be fixed though (see previous email). Sparc testing results: make check: # of expected passes 1189 # of expected failures 34 Regressions Single Source: None New Failures Single Source (new tests): 2005-05-12-Int64ToFP: llc,jit Regressions MultiSource: Applications/d/make_dparser: llc, cbe, jit

After going through 17000+ lines of output, I come up with the following... =========================================== In file included from /usr/home/llvm/obj/projects/llvm-test/../../../projects/llvm-test/MultiSource/Applications/hexxagon/hexxagonmove.cpp:26: /usr/include/sys/timeb.h:43: error: `time_t' does not name a type

Tanya Lattner wrote: > >> 1. I'm still looking for volunteers to test MacOS X and Solaris. >> If you'd like to volunteer, please email the list to let us know. > > > I'll do minimal testing on Sparc. I'm not going to look into any > regressions though since no one has been really watching Sparc since I > graduated and I am sure there are

2 questions on the code of mini-os (the one in XEN 3.0.3): 1. In xen-3.0.3/extras/mini-os/mm.c:52 is a declaration of stack extern char *stack; but in file xen-3.0.3/extras/mini-os/arch/x86/setup.c:48, there is also a decl of stack: char stack[8192]; If one dereferences the variable stack, which is apparently not the case yet, it gives surely a segfault! 2. In file

A colleague is using Watcom F77 version 11 in Windows NT, and wants to create DLLs callable from R. (He was previously able to do external calls from S-PLUS). Does anyone know what magic is necessary so that it uses the right calling convention? In a debugger, it appears it's using a register-based calling convention, no matter what we ask for, but we're probably asking in the wrong

On 03/17/2010 10:12 PM, Tanya Lattner wrote: > The 2.7 binaries are available for testing: > http://llvm.org/pre-releases/2.7/pre-release1/ > > You will also find the source tarballs there as well. > > We rely on the community to help make our releases great, so please help > test 2.7 if you can. Please follow these instructions to test 2.7: > > /To test llvm-gcc:/

Thanks for your help with this problem about dynamic linked libraries. I thought I had it solved, but apparently not. Below is a small piece of Pascal code that I compile into a library. When I load the library using dyn.load R becomes very unstable. The Mac GUI crashes in all kinds of situations --even moving a window can sometimes crash it. Running from the command line (I thought the

Ignore the missing malloc.h errors. I screwed up badly. I was undoing my alloca.h hack and removed the wrong file. On Tue, 16 Nov 2004 23:29:43 -0800 Jeff Cohen <jeffc at jolt-lang.org> wrote: > After going through 17000+ lines of output, I come up with the following... > > =========================================== > > In file included from

Hi friendly LLVM Devs, I'm trying to understand the technical details of tail call optimization, but unfortunately I hit some issues that I couldn't figure out myself. So I tried the following two really simple functions: > extern void g(int*); > void f1() { > int x; > g(&x); > } > void f2(int* x) { > g(x); > } > It turns out that 'f1'

Hi Martin, Thank you for the hint. > For 32 bit windows, functions with cdecl calling convention (the default > in C) are decorated with an underscore prefix. So you'd need to update > your nasm source file to define the symbol _Foo instead of Foo. (Most > assembly files use some sort of macro for wrapping this detail.) Yes, my assembly files do use prefix macro (ASM_PFX) for