Re: [Dotgnu-libjit] Arithmetic operations and type-coercions for byte, short int, ...

[Klaus Treichel]

Am Donnerstag, den 18.09.2008, 17:10 -0700 schrieb Kirill Kononenko:
> Also I do not think there is much sense have support of 16, 8 bit
> opcodes on a 32-bit processor. As it will operate on 32-bit data
> anyways. Actually I have read using 8-bit register can even slow down
> your program.

At least operations on non native sizes add additional latencies because
the cpu has to merge the 8/16 bit from the current result with the
previous register contents.

IMHO it makes more sense to expand the value during load from a register
to the native size what should be done without extra costs and omit the
expansion of the value with an extra instruction. (At least for the
intel x86 family).
This approach doesn't allow usage of the high 8bit registers but i doubt
they are used anyways in libjit.

Klaus

> 
> 
> Thanks,
> Kirill
> 
> 2008/9/18 Jan Wedekind <address@hidden>:
> > Thanks for your response.
> > First of all the time for code generation seems to be negligible for my
> > application. I am interested in libjit, because it is difficult to write a
> > C++ library which provides all possible combinations of operators and
> > element-types.
> >   Looks like I overlooked quite a bit though regarding adding special
> > support for operations on 8- and 16-bit values.
> > If I understand it correctly one needs to do the following things:
> > * add functions supporting the additional types - and combination
> >  of types :( - to jit-intrinsic.c
> > * add instruction sets to jit-rules-*.ins for each platform
> > * update the jit_opcode_descr tables in jit-insn.c
> > * optionally upgrade the backend to support register-register operation
> >  such as 2-byte addition [1]. If I understand it correctly the
> >  code is somewhere in jit-rules-x86.c.
> >
> > I'm not sure whether I will have the time (and a sufficient understanding
> > of the code) to do this. Especially I don't know how to do this without
> > breaking the other backends for Alpha and ARM.
> >
> > [1] http://home.comcast.net/~fbui/intel_a.html#add
> >
> > On Sat, 13 Sep 2008, Klaus Treichel wrote:
> >
> >> Hi Jan,
> >>
> >> Am Sonntag, den 07.09.2008, 11:28 +0100 schrieb Jan Wedekind:
> >>>
> >>> 5AHi,
> >>>   I'm developing a Ruby-extension for doing computer vision [1] with the
> >>> Ruby programming language and I am thinking about replacing the current
> >>> C++ template implementation with an implementation based on
> >>> libjit and ruby-libjit [2].
> >>>   I need to generate code to do element-wise unary operations
> >>> (such as +,-) and binary (scalar-array,array-scalar,array-array)
> >>> operations (such as +,-,*,/,**,minor,major). The element-types of the
> >>> two arrays can be various combinations of char, unsigned char, unsigned
> >>> short int, ...
> >>>   I noted that adding to 8-bit values with libjit results in a 32 bit
> >>> integer. Since I don't want to overwrite succeeding elements in the
> >>> array,
> >>> I need to convert the result back to 8-bit. A performance comparison
> >>> shows
> >>> that this also has an impact on the performance (see below).
> >>>   I had a look at the methods "common_binary" and "apply_arith" and I am
> >>> wondering whether one could extend the code to support coercions
> >>> resulting
> >>> in 8- or 16-bit values as well.
> >>
> >> We'll have to add all arithmetic opcodes for 8bit and 16bit values too
> >> which
> >> will about double the number of opcodes for integer arithmetics (and the
> >> corresponding intrinsics).
> >>
> >> The next step would be supporting backend specific addressing modes for
> >> arithmetic
> >> operations to be able to emit code like add 0x10(%ecx, %edx, 4), %eax on
> >> x86
> >> instead of loading 0x10(%ecx, %edx, 4) to a register first.
> >>
> >>>   Please let me know what you think and tell me if I overlooked
> >>> something.
> >>> It would be really cool if I could get the same performance as a C/C++
> >>> implementation.
> >>
> >> Libjit is still a just in time compiler where the time needed for code
> >> generation has to be taken into account too.
> >>
> >> Any suggestions are welcome.
> >>
> >> Klaus
> >>
> >
> > _______________________________________________
> > Dotgnu-libjit mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/dotgnu-libjit
> >
> >
> 
> 
> _______________________________________________
> Dotgnu-libjit mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/dotgnu-libjit

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil