Hi, I'm slowly getting to grips with what makes up LLVM. I intend to use it in a machine simulator, e.g. processor, clock, RAM, UART, and other devices, where the processor will be one of several. It would take a block of target instructions, e.g. ARM, and produce LLVM to simulate those on the target machine state, and then JIT them to host instructions and then execute. The peripheral simulations would be in C and end up as LLVM too so optimisations could occur across the ARM->LLVM/peripheral->LLVM boundary. Does this sound a good fit so far? My main question relates to TableGen and decoding the target instructions. I was initially going to use something specific to the task of decoding, e.g. New Jersey Machine Code Toolkit, but wonder if I could/should make use of the *.td for the various processors already known to LLVM with a new TableGen back-end? (I know there isn't support for ARM yet in LLVM.) And perhaps the DAG selector is of use in matching patterns in ARM instructions to the desired LLVM rather than just doing one ARM instruction at a time production? (For ARM, substitute other ISAs, some of which aren't in LLVM.) I'm looking for guidance so I avoid a dead-end. Cheers, Ralph.
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. 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) 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) 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.... regards, and good luck, please let me know how its going... Joseph Aleta(IVO) Ralph Corderoy <ralph at inputplus.co.uk> wrote: Hi, I'm slowly getting to grips with what makes up LLVM. I intend to use it in a machine simulator, e.g. processor, clock, RAM, UART, and other devices, where the processor will be one of several. It would take a block of target instructions, e.g. ARM, and produce LLVM to simulate those on the target machine state, and then JIT them to host instructions and then execute. The peripheral simulations would be in C and end up as LLVM too so optimisations could occur across the ARM->LLVM/peripheral->LLVM boundary. Does this sound a good fit so far? My main question relates to TableGen and decoding the target instructions. I was initially going to use something specific to the task of decoding, e.g. New Jersey Machine Code Toolkit, but wonder if I could/should make use of the *.td for the various processors already known to LLVM with a new TableGen back-end? (I know there isn't support for ARM yet in LLVM.) And perhaps the DAG selector is of use in matching patterns in ARM instructions to the desired LLVM rather than just doing one ARM instruction at a time production? (For ARM, substitute other ISAs, some of which aren't in LLVM.) I'm looking for guidance so I avoid a dead-end. Cheers, Ralph. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --------------------------------- Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060416/2f5c2c14/attachment.html>
On Sun, 16 Apr 2006, Ralph Corderoy wrote:> I'm slowly getting to grips with what makes up LLVM. I intend to use it > in a machine simulator, e.g. processor, clock, RAM, UART, and other > devices, where the processor will be one of several. It would take a > block of target instructions, e.g. ARM, and produce LLVM to simulate > those on the target machine state, and then JIT them to host > instructions and then execute.Ok.> The peripheral simulations would be in C and end up as LLVM too so > optimisations could occur across the ARM->LLVM/peripheral->LLVM > boundary. > > Does this sound a good fit so far?Sure, that makes sense.> My main question relates to TableGen and decoding the target > instructions. I was initially going to use something specific to the > task of decoding, e.g. New Jersey Machine Code Toolkit, but wonder if I > could/should make use of the *.td for the various processors already > known to LLVM with a new TableGen back-end? (I know there isn't support > for ARM yet in LLVM.) And perhaps the DAG selector is of use in > matching patterns in ARM instructions to the desired LLVM rather than > just doing one ARM instruction at a time production? (For ARM, > substitute other ISAs, some of which aren't in LLVM.)This would be an interesting direction to take, but it may not be the easiest one. The easiest direction would be to write a hand coded machine instruction parser (or use something like the machine code toolkit) and then have a switch statement on the opcode to emit LLVM instructions. Of interest may be this thesis. It talks about converting alpha code to LLVM (among other things): http://llvm.org/pubs/2004-05-JoshiMSThesis.html -Chris -- http://nondot.org/sabre/ http://llvm.org/
Ralph Corderoy wrote:> I'm slowly getting to grips with what makes up LLVM. I intend to use it > in a machine simulator,Interesting. We have a simulator that we plan to port to LLVM too ;-)> e.g. processor, clock, RAM, UART, and other > devices, where the processor will be one of several. It would take a > block of target instructions, e.g. ARM, and produce LLVM to simulate > those on the target machine state, and then JIT them to host > instructions and then execute. > > The peripheral simulations would be in C and end up as LLVM too so > optimisations could occur across the ARM->LLVM/peripheral->LLVM > boundary. > > Does this sound a good fit so far?I'm not sure. I would suspect that your peripherals have some internal logic that's independent from CPU. This means that in order to simulate the whole system, you need to use some discrete-event simulation engine, where processor and each peripheral will generate events that will be then executed in order. With such scheme, I don't think you can do optimization across ARM->LLVM/peripheral->LLVM boundary. Well, unless your discrete-event engine is also fully in LLVM, but even then, I'm not sure there's much potential for optimization. Maybe, I misunderstood what you're trying to do?> My main question relates to TableGen and decoding the target > instructions. I was initially going to use something specific to the > task of decoding, e.g. New Jersey Machine Code Toolkit, but wonder if I > could/should make use of the *.td for the various processors already > known to LLVM with a new TableGen back-end? (I know there isn't support > for ARM yet in LLVM.) And perhaps the DAG selector is of use in > matching patterns in ARM instructions to the desired LLVM rather than > just doing one ARM instruction at a time production? (For ARM, > substitute other ISAs, some of which aren't in LLVM.) > > I'm looking for guidance so I avoid a dead-end.As Chris already mentioned, it does not seem like .td file format is very suitable for that. It might be better to use some other tool or implement bit pattern matching manually. - Volodya
Hi Chris,> Of interest may be this thesis. It talks about converting alpha code > to LLVM (among other things): > http://llvm.org/pubs/2004-05-JoshiMSThesis.htmlThanks, it was of interest. I didn't spot its relevance from the title. Cheers, Ralph.