On Fri, Aug 02, 2002 at 03:59:28PM -0400, Richard Prescott wrote:
> IMHO, C version shall exist anyway, for speed comparaison first (it is
> always surprising how good compilers can be in some situations), then you
> could find tricks that are faster on some processors (let's say AMD) and
> not on some others for the same instructions set.
>
> I still encourage the asm version.
The arm backend on gcc isn't always that good. I'm told its because gcc is
not really architectured on the basis that the target machine could have
all instructions conditional.
In the end I decided that it's faster for me to write C now, particularly
as the JIT may well change again a few times, but I did resort to assembler
for a single 32 bit rotate instruction, as it's terser than writing it in
C as 2 shifts orred together plus casting to unsigned to avoid sign extension.
Another question:
Is there an easy way for the jit op implementation to have a peek at its
parameters, and then decide "too hard" and fall back to inserting the code
to call the real parrot op?
I'm thinking of the case of DIV $1, $2, constant
where I'd like to be able to write (in pseudocode)
Parrot_div_i_i_ic {
if (op3 == 2) {
op1 = op2 >> 2
} else {
call the C subroutine that the jit normally uses
}
}
[I'm assuming that dividing by 2 may well be a common enough case to be
interesting, and ARM has no hardware divide, so without this I'd have to choose
between a shift operator and implementing a call to division subroutine.
It seems that foo & (foo - 1) is zero only for a power of 2 (or foo == 0)
but is there a fast way once you know that foo is a power of 2, to find out
log2 foo?
I presume in the general case I'd have to know whether to call
Parrot_jit_normal_op() or Parrot_jit_cpcf_op(), so could there be a subroutine
in jit.c that I could call to make the correct decision for me?
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
