new vex on the way

Discussion:

new vex on the way

Eric Auge

2005-11-08 08:08:08 UTC

Hello,

FYI VEX seems to be on the "good" way, still some issue in
m_translate.c and some other places, but they doesn't
look like big blocking issues :)

I was unable to finish yesterday night,
I hope to finish tonight.

see ya guys,
Regards,

Eric

NB:
01:23AM <hsaliak> eh run_innerloop is pushing registers into stack
01:24AM <hsaliak> doh nevermidn
01:25AM <hsaliak> l8r
01:25AM <hsaliak> we should discuss on ML more
<spoty> yes
<spoty> run_innerloop is pusshin register on the stack
<spoty> because that's what require VEX
<spoty> it is doing the VEX exec environnement setup
<spoty> iirc

Kailash Sethuraman

2005-11-08 09:14:20 UTC

Permalink

Sweet, looking forward to see it, I made new commits yesterday, with
debugging info added in. Helps us know how far we have got and where
exactly the error is, as development is not consistently going on at
the moment. when you commit vex, please do ensure that the changes
dont back out each other.
Looking forward to the new vex :)
Hopefully that will fix our problems.
I was debugging run_innerloop asm before I slept off at some point.
Regards,
Kailash

Post by Eric Auge
Hello,
FYI VEX seems to be on the "good" way, still some issue in
m_translate.c and some other places, but they doesn't
look like big blocking issues :)
I was unable to finish yesterday night,
I hope to finish tonight.
see ya guys,
Regards,
Eric
01:23AM <hsaliak> eh run_innerloop is pushing registers into stack
01:24AM <hsaliak> doh nevermidn
01:25AM <hsaliak> l8r
01:25AM <hsaliak> we should discuss on ML more
<spoty> yes
<spoty> run_innerloop is pusshin register on the stack
<spoty> because that's what require VEX
<spoty> it is doing the VEX exec environnement setup
<spoty> iirc
_______________________________________________
Vg4nbsd-devel mailing list
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel

Eric Auge

2005-11-08 09:26:08 UTC

Permalink

Post by Kailash Sethuraman
Sweet, looking forward to see it, I made new commits yesterday, with
debugging info added in. Helps us know how far we have got and where
exactly the error is, as development is not consistently going on at
the moment. when you commit vex, please do ensure that the changes
dont back out each other.

"dont back out each other" sorry my weak english don't understand.

Post by Kailash Sethuraman
Looking forward to the new vex :)

heheh hopefully it will work.

Post by Kailash Sethuraman
Hopefully that will fix our problems.
I was debugging run_innerloop asm before I slept off at some point.

I hope you will reach the same point I reached sometime ago
first the call *$ecx and then discovering that it is within
VEX generated code...

The problem here is the VEX generated code is not _obvious_ (i mean
it's hard already when it's obvious :) to debug, at least to me :)

we will succeed making a hello_world that return 0; only run through valgrind :)

Regards,
Eric.

Post by Kailash Sethuraman
Regards,
Kailash

Kailash Sethuraman

2005-11-08 10:43:30 UTC

Permalink

As in when you make changes, if there are conflicts, make sure that my
change is not nuked. I think i did do some changes to m_translate.c .
Yes I am almost there at *$ecx, i have not seen that chunk of ASM code
yet. Though, will debug tonight.
I think we are pretty close, it might just be that the asm code is not
entirely Netbsd compat. lets see.

Post by Eric Auge

"dont back out each other" sorry my weak english don't understand.

Post by Kailash Sethuraman
Looking forward to the new vex :)

heheh hopefully it will work.

Post by Kailash Sethuraman
Hopefully that will fix our problems.
I was debugging run_innerloop asm before I slept off at some point.

I hope you will reach the same point I reached sometime ago
first the call *$ecx and then discovering that it is within
VEX generated code...
The problem here is the VEX generated code is not _obvious_ (i mean
it's hard already when it's obvious :) to debug, at least to me :)
we will succeed making a hello_world that return 0; only run through valgrind :)
Regards,
Eric.

Post by Kailash Sethuraman
Regards,
Kailash

_______________________________________________
Vg4nbsd-devel mailing list
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel

Eric Auge

2005-11-08 12:29:40 UTC

Permalink

Since the control is transfered to VEX right after,
it is difficult to see except by activating internal
valgrind debug instrumentation, this way you'll have more assertion
on VEX generated code and more sanity checks activated.

I don't know all but i've found some assertion on
VEX generated code this way.

Post by Kailash Sethuraman
As in when you make changes, if there are conflicts, make sure that my
change is not nuked. I think i did do some changes to m_translate.c .
Yes I am almost there at *$ecx, i have not seen that chunk of ASM code
yet. Though, will debug tonight.
I think we are pretty close, it might just be that the asm code is not
entirely Netbsd compat. lets see.

Post by Eric Auge

"dont back out each other" sorry my weak english don't understand.

Post by Kailash Sethuraman
Looking forward to the new vex :)

heheh hopefully it will work.

Post by Kailash Sethuraman
Hopefully that will fix our problems.
I was debugging run_innerloop asm before I slept off at some point.

I hope you will reach the same point I reached sometime ago
first the call *$ecx and then discovering that it is within
VEX generated code...
The problem here is the VEX generated code is not _obvious_ (i mean
it's hard already when it's obvious :) to debug, at least to me :)
we will succeed making a hello_world that return 0; only run through valgrind :)
Regards,
Eric.

Post by Kailash Sethuraman
Regards,
Kailash

_______________________________________________
Vg4nbsd-devel mailing list
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel