similar to: [LLVMdev] Generic target?

On May 2, 2010, at 10:45 AM, Samuel Crow wrote: > Hello LLVM list, > > I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to

Hi Nate, I've successfully ported one bitcode from Linux to Mac to Windows.  All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help.  Currently it just wraps StdIO.h with its own functions. Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: * Convert all

Hi again, My point is that your code could not be written in C++ at this time because the only complete compiler for C++ is LLVM-GCC. It will do little endian optimizations on your x86 box and make the resultant bitcode file not work on the ARM processor. It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. Also the FAQ also

Hello again, My partner and I am modifying a PEG parser generator to produce LLVM bitcode from a version of a parsing expression grammar that takes LLVM Assembly as code. It accepts external libraries in its current state so we are writing an external library in C++ using C bindings for the linkage. Trying to get it to link is proving to be more challenging than expected. My partner is trying

I don't think I quite understand this... suppose for example you're trying to use an LLVM-based toolchain running on an x86 PC to write code for a device that uses an ARM processor in big endian mode, so you tell the LLVM code generator "generate code for ARM, big endian"... are you saying the optimizer will actually assume the target device is little endian because the

Hello OvermindDL1, We are implementing an extensible language. That's one where you can add commands and constructs to the language without having to recompile the parser. We want compilation of the parser in order to "freeze" it but only as an option. One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template

Hello everybody, We've just got our command-line driven program to compile after having converted our command-line option parser to use LLVM's commandline class. The problem we've run into is that we get the following for llvmpeg --help : USAGE: llvmpeg [options] <input file> OPTIONS: -I=<path> - Specify an additional include path -help - Display

Hello Anton, Our main.bc was generated with the following command line: llvm-g++ -Illvm\include -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -c -emit-llvm -omain.bc main.cpp The amos.bc file was generated by our experimental llvm-peg parser generator whose internal workings are assembled internally using LLVM Assembly. The parser generator links a C++ library bitcode with C bindings called

> I agree with you OvermindDL1, > > SInce the language I'm going to be working on doesn't support varargs, it would be nice to be able to ditch the C calling convention for fastcc in all occurrances for an added speed boost.  I also will need to add my own library calling convention on one platform I plan on supporting which will be register-loaded as well. Are you going to be

----- Original Message ---- > From: Eli Friedman <eli.friedman at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, August 31, 2009 3:49:01 PM > Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT > > On Mon, Aug 31, 2009 at 12:17 PM, Samuel

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com> wrote: > > > > > ----- Original Message ---- >> From: Kenneth Uildriks <kennethuil at gmail.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent:

----- Original Message ---- > From: Kenneth Uildriks <kennethuil at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 12:22:55 PM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > >

On 6/2/2011 10:13 AM, Samuel Crow wrote: > Hi Nate, > > I've successfully ported one bitcode from Linux to Mac to Windows. All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help. Currently it just wraps StdIO.h with its own functions Naturally that would work perfectly fine on a similar

Hello > It is complaining about not being able to find __gxx_personality_sj0 and the LLVM command line parser-related files.  What else do we need to link? This is personality function for sjlj eh. How the source bitcode files in questions were generated? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello LLVM team, In the past I've worked on a PEG parser generator for any LLVM-based language to use.  One obstacle we ran into when generating LLVM IR assembly was that we'd end up cutting and pasting a list of declarations and aliases into every .ll file that needed to link with the others.  I'd propose that in the Bitcode 3.0 format, that a header definition be added to the IR

Hello everybody, I don't quite understand how the proposed regex library works but I know that PEG parser generators use a super-set of regex functionality to define their parsers. There's also a nice one on Google code called YARDparser that uses templates based on PEGs to generate efficient recursive-decent parsers. Furthermore, my partner and I am working on an interpreter for PEG

On Mon, Aug 31, 2009 at 6:23 PM, Samuel Crow<samuraileumas at yahoo.com> wrote: > If you're wondering why we're doing an interpreted PEG parser generator rather than Boost Spirit 2.x, it's because we need it to be easier to debug the parser.  Once the parser is debugged it can be fed into a compiled parser generator and "frozen" into stand-alone parser code. You do

Hello, Samuel Crow wrote: > It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. > Which ones llvm assembler instructions is not endian-agnostic? -- Ivan

Hi, I'd like to use LLVM to compile and optimise code when I don't know whether the target CPU is big- or little-endian. This would allow me to create a single optimised LLVM bitcode binary of an application, and then run it through a JIT compiler on systems of differening endianness. I realise that in general the LLVM IR depends on various characteristics of the target; I'd just

Hello Russell, Major pitfall #1: LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. I've been looking forward to the day that LLVM can be used for cross-architecture