> > What's wrong with running LLVM on ARM? > > LLVM can generate code for ARM, but the JIT requires extra target and > platform dependent stuff, and that's not done for arm-wince.The release notes say "compiler_rt now supports ARM targets". What else is needed? Keep in mind that I do not need (or want) Clang or any of the optimizers: I just want to generate small sequences of machine code in-memory (on the heap, I assume) and execute them. By the way, LLVM comes with 66 projects (BrainF, bugpoint, Kaleidoscope, llc, etc.) and it's not obvious which one(s) I actually need to accomplish this "simple" use of LLVM. Is there a list of all the targets and what they are for?> > It's supposed to support ARM as a target, and since it's written in C > > it should theoretically compile for ARM. > > LLVM is C++, although it has C bindings.Right, sorry, that's what I meant.
----- Original Message ----> From: David Piepgrass <dpiepgrass at mentoreng.com> > To: Óscar Fuentes <ofv at wanadoo.es> > Cc: "LLVMdev at cs.uiuc.edu" <LLVMdev at cs.uiuc.edu> > Sent: Fri, July 16, 2010 2:22:57 PM > Subject: Re: [LLVMdev] Tool for run-time code generation? > > > > What's wrong with running LLVM on ARM? > > > > LLVM can generate code for ARM, but the JIT requires extra target and > > platform dependent stuff, and that's not done for arm-wince. > > The release notes say "compiler_rt now supports ARM targets". What else is >needed? Keep in mind that I do not need (or want) Clang or any of the >optimizers: I just want to generate small sequences of machine code in-memory >(on the heap, I assume) and execute them. >Have you ever tried running a dynamically allocated code that cannot execute malloc() or any runtime libraries or library-based functions because they haven't been ported to your architecture? That's what it would be like trying to run ARM Linux code on your WinCE target. Windows CE requires an LLVM port before it will be useful to you. Put simply, the core architecture of the LLVM ARM backend requires porting to work.
> Have you ever tried running a dynamically allocated code that cannot > execute > malloc() or any runtime libraries or library-based functions because > they haven't been ported to your architecture? That's what it would > be like trying to run ARM Linux code on your WinCE target. Windows CE > requires an LLVM port before it will be useful to you. Put simply, > the core architecture of the LLVM ARM backend requires porting to > work.WinCE offers most of the standard C APIs (such as malloc), as well as most standard C++ libraries including, I think, the same STL that is available under Win32. There could be some gaps, but I hope, given that I only need part of LLVM, that any "porting" I have to do will involve only small tweaks. If you mean that dynamically generated code cannot call malloc (why not? Couldn't I provide a table that tells LLVM the address of malloc and any other methods I want to call?), even then it is not a problem, since the code I want to generate will simply access records and do some arithmetic. For example, I might generate a function that does this: int ReadArrayElement(byte* record, int index, int defValue) { unsigned arraySize = (*(unsigned*)(record + 4) & 0x7F); if (index > arraySize) return defValue; return *(int*)(record + 8 + index * 4); } No method calls there.
----- Original Message ----> From: David Piepgrass <dpiepgrass at mentoreng.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Sent: Fri, July 16, 2010 2:48:10 PM > Subject: RE: [LLVMdev] Tool for run-time code generation? > > WinCE offers most of the standard C APIs (such as malloc), as well as most >standard C++ libraries including, I think, the same STL that is available under >Win32. There could be some gaps, but I hope, given that I only need part of >LLVM, that any "porting" I have to do will involve only small tweaks. > > If you mean that dynamically generated code cannot call malloc (why not? >Couldn't I provide a table that tells LLVM the address of malloc and any other >methods I want to call?), even then it is not a problem, since the code I want >to generate will simply access records and do some arithmetic. For example, I >might generate a function that does this: > > int ReadArrayElement(byte* record, int index, int defValue) > { > unsigned arraySize = (*(unsigned*)(record + 4) & 0x7F); > if (index > arraySize) > return defValue; > return *(int*)(record + 8 + index * 4); > } > > No method calls there. >There's one very big one named ReadArrayElement() right in the middle of what you just typed. You'd have to assume the calling conventions of the ARM code are the same as the x86 code (which is impossible because of the different architectures), or that the calling convention is the same as ARM Linux. You'd need to implement the Windows CE ABIs into the backend to be able to define the C calling convention to call that code. I think you're trivializing something that is more complicated than you are giving it credit for.