Re: JIT ideas
Daniel Grunblatt wrote:
Don't implement any print op yet, if I didn't understood wrong they are
going to be updated to use the IO system.
ok, I draw back them then.
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed increase isn't at all
dramatic, but OTOH I have no idea how to do complicate stuff like allocating
memory natively in asm. these are the string ops that I've implemented in
JIT:
Parrot_set_s_s {
emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[2]);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
}
Parrot_set_s_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) STRING_CONST[2]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_copy, 8);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
}
Parrot_concat_s_s {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) STRING_REG[2]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
}
Parrot_concat_s_sc {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None,
(long) STRING_CONST[2]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None,
(long) STRING_REG[1]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
}
Parrot_concat_s_s_s {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) STRING_REG[3]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) STRING_REG[2]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) STRING_REG[1]);
}
I haven't made extensive testing, but it seems there's a gain of about 10
generations per second with the lifetest. if these changes are welcome, I
will submit a (hopefully proper ;-) patch including other string stuff too.
The -d flag will be use for the parrot debugger, Can't you stop your
debugger at runops_jit?
well, not so easily with MSVC, but maybe it's just me (I haven't much
experience with the Visual Studio stuff).
I can't get MSVC to attach the parrot process (even with the -. option), so
the only chance I have to debug it is to press 'Cancel' when the program
blows up...
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: JIT ideas
On Fri, 24 May 2002, Aldo Calpini wrote:
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed increase isn't at all
dramatic, but OTOH I have no idea how to do complicate stuff like allocating
memory natively in asm. these are the string ops that I've implemented in
There are some ways to do that but we're not going to use any of them, to
allocate memory you can call mem_sys_allocate(), so if you jit the whole
string api even calling it there will be a big win.
I haven't made extensive testing, but it seems there's a gain of about 10
generations per second with the lifetest. if these changes are welcome, I
will submit a (hopefully proper ;-) patch including other string stuff too.
Great, send it, just make sure to mark all the ops that make a call to a C
function like this:
extern Parrot_concat_s_s_s {
Regards,
Daniel Grunblatt.
JIT ideas
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret instructions. the advantage is that such hack is
portable across platform. implementing a more low-level print
mechanism (involving system calls probably) would require several
#ifdef..#endif, I suppose.
anyway, this implements a new function in jit_emit.h which makes
a call to a C function (an absolute address, that is). this is the
function I've added to jit_emit.h:
void emit_call_abs(Parrot_jit_info *jit_info,
long absaddr, int putback)
{
Parrot_jit_newfixup(jit_info);
jit_info-fixups-type = JIT_X86CALL;
jit_info-fixups-param.fptr = (void (*)(void)) absaddr;
emitm_calll(jit_info-native_ptr, 0xdeafc0de);
emitm_addl_i_r(jit_info-native_ptr, putback, emit_ESP);
}
this is very similar to Parrot_jit_normal_op, except that the
address is stored 'as it is' and the bytes to be added to ESP are
variable.
and this is how print_ic is implemented in core.jit:
Parrot_print_ic {
emitm_pushl_i(NATIVECODE, *INT_CONST[1]);
emitm_pushl_i(NATIVECODE, (long) INTVAL_FMT);
emit_call_abs(jit_info, (long) printf, 8);
}
print_nc looks like this (I needed to define a private long because
simply saying (NUM_CONST[1])+4 doesn't work):
Parrot_print_nc {
long mydouble = (long) NUM_CONST[1];
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble+4);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble);
emitm_pushl_i(NATIVECODE, (long) FLOATVAL_FMT);
emit_call_abs(jit_info, (long) printf, 12);
}
also print_sc is similar, except that there isn't a STRINGVAL_FMT
defined in config.h:
Parrot_print_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, (long) STRING_CONST[1]-bufstart);
emitm_pushl_i(NATIVECODE, (long) %s);
emit_call_abs(jit_info, (long) printf, 8);
}
another little thing I've done, but I'm not sure if there's need
for this, is having added these lines to jit.c in the build_asm
routine, just before returning:
if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
fprintf(stderr, *** Parrot VM: JITted code at 0x%08x. ***\n,
jit_info.arena_start);
}
this way when I start 'parrot -j -d something' it tells me where
to find the JIT, and I can goto there directly in the debugger.
it's really a time saver for me.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: JIT ideas
On Thu, 23 May 2002, Aldo Calpini wrote:
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret instructions. the advantage is that such hack is
portable across platform. implementing a more low-level print
mechanism (involving system calls probably) would require several
#ifdef..#endif, I suppose.
anyway, this implements a new function in jit_emit.h which makes
a call to a C function (an absolute address, that is). this is the
function I've added to jit_emit.h:
void emit_call_abs(Parrot_jit_info *jit_info,
long absaddr, int putback)
{
Parrot_jit_newfixup(jit_info);
jit_info-fixups-type = JIT_X86CALL;
jit_info-fixups-param.fptr = (void (*)(void)) absaddr;
emitm_calll(jit_info-native_ptr, 0xdeafc0de);
emitm_addl_i_r(jit_info-native_ptr, putback, emit_ESP);
}
this is very similar to Parrot_jit_normal_op, except that the
address is stored 'as it is' and the bytes to be added to ESP are
variable.
and this is how print_ic is implemented in core.jit:
Parrot_print_ic {
emitm_pushl_i(NATIVECODE, *INT_CONST[1]);
emitm_pushl_i(NATIVECODE, (long) INTVAL_FMT);
emit_call_abs(jit_info, (long) printf, 8);
}
print_nc looks like this (I needed to define a private long because
simply saying (NUM_CONST[1])+4 doesn't work):
Parrot_print_nc {
long mydouble = (long) NUM_CONST[1];
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble+4);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble);
emitm_pushl_i(NATIVECODE, (long) FLOATVAL_FMT);
emit_call_abs(jit_info, (long) printf, 12);
}
also print_sc is similar, except that there isn't a STRINGVAL_FMT
defined in config.h:
Parrot_print_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, (long) STRING_CONST[1]-bufstart);
emitm_pushl_i(NATIVECODE, (long) %s);
emit_call_abs(jit_info, (long) printf, 8);
}
Don't implement any print op yet, if I didn't understood wrong they are
going to be updated to use the IO system.
another little thing I've done, but I'm not sure if there's need
for this, is having added these lines to jit.c in the build_asm
routine, just before returning:
if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
fprintf(stderr, *** Parrot VM: JITted code at 0x%08x. ***\n,
jit_info.arena_start);
}
this way when I start 'parrot -j -d something' it tells me where
to find the JIT, and I can goto there directly in the debugger.
it's really a time saver for me.
The -d flag will be use for the parrot debugger, Can't you stop your
debugger at runops_jit?
Daniel Grunblatt.
Re: x86 linux memory leak checker (and JIT ideas)
Methamphetamine/Speed is probably unhealthy for parrots. On 4/24/02 7:32 AM, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 12:26:57PM +0100, Nicholas Clark wrote: Jarkko mailed this URL to p5p: http://developer.kde.org/~sewardj/ I'd not twigged, but the author (Julian Seward) is the author of bzip2. Another interesting thing he's written is http://www.cacheprof.org/ [again, not tested this - just found the link] It's designed to emulate how algorithms interact with CPU caches, to let you build better (and therefore faster) algorithms. Speed, I seem to remember, is something that parrot is in to. Nicholas Clark
Re: x86 linux memory leak checker (and JIT ideas)
In message [EMAIL PROTECTED] Nicholas Clark [EMAIL PROTECTED] wrote: Jarkko mailed this URL to p5p: http://developer.kde.org/~sewardj/ It describes a free (GPL) memory leak checker for x86 Linux 1: This may be of use for parrot hackers Which is why I mentioned it a week or two ago ;-) I also ran it over the test suite and fixed the only bug that it found at that time... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
