On Mon, 29 Jul 2002, Nicholas Clark wrote: > Here's a very minimal ARM jit framework. It does work (at least as far as > passing all 10 t/op/basic.t subtests, and running mops.pbc)
Cool, I have also been playing with ARM but your approach is in better shape. (I'll send you a copy of what I got here anyway because it's bit more documented and you might want to merge it). > As you can see from the patch all it does is implement the end and noop ops. > Everything else is being called. Interestingly, JITing like this is slower > than computed goto: Yes, function calls are generally slower than computing a goto. > > I doubt in its current form this is quite ready to go in. Points I'd like to > raise > > 0: I've only implemented generator code fully for 1 class of instructions > (load/store multiple registers), partially for a second (load/store > single registers, and hard coded the minimal set of other things I > needed. I'll replaced these with fully featured versions, now that I'm > happy that the concept works > > 1: The most optimal code I could think of to call external functions sets > everything up by loading arguments into registers and function address > into PC a single load multiple instruction. (plus setting the return > address in the link register, by using the link register as the base > register for the load). All that in 1 instruction, plus a second to prime > LR for the load. (This is why I like it) > > However, this is the form of instruction that can trigger bugs on the > (very early) K version StrongARMs. (if it page faults midway) Probably > the rest of the world doesn't have these (unless they have machines > dating from 1996 or so) but I do have one, so it is an important itch for > me. ARM_K_BUG is a symbol to define to generate code that cannot cause > the bug. > > 2: This code probably is the ARM assembler version of a JAPH, in that I've > not actually found the need (yet) to use any branch instructions. They > do exist! It's just that I find I can do it all so far with loads. :-) > > 3: The code as is issues casting warnings and 3 warnings about unprototyped > functions. (which I think can be static) > > 4: I'd really like the type of the pointer for the native code to be > machine chosen. char* isn't the most appropriate type for ARM code - > all instructions are word sized (32 bits) and must all be word aligned, > so I'd really like to be fabricating them in ints, and writing to an int* > in one blat. > > 5: The symbol TESTING was so that I could #include "jit_emit.h" in a test C > program to check my generator (by spitting a buffer out into a $file, and > then disassembling it with objdump -b binary -m arm -D $file > > 6: ARMs with separate I and D caches need to sync them before running code. > (else it all goes SEGV shaped with really really weird backtraces) > I don't think there's any official Linux function wrapper round the > ARM Linux syscal necessary to do this, hence the function with the inline > assembler. I'm not sure if there is a better way to do this. > [optional .s file in the architecture's jit directory, which the jit > installer can copy if it finds?] > > 7: Debian define the archname on their perl as "arm", whereas building from > the source tree gets me armv4l (from uname) hence the substitution for > armv[34]l? down to arm. I do have a machine with an ARM3 here (which I > think would be armv2) but it is 14 years old, and doesn't currently have > Linux on it (or a compiler for RISC OS, and I'm not feeling up to > attempting a RISC OS port for parrot just to experiment with JITs) > It's probably quite feasible to make the JIT work on everything back to > the ARM2 (ARM1 was the prototype and I believe was never used in any > hardware available outside Acorn, and IIRC all ARM1 doesn't have is the > multiply instruction, so it could be done) Ofcourse I didn't even noticed about all those problem, I'm using TD's ARM. > > I'll start writing some real JIT ops over the next few days, although > possibly only for the ops mops and life use :-) Yay!, the ARM will be the first one with string opcodes jitted, I'm looking forward to see if we get good speed up. > [although I strongly suspect that JITting the ops the regexps compile down > to would be the first real world JIT priority. How fast would perl6 regexps > be with that?] Yes, that should be one of the priorities. > > Oh, and prepare an acceptable version of this patch once people decide what > is acceptable > > Nicholas Clark > -- > Even better than the real thing: http://nms-cgi.sourceforge.net/
