--- Log opened Thu Jul 02 00:00:46 2009
00:50 < tgrabiec> grr, the vtable is broken, it calls Throwable.getStackTrace() instead of Throwable.getMessage()
00:50 < tgrabiec> that was sneaky
00:52 < tgrabiec> the actual class is RuntimeException
01:02 < tgrabiec> hmm, but vtable seems to be initialized correctly
01:27 < tgrabiec> the problem is that fixup_vtable() is broken because it uses the old ->method_index, and now we have ->virtual_index
01:39 < tgrabiec> now I'm blocked by java/util/Hashtable.<init>()  which fails in monoburg. Are you guys working on it?
01:42 < tgrabiec> about fixup_vtable() - it used method_index because that's what JamVM used as what we call now visrtual_index
01:56 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit ["Leaving"]
07:22 < penberg_home> ahuillet: I was reading on x87 last night
07:23 < penberg_home> ahuillet: man that's some crazy model to program with
07:23 < penberg_home> I have no idea how compilers generate code for that.
08:04 < vegard> ouch to tgrabiec's bug
08:15 < vegard> we're going to need invokeinterface :)
08:26 <@penberg> vegard: yes.
08:26 <@penberg> did you hit that already?
08:27 < vegard> yep
08:27 <@penberg> vegard: http://www.research.ibm.com/people/d/dgrove/papers/oopsla01.html
08:28 < vegard> jit_magic_trampoline: ret0=0xa7bc80ed, ret1=0xa7bc8f41: java/lang/VMClassLoader.getBootPackages #7
08:28 < vegard> bc_insn_size: Unknown bytecode opcode: 0xb9
08:28 <@penberg> yup, I anticipated that.
08:28 <@penberg> ahuillet_ didn't believe me.
08:28 <@penberg> vegard: I don't think that's going to be a big issue for us, though.
08:29 <@penberg> ahuillet_, vegard: wanna take a stab at it?
08:29 < vegard> penberg: invokeinterface considered harm_less_ ?
08:29 <@penberg> yes.
08:30 <@penberg> vegard: it turns out, the naive implementation if invokeinterface is a performance train-wreck ;)
08:30 <@penberg> vegard: read the paper?
08:30 < vegard> I'm working on it :)
08:30 <@penberg> vegard: I think we should just implement the IMT approach
08:31 <@penberg> vegard: unless you want to do it in some other way
08:31 < vegard> hmmm
08:32 < vegard> hashtable lookup ??
08:32 < vegard> it sounds seriously inefficient
08:32 <@penberg> vegard: yup.
08:32 <@penberg> vegard: ok, I'll just let you read that paper and figure out the alternatives.
08:32 <@penberg> let me find some more papers for you
08:34 <@penberg> vegard: (check references of that paper, btw, and see smalltalk appear there again.)
08:35 <@penberg> vegard: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.8042
08:35 <@penberg> that paper also appears in the references
08:35 <@penberg> IMO good read.
08:37 < vegard> how does c++ handle multiple inheritance?
08:37 <@penberg> dunno.
08:38 <@penberg> vegard: check Section 4.4
08:38 <@penberg> just read the paper ;)
08:38 <@penberg> Section 4.4 ("Multiple Inheritance in C++")
08:45 < vegard> " the classloader may not load the full interface hierarchy before  compiling
08:46 < vegard> a class's methods "
08:46 < vegard> but that's not true, is it?
08:46 <@penberg> hmm
08:46 <@penberg> does it say why?
08:46 <@penberg> I think you can add interfaces to classes after loading
08:47 < vegard> we can load away as much as we want, but not initialize them is my impression
08:47 <@penberg> I'm not sure how familiar you are with bytecode manipulation.
08:47 <@penberg> vegard: ok, I don't know the details here.
08:47 <@penberg> Did I post this already? http://www.weiqigao.com/blog/2009/06/30/the_jvm_is_not_the_center_of_the_universe.html
08:47 < vegard> don't think so
08:48 <@penberg> It was interesting enough for me to write a comment.
08:48 <@penberg> I spent something like 15 minutes writing it
08:49 <@penberg> and when I submitted it the damned software told me it was rejected because it thought the comment was spam!
08:49 <@penberg> I was not able to recover it and thought it went to /dev/null
08:49 < vegard> lool
08:49 <@penberg> luckily it went to their database
08:49 <@penberg> and was recovered
08:49 <@penberg> I was pretty pissed off last night.
08:49 <@penberg> ;)
08:58 < vegard> arg, this is going to be bothersome, I think.
09:01 <@penberg> vegard: yeah?
09:02 < vegard> yes. I am trying to picture what the generated asm would look like
09:02 < vegard> and I can't think of any way that it won't be huge
09:04 <@penberg> how come?
09:04 <@penberg> see Figure 1 of the paper.
09:09 < vegard> yes, then look at figure 2 :)
09:10 <@penberg> vegard: but that's _out of line_
09:12 < vegard> what do you mean?
09:12 <@penberg> that's the conflict resolution stub
09:14 <@penberg> "If there is no collision, then the IMT entry holds a reference to the executable code of the callee method"
09:14 <@penberg> so we always go through the IMT
09:14 <@penberg> we can even write the conflict resolution stub in C
09:14 <@penberg> at this point.
09:15 < vegard> um
09:15 < vegard> we're going to need a different stub for every class, right?
09:16 <@penberg> hmm, yes, probably
09:16 <@penberg> but AFAICT, we can write a generic one too.
09:16 <@penberg> that's slow but does the trick.
09:16 <@penberg> vegard: right?
09:16 < vegard> they pass one of the parameters to the stub in a register
09:16 <@penberg> that's because it's ppc
09:17 <@penberg> arguments in registers
09:17 <@penberg> just think of the conflict resolution stub as yet another trampoline.
09:17 < vegard> but we can't back-patch the result
09:18 <@penberg> no, we can't.
09:18 < vegard> so this stub needs to be called every time
09:18 <@penberg> yes.
09:18 <@penberg> _if_ there's a conflict
09:18 <@penberg> and none of this matters with inline caching either
09:18 <@penberg> hell
09:18 <@penberg> we could implement inline cache of our own in the stub
09:19 <@penberg> have a fast-path where we test for the most commonly used receiver
09:19 <@penberg> and do a direct call to the address.
09:19 <@penberg> but anyway, lets not worry about that
09:19 <@penberg> inline caching is even better
09:19 <@penberg> because it moves the fast-path to the actual call-site
09:20 <@penberg> so in the fastpath case, we never even bother to check the IMT
09:20 <@penberg> most call-sites end up landing in the same receiver.
09:20 <@penberg> which makes a lot of sense.
09:21 <@penberg> but still, lets not worry about that
09:21 <@penberg> IMT + generic resolution stub would be my suggestion.
09:21 <@penberg> also, keep in mind that the IMT must have pointers to _trampolines_ initially.
09:22 <@penberg> and then either a pointer to the executable code
09:22 <@penberg> or to a resolution stub
09:22 <@penberg> vegard: and as you can see in the paper, if you make the IMT big enough, you hardly ever get conflicts anyway
10:35 <@penberg> http://github.com/penberg/jato/commit/3e04dfc25aaeb7ee2a69ded104dcc8db5ffe6814
10:35 <@penberg> did I cause bad conflicts now?
10:45 <@penberg> vegard: ping
10:51 < vegard> ping!
10:51 <@penberg> vegard: IMT
10:51 <@penberg> vegard: convinced?
11:03 < vegard> not entirely
11:03 < vegard> I didn't read the paper thoroughly
11:03 <@penberg> aha
11:20 < vegard> it seems a bit sketchy, that's why I'm sceptical
11:20 < vegard> I can't convince myself that there is no better way to do it
11:21 < vegard> something simpler and more obvious, perhaps
11:21 < ahuillet_> hi
11:23 <@penberg> ahuillet_: hi
11:23 <@penberg> vegard: yup
11:23 <@penberg> vegard: that's why I said we should just implement the IMT approach.
11:23 <@penberg> vegard: I was afraid you'd start thinking about it
11:23 <@penberg> which just slows you down ;)
11:36 <@penberg> vegard: hmm, ARRAY_SIZE() and "int i"
11:36 <@penberg> vegard: how to shut GCC up here?
11:48 < vegard> ARRAY_SIZE() and "int i"?
11:48 < vegard> where?
11:48 <@penberg> vm/jato.c
11:48 <@penberg> I tried -Wno-sign-compare but the warning is still there
11:48 < vegard> oh
11:48 <@penberg> Ubuntu probably has hard-coded -Wsign-compare in the distro GCC :(
11:48 < vegard> ARRAY_SIZE is unsigned, i is signed
11:48 <@penberg> well the point is
11:48 <@penberg> do we _really_ care?
11:49 < vegard> where is the warning?
11:49 < vegard> just use "unsigned int"
11:49 <@penberg> hmmhmhm
11:49 <@penberg> I don't like that.
11:49 <@penberg> oh well
11:49 < vegard> why not?
11:50 < vegard> but it's correct. an array index can never be negative (assuming index 0 is the start of the array)
11:50 <@penberg> fixing
11:51 < vegard> I like the itables approach much more than ITV
11:53 <@penberg> IMT
11:53 <@penberg> vegard: the paper also explains that itables are slower.
11:53 <@penberg> but whatever you decide
11:53 < vegard> oh sorry
11:53 <@penberg> i just want invokeinterface
11:56 < vegard> I have a sort of vague idea of an implementation
11:57 < vegard> if each class knows which interfaces it implements, we can construct a per-class perfect hash
11:59 < vegard> hm, I realized that you probably want something that's tested and tried, rather than some of my ad-hoc algorithm that might not even work :-p
12:02 < vegard> so this is not a proposal on how to do it, rather it's just my thinking aloud on possible ways to do it
12:04 -!- tgrabiec [i=tgrabiec@abkw35.neoplus.adsl.tpnet.pl] has joined #jato
12:16 < vegard> hm, ok, maybe IMT isn't that bad
12:18 < vegard> but where do we get the "imtOffset" ?
12:18 < vegard> computed from the interface signature..
12:19 < vegard> and all classes have a fixed-size imt table
12:25 <@penberg> something like that yeah
12:31 < ahuillet_> ok, today hopefully sees CMPL done
12:31 < ahuillet_> the hangover isn't too bad I'll be back in order after eating
12:34 <@penberg> ahuillet_: ;)
12:34 <@penberg> ahuillet_: vegard is implementing invokeinterface for S.o.println()
12:34 <@penberg> told you we would hit it ;)
12:36 < ahuillet_> next celebration is saturday evening
12:36 < ahuillet_> get me something to celebrate. :)
12:39 <@penberg> vegard: ahuillet_ is counting on you!
12:40 < ahuillet_> I'll provide floating point ASAP :)
12:43 < vegard> ok.
12:43 < vegard> I will implement IMT
12:43 < vegard> I understand it fully now.
12:44 < vegard> I think there's a way to improve it with 2 extra instructions (1 load, but it touches the same cacheline as another)
12:44 < vegard> (most likely anyway)
12:44 < vegard> don't know if that's worth it (probably not _now_ anyway)
12:46 < vegard> we could make the per-class IMT be variable sized in a power of two, so table sizes can be 1, 2, 4, 8, etc. then we load the table size (well, table mask actually) from the class pointer and mask off the bits of the vmt offset that would go beyond the imt
12:46 < vegard> hm, that's probably 3 more instructions though.
12:46 <@penberg> vegard: generic resolution stub?
12:47 < vegard> I think I'll do that, yes, because it's easier.
12:47 < vegard> then we can optimize it later by generating the code
12:48 < vegard> hm, actually my optimization would be worse than that. because the IMT approach in the paper assumes that the IMT itself is "inlined" in the class struct
12:48 < vegard> and we wouldn't be able to do that. I think, unless we attach it to the end of the class struct.
12:49 < vegard> we could do that; do we want the end of the struct for something else later?
12:49 <@penberg> vegard: probaby not
13:22 < vegard> here's my idea for variable itable sizes: http://pastebin.com/m34ccc20a
13:22 < vegard> oh wait, that one instruction is probably not valid
13:24 < vegard> actually it is. that's nice
13:26 < vegard> so it should be doable in 5 x86 instructions
13:30 < ahuillet_> CISC ftw :)
13:31 < vegard> hm, we need a way to pass the "untampered" signature id to the conflict resolution function too
13:34 < vegard> I really don't like the idea of a fixed-size table.
13:35 < vegard> 1. If we don't make it big enough, it _will_ waste time for classes that implement more interfaces than the size of the table (modulo the interfaces that hash to the same index)
13:36 < vegard> 2. If we make it too big, it _will_ waste space for _every_ class that implements fewer interfaces
13:37 < vegard> but I will wimplement the simple IMT variant first, and we can use perf to see if there's a noticable difference in speed
13:44 <@penberg> vegard: yes.
13:44 <@penberg> please.
13:44 <@penberg> you can optimize it to your hearts content.
13:44 <@penberg> but lets get S.o.println() working first.
15:14 <@penberg> vegard: so, my setup is still failing like this for PrintTest:
15:14 <@penberg> convert_invokestatic: warning: unable to resolve invocation target
15:14 <@penberg> compile_error: error: Failed to compile method `<clinit>' in class `java/lang/System', error: -22
15:14 <@penberg> vegard: expected?
15:17 -!- tgrabiec [i=tgrabiec@abkw35.neoplus.adsl.tpnet.pl] has quit []
15:20 < ahuillet_> Otherwise, at least one of value1' or value2' is NaN. The fcmpg instruction pushes the int value 1 onto the operand stack and the fcmpl instruction pushes the int value -1 onto the operand stack.
15:20 < ahuillet_> emulate_fcmpl() it is.
15:22 <@penberg> yup, makes sense.
15:30 < ahuillet_> so, float on the stack
15:33 < ahuillet_> oh god
15:33 < ahuillet_> cvtss2si does float->integer *conversion*
15:33 < ahuillet_> it's not what I have to use at all
15:37 < ahuillet_> what a set back....
15:44 <@penberg> :(
15:45 < ahuillet_> I don't remember, does %esp point to the next free slot?
15:45 < ahuillet_> or to the last occupied slot?
15:45 < ahuillet_> ie. do I write at (%esp) or -4(%esp) ?
15:46 <@penberg> stack grows down
15:46 < ahuillet_> that doesn't answer my question
15:46 <@penberg> so i think it's %esp
15:46 <@penberg> %esp points to the top of the stack
15:47 < ahuillet_> there are two definitions of "top" that's my problem
15:47 < vegard> but "push" writes before it decrements ;)
15:47 < vegard> er
15:47 < vegard> I don't remember :-(
15:47 < ahuillet_> push writes before it decrements? so I have to write at %esp
15:48 <@penberg> no i don't think that's correct.
15:48 <@penberg> check out intel docs
15:48 < vegard> I think I meant to say it decrements before it writes
15:48 < ahuillet_> so -4(%esp) ? :)
15:48 <@penberg> yes, next free is -4(%esp)
15:48 <@penberg> but what are you doing?
15:48 <@penberg> you can't write beyond the stack
15:48 < ahuillet_> confirmed, it decrements then writes
15:48 < ahuillet_> penberg : yes I can :]
15:48 < ahuillet_> faster than using push
15:49 <@penberg> hmhm?
15:49 < ahuillet_> mov $imm, -4(%esp); movss -4(%esp), %xmm0;
15:49 <@penberg> gcc does that too?
15:49 < vegard> ahuillet_: I think valgrind chokes on that (unless you put --workaround-gcc297-bugs or something)
15:49 < vegard> (not that we can use valgrind anymore _anyway_...)
15:49 < ahuillet_> ah well, I can decrement esp before and increment it afterwards
15:49 < ahuillet_> it's just a bit pointless
15:50 <@penberg> ahuillet_: but as far as I can tell, it's not completely safe
15:50 < ahuillet_> penberg : why?
15:50 <@penberg> stack is allocated on demand
15:50 <@penberg> well ok
15:50 <@penberg> then you write to it and pages are allocated
15:50 <@penberg> ok
15:50 <@penberg> fine.
15:50 < ahuillet_> I believe it's ok
15:51 < ahuillet_> it's not like adding a subl $4, %esp; will change much anyway
15:51 <@penberg> no no
15:51 <@penberg> agreed.
15:51  * penberg is just being silly.
15:52 < ahuillet_> it's really annoying that movss cannot interact with GPRs
15:52 < ahuillet_> in SSE1, you basically can't move data around between GPRs and XMM registers without going through memory
16:06 <@penberg> ahuillet_: that's pretty horrible
16:06 < ahuillet_> SSE2 fixes it, movd/movq
16:07 < ahuillet_> [     4 ]  0x97ecb4cc:   c7 44 fc 00 00 00 c0 f3    movl   $0xf3c00000,0x0(%esp,%edi,8)
16:07 < ahuillet_> now that's what screwing up is about. :]
16:12 < ahuillet_> aha
16:12 < ahuillet_> we can't mov -4(%esp)
16:12 < ahuillet_> it doesn't exist. :)
16:14 < ahuillet_> grrrrrrrrr.
16:19 < ahuillet_> penberg : help
16:19 < ahuillet_> penberg : I have four bytes of data to write on stack
16:19 < ahuillet_> get_local_slot() requires a slot number
16:19 < ahuillet_> what can I do?
16:19 < ahuillet_> I can't -4(%esp) so I need ebp-relative addressing
16:20 < ahuillet_> I can cheat by doing a mov %esp, %eax and doing %eax-relative addressing
16:20 < ahuillet_> but maybe there is a better solution.
16:26 <@penberg> why can't you -4(%esp)?
16:26 < ahuillet_> because it does not exist in x86
16:27 < ahuillet_> the ModRM byte cannot encode disp(%esp)
16:27 < ahuillet_> it cannot encode (%esp) FWIW
16:27 < vegard> that's CISC for ya ;-)
16:27 <@penberg> yes it can.
16:27 <@penberg> we've done 0x00(%esp)
16:28 <@penberg> select_insn(s, tree, membase_reg_insn(INSN_MOV_MEMBASE_REG, stack_ptr, 0, call_target));
16:28 <@penberg> commit b6e44b1d2b906ca2e61b83279a741d24bab69629
16:28 < ahuillet_> looking at table 2-2 I don't see how you did this :)
16:29 < ahuillet_> there is no indirect ESP adressing in modrm
16:29 < ahuillet_> they used the slot to indicate SIB presence
16:29 <@penberg> hmm
16:29 <@penberg> anyway
16:29 <@penberg> try it out
16:29 < ahuillet_> I tried it out
16:29 < ahuillet_> the disassembler gets confused because it wants a SIB
16:30 < ahuillet_> movl   $0xf3c00000,0x0(%esp,%edi,8)
16:30 < ahuillet_> that's your move. :)
16:30 < ahuillet_> movl $0xf3c00000, -4(%esp)
16:31 < ahuillet_> so what is in the commit you pointed out is not going to work either
16:31 <@penberg> of course it was working
16:31 <@penberg> the commit I mentiond, _removed_ it
16:31 <@penberg> it's been working since day zero
16:31 < ahuillet_> well, the intel documentation and my experiment say it's not possible
16:32 < ahuillet_> seriously, look at the modRM table
16:32 <@penberg> hmm but that's
16:32 <@penberg> membase -> reg
16:32 <@penberg> you have imm -> membase, no?
16:32 < ahuillet_> same problem
16:32 < ahuillet_> but yes
16:33 <@penberg> c7 44 24 fc 00 00 c0 movl   $0xf3c00000,-0x4(%esp)
16:33 <@penberg> func: movl $0xf3c00000, -4(%esp)
16:33 <@penberg> as compiled by gcc
16:33 < ahuillet_> ok I get it
16:34 < ahuillet_> that's not -4(%esp)
16:34 < ahuillet_> that's -4(nothing, %esp, 1) or something like this
16:34 <@penberg> so what is it?
16:34 <@penberg> anyway, I don't know why you want me to look at documentation
16:34 < ahuillet_> -4(%esp, %eiz, 1) sorry
16:34 <@penberg> when I know for a fact that 0x0(%esp) -> reg _works_
16:35 < ahuillet_> so ok it can be worked out but it's not regular membase :)
16:35 <@penberg> that's _x86 legacy_ for ya baby
16:35 <@penberg> I always try with gas first.
16:35 < ahuillet_> penberg : problem is, it's not regular indirect adressing
16:35 < ahuillet_> we can't emit it like we emit the other membase
16:35 <@penberg> then look up documentation.
16:35 < ahuillet_> because -4(%esp) doesn't exist per se
16:35 <@penberg> ahuillet_: fix it?
16:36 <@penberg> special-case it
16:36 < ahuillet_> mmh
16:36 <@penberg> if (reg == REG_ESP) foo_bar()
16:36 <@penberg> _it exists_
16:36 < ahuillet_> not like I have much of a choice anyway
16:36 <@penberg> ok, I'm off!
16:36 <@penberg> catch you guys later.
16:36 < ahuillet_> the assembler notes it like it wants, it's just confusing to pretend it's regular indirect adressing when it is not
16:37 < ahuillet_> certain versions of binutils output the infamous %eiz thing
17:39 < vegard> ok, we can construct the IMTs now
17:40 < ahuillet_> ok, big patch on its way to the list
17:40 < ahuillet_> floating point is taking shape.
17:40 < vegard> nice :D
17:42 < ahuillet_> the problem is
17:42 < ahuillet_> float abc() <- doesn't work
17:42 < ahuillet_> the return value isn't handled correctly, for now.
17:43 < vegard> can we violate C abi and use something like get_float_return_value() from C to get the whatever fp register that contains the return value of the last called function?
17:44 < vegard> and use a fixed fp register for the jit code
17:44 < ahuillet_> penberg will kill me for this
17:44 < ahuillet_> but what I had in mind was to return into %eax anyway
17:44 < vegard> ahh
17:44 < vegard> that's not so bad.
17:44 < vegard> is it big enough to hold doubles?
17:45 < ahuillet_> no
17:46 < vegard> but I guess unsigned long long int is?
17:46 < ahuillet_>  do I look like I care about doubles? :D
17:46 < ahuillet_> vegard : EDX:EAX yes
17:46 < vegard> then we could just make a wrapper in C
17:46 < vegard> to get return values
17:47 < vegard> and declare the function with uint32_t or uint64_t (or we can even make our own type!)
17:47 < vegard> struct jit_float { enum { uint32_t x; float y; } };
17:47 < vegard> jit_float float_method();
17:48 < vegard> jit_float x = float_method();
17:48 < vegard> printf("%f\n", x.float_value);
17:48 < vegard> (er, yeah, x and y should be "raw" and "float_value" probably ;-))
17:48 < vegard> and
17:48 < vegard> s/enum/union/
17:49 < vegard> well, I gotta go, see you later!
17:57 < ahuillet_> ok
17:57 < ahuillet_> I'm raping the ABI here
17:57 < ahuillet_> but it works.
18:14 < ahuillet_> comparing 0.000000 and -0.000000
18:14 < ahuillet_> grr
18:28 < ahuillet_> ok
18:28 < ahuillet_> floating point computations now working
18:33 -!- ahuillet_ [n=user@79.83.34.171] has quit ["Leaving"]
18:33 -!- ahuillet_ [n=user@171.34.83-79.rev.gaoland.net] has joined #jato
19:10 < vegard> hm. question.
19:10 < vegard> -Xtrace
19:10 < vegard> do we use this for all kinds of debug output?
19:11 < vegard> I have now a function that outputs the itable/imt after it has been derived
19:11 < vegard> also,
19:11 < vegard> can I put this in vm/itable.c ?
19:11 < vegard> this means we need vm/trace.c ?
21:41 < ahuillet_> penberg_home : ping
21:56 < vegard> from now on I'll not use interfaces in java again :)
21:56 < ahuillet_> why?
21:58 < vegard> because their implementation (in the jvm) is ridiculous :-)
21:59 < vegard> and there is apparently no way to do it in a sane way
21:59 < ahuillet_> ah
22:00 < ahuillet_> don't use floating point on Jato either ;)
22:00 < vegard> that said, it is probably more sensible to say I'll never use multiple inheritance in C++
22:00 < vegard> heh, ah, but that we can fix at least, no?
22:01 < vegard> and.. does it really work now?
22:02 < ahuillet_> as far as i can tell
22:02 < ahuillet_> the patches I sent to penberg even enable FloatArithmeticTest
22:02 < ahuillet_> only OP_FREM is missing now
22:03 < vegard> that's pretty cool :)
22:03 < vegard> and the conversions?
22:03 < vegard> sorry, conversion opcodes*
22:03 < vegard> hm. or both.
22:05 < ahuillet_> conversions.. mmh
22:05 < ahuillet_> I haven't done them, yet. if you need them, ping me
22:05 < ahuillet_> they're easy
22:06 < vegard> there was something... INT to BYTE?
22:06 < vegard> er, yeah, that's not floating-point, but still ;)
22:06 < ahuillet_> oh, that one
22:06 < ahuillet_> INT to CHAR it was
22:06 < vegard> yeah, it was
22:06 < vegard> FLOAT to INT as well
22:07 < ahuillet_> that one should be simple
22:07 < ahuillet_> the CHAR thing I'm leaving to you though
22:07 < vegard> and INT to FLOAT is missing
22:07 < vegard> aww
22:07 < ahuillet_> do you need them now?
22:07 < vegard> not _right_ now :)
22:07 < ahuillet_> when my movie's finished I can do the conversion things but I'd like some feedback from penberg about the other patches first
22:07 < vegard> but we need it for Hashtable (and hence for PrintTest)
22:07 < ahuillet_> vegard : you sure about that?
22:07 < vegard> oh, watch your movie :)
22:08 < ahuillet_> for now PrintTest crashes with a NullPointerException here
22:08 < vegard> it's not urgent. I'm stuck trying to implement INVOKEINTERFACE meanwhile, I expect that will take a bit of time
22:08 -!- tgrabiec [n=tomekg@biz178.neoplus.adsl.tpnet.pl] has joined #jato
22:09 < ahuillet_> any idea about the NULL pointer thing btw?
22:09 < vegard> tgrabiec: WELL DONE on the vtable bug... and so sorry :-/
22:09 < tgrabiec> vegard: it was a nightmare to debug ;)
22:10 < tgrabiec> i have ready patches that improve invoke debug
22:11 < tgrabiec> ahuillet_: what NULL pointer thing ?
22:12 < vegard> yeah, NullPointerException in PrintTest, I get it too
22:12 < vegard> seems to come from String.hashCode() (though I'm not 100% sure)
22:12 < vegard> (probably because the string object is null)
22:15 < vegard> oh it's Hashtable.put() actually, I think
22:16 < ahuillet_> oh.
22:16 < vegard> it's the last "mov" in the function, then two pops, and leave
22:19 < vegard> I don't know :) it's too late.
22:19 < ahuillet_> :]
22:19 < vegard> but the easiest thing is to run it in gdb
22:19 < vegard> because it stops at every SIGSEGV
22:20 < vegard> then inspect the instruction that trapped to check whether it was a static-field access (if it was, you can continnue execution)
22:20 < vegard> if it stops at a "test %r,(%r)" that means a NULL check
22:20 < vegard> and that something is null. and about to throw an exception :)
22:21 < ahuillet_> 0x97d29056:     mov    0x8c8d000,%ebx
22:21 < ahuillet_> ok, that one I could continue
22:21 < vegard> yes
22:22 < vegard> that one will trigger class initialisation
22:22 < ahuillet_> crash on a mov (%esi), %esi
22:22 < vegard> eh really?
22:22 < ahuillet_> in String.hashCode
22:24 < vegard> hm. well I posted one patch for static field handling
22:24 < vegard> that could make a difference
22:24 < ahuillet_> ah?
22:24 < vegard> but it's probably easier to wait until pekka merges everything ;)
22:25 < vegard> then I will have float supoprt too :D
22:25 < ahuillet_> yeah, don't look at the assembly we produce
22:25 < ahuillet_> things are pretty decent, except for the functions returning float where I'm raping the ABI
22:29 < ahuillet_> oh, and we move data back and forth between GPRs and XMM registers quite a lot
22:29 < ahuillet_> though I could not care less about it
22:29 < ahuillet_> anyway,nothing I can do on PrintTest then?
22:32 < tgrabiec> vegard: is there any reason that we can't do this optimization of EXPR_INSTANCE_FIELD code selection: http://pastebin.com/db3f5415 ?
22:32 < tgrabiec> if you don't have objectsions i will send a patch
22:33 < ahuillet_> tgrabiec : have you actually made the patch?
22:33 < tgrabiec> ahuillet_: yes
22:33 < ahuillet_> can you please show?
22:33 < tgrabiec> http://pastebin.com/d25e63a12
22:41 < ahuillet_> seems relatively harmless
22:42 < ahuillet_> I don't believe this is my code though so it's strange
22:42 < ahuillet_> (I mean, that you find incorrect or suboptimal things in code I wrote that implements things i consider "complex" is not surprising)
22:42 < ahuillet_> (a bit more so in penberg's code)
22:42 < ahuillet_> ("complex" is anything higher level than C)
22:47 < vegard> nice
22:48 < ahuillet_> (hence my reluctantness to implement unicode stuff, as I am going to get it wrong)
22:49 < tgrabiec> vegard: so can i put Acked-by: you ?
22:51 < tgrabiec> oh, it seems that it's Pekka's code
22:51 < tgrabiec> I will just send the patch
22:53 < vegard> I was trying to figure it out too but I couldn't make git blame follow the rename :)
22:57 < vegard> ah, commit dc97f18a88a2c8086f92ddd3ff1a788398a98f37
23:02 < ahuillet_>  state->reg1 = get_fpu_var(s->b_parent);
23:02 < ahuillet_>         select_insn(s, tree, reg_reg_insn(INSN_CONV_GPR_TO_FPU, state->left->reg1, state->reg1));
23:02 < ahuillet_> vegard : here's int -> float conversion. :)
23:03 < ahuillet_> float -> int is the same
23:04 < tgrabiec> ahuillet_, so, do you have float <-> int conversion patches ready ?
23:04 < ahuillet_> affirmative
23:04 < tgrabiec> can I have a free sample ?
23:05 < ahuillet_> writing regression tests
23:05 < ahuillet_> then I'll send to the ML
23:05 < tgrabiec> aha, ok
23:05 < ahuillet_> ETA 5mn if everything goes well
23:05 < tgrabiec> i hope this solves my problem with java/util/Hashtable.<init>()V
23:06 < ahuillet_> what is it?
23:06 < ahuillet_> you're gonna need to apply my two patch serious
23:06 < tgrabiec> i get failure in moboburg
23:06 < ahuillet_> *series
23:06 < ahuillet_> penberg hasn't merged it yet I believe
23:06 < ahuillet_> grrrr no implicit double -> float conversion
23:06 < ahuillet_> god do I hate java
23:07 < tgrabiec> i can see in JIT trace that this method has float -> int conversion hence i hope your patches will solve it
23:07 < ahuillet_> ./jvm/FloatArithmeticTest FAILED. Expected 0, but was: 1.
23:07 < ahuillet_> ETA 10mn. :)
23:08 < ahuillet_> fuck it, no way it works
23:08 < ahuillet_> same problem as for return
23:08 < ahuillet_> EXPR_CONVERSION(reg)
23:08 < ahuillet_> I need EXPR_CONVERSION(freg)
23:09 < ahuillet_> ah well, I hope the costs on the rules are enough to make monoburg take the right rule
23:09 < ahuillet_> but I really want conditional rules. :)
23:11 < ahuillet_> I don't know how mono guys could work with monoburg
23:11 < ahuillet_> it's poorly written *and* limited
23:11 < tgrabiec> agreed
23:12 < ahuillet_> conditional rules would be much easier
23:12 < ahuillet_> because here, I will have to add at least two instructions to HIR
23:12 < ahuillet_> and I'm not talking about doubles. :)
23:13 < ahuillet_> SSE1 doesn't know about double precision floating point values
23:16 < tgrabiec> btw, what do you think about colored output in some tracers, it would increase readability of some complex outputs (especially those which can output error information in the trace) ?
23:17 < ahuillet_> ANSI control characters? how do you plan on outputting them?
23:17 < ahuillet_> homemade technique or curses?
23:17 < ahuillet_> I don't need color myself really
23:18 < tgrabiec> i thought about plane excape sequences
23:18 < tgrabiec> *escape
23:18 < ahuillet_> well I don't know, I've to be convinced it brings much to readability
23:19 < tgrabiec> well, it is not nedded in most cases, but i have this complex invoke tracer now, which shows actual parameter values, and colors would increase readability
23:20 < tgrabiec> but i guess it's not quite important now
23:20 < ahuillet_> yeah, let's get println first
23:22 < ahuillet_> guys
23:22 < ahuillet_> it smells like monoburg rewrite
23:22 < ahuillet_> not this summer I'd say, but really
23:23 < ahuillet_> I have one more SoC on my apartment financing plan, maybe rewriting monoburg would be a good subject
23:41 < vegard> for 2010?
23:41 < ahuillet_> yup
23:41 < vegard> you should be a mentor!
23:41 < ahuillet_> starting in 2011. :)
23:42 < vegard> I think it would be great to have more mentors next year
23:42 < vegard> I will definitely apply again next year.
23:42 < ahuillet_> as a student?
23:42 < vegard> assuming jato is accepted as mentoring organization (though I don't doubt it)
23:42 < vegard> yes.
23:43 < ahuillet_> as far as I'm concerned it depends
23:43 < ahuillet_> I finish my studies in june 2010
23:43 < ahuillet_> so it depends when I start my full time job
23:43 < ahuillet_> if I manage to get one month off in the summer, I'll apply as a student
23:43 < vegard> honestly, I prefer this as a job to any other summer job, and being mentor doesn't really give that much money. so yes, it is definitely about the money.
23:43 < ahuillet_> if I don't, mentor
23:43 < ahuillet_> vegard : same here. :)
23:43 < ahuillet_> vegard : and it definitely rocks as a summer job, this is my fourth year I'm doing this and when I see my friends...
23:44 < vegard> fourth year?? wow
23:44 < ahuillet_> yesterday, the people I was with could not drink and had to go to bed early because they had to *go to work* at 9h
23:45 < ahuillet_> yeah, fourth year.. I'd have done it in 2005 but I was too young
23:45 < ahuillet_> you need to be 18 :)
23:45 < vegard> by the way, how old are you? I'm 21, I just finished second year of uni (university of oslo, studying informatics, formally it's "distributed systems and networks" but I actually enjoy computer languages and operating systems the most)
23:46 < ahuillet_> 21 as well, finished second year of engineer school (fourth year after high school)
23:46 < ahuillet_> and doing computer stuff obviously. :)
23:47 < vegard> ah, right. and you have been doing SoC for two tears already, wow.
23:47 < ahuillet_> three
23:47 < ahuillet_> 2006 with open security foundation
23:47 < ahuillet_> crap project but it paid
23:47 < ahuillet_> 2007 Nouveau XVideo support
23:47 < ahuillet_> paid by X.org, not Google though
23:47 < ahuillet_> 2008 Jato, 2009 Jato
23:47 < ahuillet_> 2010 Jato ? :)
23:48 < vegard> ah.
23:48 < vegard> so you really liked jato, then ;)
23:48 < ahuillet_> pretty much so
23:48 < ahuillet_> seriously, it's the best GSoC organization
23:48 < ahuillet_> I've seen enough of them, I know it :)
23:49 < vegard> well.. "organization", heh
23:49 < ahuillet_> that's the official name. :)
23:50 < ahuillet_> besides, I learnt a lot in Jato, about compilers and C programming
23:51 < vegard> it would be nice to have more mentors next year. I don't think pekka can handle more than four students on his own. not saying anything bad about him, I think four is already quite a feat!
23:51 < ahuillet_> definitely :)
23:51 < ahuillet_> though I don't intend on giving up on the money
23:52 < ahuillet_> ah, we'll see, I really can't tell right no
23:52 < ahuillet_> *now
23:52 < vegard> (and I'd like to see more students, because, also honestly, it really boosts the progress of the project SO much.)
23:52 < ahuillet_> yeah, but I'm not sure jato could take 10 students either
23:52 < vegard> yep, I understand it :-)
23:52 < ahuillet_> at some point we'd just mutex each other
23:52 < vegard> yes. hehe
23:52 < ahuillet_> pretty much like you and I did with cafebabe and FPU :)
23:53 < ahuillet_> imagine another guy rewriting monoburg, and one starting an optimizer and thus adding a linear architecture independant intermediate language
23:53 < vegard> oh, not just that. the out-of-tree development of the VM switch-out was pretty bad too.
23:53 < ahuillet_> (ok, that second thing would probably be overkill)
23:53 < ahuillet_> yeah, out-of-tree tends to be painful
23:53 < vegard> at some point I'd changed so much that almost _any_ change you did would make me have to rewrite it
23:54 < ahuillet_> 4 people is good, I am not sure we'd scale to say 6 or 8
23:54 < ahuillet_> Eduard (working on x86-64) is probably cursing me twice a day for only doing my patches for x86
23:54 < vegard> it was driving me a bit crazy. but it's really hard to do it any other way when you're rewriting something big (and you can't do it incrementally either, because it's broken for such a long time)
23:54 < vegard> yes!
23:55 < vegard> on the other hand, I think that if we can manage to produce a 1.0 (or was it 0.1? heh) by the end of the year, it will be easier to be more people too, simply because the code base is bigger.
23:56 < vegard> and it's harder to step on each other's toes.
23:56 < ahuillet_> yes, but I feel we'll have to do something about monoburg before it gets out of hand
23:56 < ahuillet_> if I have to add double precision support, the thing will double in size.
23:56  * vegard nods
23:57 < ahuillet_> we might need a bit of modularity (several files), conditions for rules, proper "no rule found" reports
23:57 < vegard> that's equivalent to the motivation of my this year's project :D
23:57 < ahuillet_> what was it?
23:58 < vegard> oh, replace jamvm before we grow too attached to it.
23:59 < vegard> I understand about monoburg. if you decide to rewrite it, you must emit #line lines
23:59 < ahuillet_> I'm not usually an advocate of rewriting things from scratch
23:59 < ahuillet_> as far as jamvm is concerned, it's beyond my abilities to judge whether it sucked or not
23:59 < vegard> I tried to change it, it was pretty hard ;)
23:59 < ahuillet_> but monoburg, man... :)
23:59 < vegard> (monoburg, that is)
--- Log closed Fri Jul 03 00:00:10 2009