I would look at the backend of the gcc (ARM) cross compiler the pass the generates .s files. These run from a table interface and from AST tree of the intermediate langauge that gcc uses. It is not llvm but it is a mapping mechanism that maps to ARM on one side (half your problem) the other half is the map from llvm byte code to the ast tree which you do not need. <br> <br> Probably taking an ARM assembler map and hand mapping single instructions for all the common stuff would get you going then you could implement something more optimimal if you need. In addition you can optimize llvm bytecode then gen asm or object code depending on your model (Jit I think)<br> <br> gcc intermiate code is quite simple and you should be able to remap using their ARM as a model into llvm. Perhaps even use the output of the test-suite into a mapper program that takes their instruction cases and then looks them up in a symbol table and then returns th llvm equivalent map so you could possibly
 automate the process of the transcoding into ARM assembler (JIT)<br> <br> Anyways juswt some ideas to add to your investigation. In addition please let me know what you find. I am working on seeing about making llvm go on MacPPC on OpenBSD because of the secure environment.... <br> <br> regards, and good luck, please let me know how its going... Joseph Aleta(IVO)<br> <br><br><b><i>Ralph Corderoy <ralph@inputplus.co.uk></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <br>Hi,<br><br>I'm slowly getting to grips with what makes up LLVM.  I intend to use it<br>in a machine simulator, e.g. processor, clock, RAM, UART, and other<br>devices, where the processor will be one of several.  It would take a<br>block of target instructions, e.g. ARM, and produce LLVM to simulate<br>those on the target machine state, and then JIT them to host<br>instructions and then execute.<br><br>The peripheral
 simulations would be in C and end up as LLVM too so<br>optimisations could occur across the ARM->LLVM/peripheral->LLVM<br>boundary.<br><br>Does this sound a good fit so far?<br><br>My main question relates to TableGen and decoding the target<br>instructions.  I was initially going to use something specific to the<br>task of decoding, e.g. New Jersey Machine Code Toolkit, but wonder if I<br>could/should make use of the *.td for the various processors already<br>known to LLVM with a new TableGen back-end?  (I know there isn't support<br>for ARM yet in LLVM.)  And perhaps the DAG selector is of use in<br>matching patterns in ARM instructions to the desired LLVM rather than<br>just doing one ARM instruction at a time production?  (For ARM,<br>substitute other ISAs, some of which aren't in LLVM.)<br><br>I'm looking for guidance so I avoid a dead-end.<br><br>Cheers,<br><br><br>Ralph.<br><br><br>_______________________________________________<br>LLVM Developers mailing
 list<br>LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></blockquote><br><p>
                <hr size=1> 
<font size="2" face="Verdana, Arial, Helvetica, sans-serif"> 
Switch an email account to Yahoo! Mail, you could <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/fifa_truswitch/*http://eur.i1.yimg.com/java.europe.yahoo.com/uk/mail/fu/trueswitch/index.html">win FIFA World Cup tickets</a>. 
</font>