Discussion:
[Pearpc-devel] Progress of Atlhon64 support
Ryan Hennessee
2005-10-19 00:51:08 UTC
Permalink
I was just wondering what progress was being made in porting PearPC to the x64. Has anyone undertaken the task of re-writing the JITC to x64 or is that even pratical?. I've upgraded to a Athlon 64 Venice core processor and was just curious. Thanks

Ryan Hennessee


---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
Jens von der Heydt
2005-10-19 07:43:56 UTC
Permalink
Post by Ryan Hennessee
I was just wondering what progress was being made in porting PearPC
to the x64. Has anyone undertaken the task of re-writing the JITC
to x64 or is that even pratical?. I've upgraded to a Athlon 64
Venice core processor and was just curious. Thanks
Ryan Hennessee
Ryan, as far as I know, nobody is working on that task at the moment.
I wanted to start but am yet to actually buy an AMD64 :)

Jens
Ryan Hennessee
2005-10-19 09:25:54 UTC
Permalink
Post by Jens von der Heydt
I was just wondering what progress was being made in porting PearPC to the x64. Has >>anyone undertaken the task of re-writing the JITC to x64 or is that even pratical?. I've >>upgraded to a Athlon 64 Venice core processor and was just curious. Thanks
Ryan Hennessee
Ryan, as far as I know, nobody is working on that task at the moment.
I wanted to start but am yet to actually buy an AMD64 :)
Jens
Thanks, would there be any advantage to a 64-bit Pearpc. Would it be possible to do G5 emulation with the Athlon 64 and a 64-bit JITC?



---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
j***@giantblob.com
2005-10-19 10:16:05 UTC
Permalink
Post by Jens von der Heydt
Post by Ryan Hennessee
I was just wondering what progress was being made in porting PearPC
to the x64. Has >>anyone undertaken the task of re-writing the JITC
to x64 or is that even pratical?. I've >>upgraded to a Athlon 64
Venice core processor and was just curious. Thanks
Post by Jens von der Heydt
Post by Ryan Hennessee
Ryan Hennessee
Ryan, as far as I know, nobody is working on that task at the moment.
I wanted to start but am yet to actually buy an AMD64 :)
Jens
Thanks, would there be any advantage to a 64-bit Pearpc. Would it be
possible to do G5 emulation with the Athlon 64 and a 64-bit JITC?
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.

Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.

FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.

-- jeek
------------------------------------------------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/>
Daniel Foesch
2005-10-19 15:50:00 UTC
Permalink
Post by j***@giantblob.com
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.
Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.
FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.
Yeah, it's fun, ne? You shouldn't give up though, this is where I
learned some of my best debugging techniques. While everyone else is
running around with debuggers and using tools, I know solid
techniques, and can debug code just from reading it.

I very rarely have use for a debugging program anymore. People at
Microsoft sometimes tell me to break out the perl debugger to see what
the code is doing, and I'm like, "I know what the code is doing. It's
right there for me to read."

If you get good at debugging a JITC compiler, then you'll be good at
debugging just about anything.

--
Daniel Foesch
j***@giantblob.com
2005-10-19 19:21:51 UTC
Permalink
Post by Daniel Foesch
Post by j***@giantblob.com
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.
Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.
FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.
Yeah, it's fun, ne? You shouldn't give up though, this is where I
learned some of my best debugging techniques. While everyone else is
running around with debuggers and using tools, I know solid
techniques, and can debug code just from reading it.
Fair enough, but you're reading the code at one level removed when
debugging the JIT! I'm used to debugging code generators where I can
read the assembler output side by side with the source and/or
intermediate code in order to spot discrepencies - when debugging the
JITed code from PearPC, I have no source to compare it with - just a
segfault thousands of instructions from the actual error :-(

Do you have any specific techniques for debugging the JITter? Do you
write specific PowerPC test cases etc. or you you rely on MacOS exposing
JIT bugs?
Post by Daniel Foesch
I very rarely have use for a debugging program anymore. People at
Microsoft sometimes tell me to break out the perl debugger to see what
the code is doing, and I'm like, "I know what the code is doing. It's
right there for me to read."
To be honest I seldom use a debugger either - people at work think I'm
some kind of Luddite - but I find using a debugger leads to a
potentially endless cycle of ill thought out alterations whereas a
rigorous re-reading of the code produces better results, plus improving
one's understanding of the code is always good.
Post by Daniel Foesch
If you get good at debugging a JITC compiler, then you'll be good at
debugging just about anything.
I can see that. Unfortunately I've not had the time to look at it
recently - in the middle of big project at work plus also have exams :-(
Hopefully I'll have another shot next month.

-- jeek
Post by Daniel Foesch
--
Daniel Foesch
-------------------------------------------------------
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Daniel Foesch
2005-10-20 04:45:47 UTC
Permalink
Post by j***@giantblob.com
Post by Daniel Foesch
Post by j***@giantblob.com
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.
Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.
FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.
Yeah, it's fun, ne? You shouldn't give up though, this is where I
learned some of my best debugging techniques. While everyone else is
running around with debuggers and using tools, I know solid
techniques, and can debug code just from reading it.
Fair enough, but you're reading the code at one level removed when
debugging the JIT! I'm used to debugging code generators where I can
read the assembler output side by side with the source and/or
intermediate code in order to spot discrepencies - when debugging the
JITed code from PearPC, I have no source to compare it with - just a
segfault thousands of instructions from the actual error :-(
Yeah, imagine how it was with me. Very few of my AltiVec changes ever
segfaulted anything. They just draw stuff weird. So I don't even
have any sort of baseline of where to look, or what functions to look
at.

Since establishing a good implementation, I've not had problems just
vectorizing it, because if I hit any graphical gliches, I was able to
always revert functions until it worked correctly, then eventually
narrow the code down to a single function.
Post by j***@giantblob.com
Do you have any specific techniques for debugging the JITter? Do you
write specific PowerPC test cases etc. or you you rely on MacOS exposing
JIT bugs?
I generally rely on MacOS exposing the JITC bugs. It's a poor choice,
but it's about all that can be done. Actually, I also implemented an
AltiVec test suite that would generate C test cases that would allow
me to test AltiVec functions. It did help narrow down many of the
bugs that were in the generic code path.
Post by j***@giantblob.com
Post by Daniel Foesch
I very rarely have use for a debugging program anymore. People at
Microsoft sometimes tell me to break out the perl debugger to see what
the code is doing, and I'm like, "I know what the code is doing. It's
right there for me to read."
To be honest I seldom use a debugger either - people at work think I'm
some kind of Luddite - but I find using a debugger leads to a
potentially endless cycle of ill thought out alterations whereas a
rigorous re-reading of the code produces better results, plus improving
one's understanding of the code is always good.
I don't know if I have any notions like that, but I certainly don't
find much use for debuggers most of the time anymore. I've used them
occationally when I have a random segfault, and the program isn't
generating output, so where is the segfault? Gotta find it somehow.
So, I compile up the program with debugging support, start up the
debugger, start the program then when it segfaults, I know where it
segfaulted at.

This was done a couple times with PearPC, I believe, or maybe some
other emulator. But yeah, sometimes there's just a ridiculous amount
of codepath to cover, and you don't know where to start. In that
case, debuggers work for me.

At work, people keep telling me to "use the debugger and find out what
the problem is." I'm usually like, "uh, I already know where the
problem is. I read the code." Or something like that.

Back in my days of DOS programming, I had programs that couldn't be
attached to a debugger. Mainly because they took over the video
display, and the keyboard driver, and thus, there was no way to give
keyboard control back so that it could be debugged. I also installed
timer interrupts that got generated often, and had to be handled, and
breaking execution in order to look at these things would cause too
many interrupts per screen, and would screw things up.

Basically, I've programmed and debugged so long without one that
debuggers are mostly useless to me, as long as I can get deterministic
output from the program. If it's some closed source black-box, then
I'm stuck... which frustrates me about Windows itself to no end. ;)
Post by j***@giantblob.com
Post by Daniel Foesch
If you get good at debugging a JITC compiler, then you'll be good at
debugging just about anything.
I can see that. Unfortunately I've not had the time to look at it
recently - in the middle of big project at work plus also have exams :-(
Hopefully I'll have another shot next month.
No problem man; just remember, working on PearPC got me my job at
Microsoft. It got me on the map (actually, it got Sebastian on the
map, who pointed them to me. It's like being the suburb of a big
city, heh)

So, don't let anyone tell you that contributing to Open Source doesn't
pay. It develops skills exposes your talents, and generally over all
is good for your teeth. (I made that last one up.)

--
Daniel Foesch
Jens von der Heydt
2005-10-20 05:49:37 UTC
Permalink
Post by j***@giantblob.com
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.
Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.
FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.
So, back on topic:

Entering the 64 bit space wouldn't just speed things up but (tm), it
would
also present some / many more bottlenecks or emulation tasks that we
had to handle
if we emulated a G5 cpu.

I think one of the biggest benefits in going jitc-64 would be to
rewrite the memory mapping
so that it would work on native AMD-64 but we would leave the
emulation in it's G4 state.
We could use those additional GPRs of the AMD64 and even (on newest
AMDs) SSE2/3.

But this whole thing, compared to a working hw-mmu, is just peanuts,
I think.

Jens

j***@giantblob.com
2005-10-19 10:13:53 UTC
Permalink
Post by Jens von der Heydt
Post by Ryan Hennessee
I was just wondering what progress was being made in porting PearPC
to the x64. Has >>anyone undertaken the task of re-writing the JITC
to x64 or is that even pratical?. I've >>upgraded to a Athlon 64
Venice core processor and was just curious. Thanks
Post by Jens von der Heydt
Post by Ryan Hennessee
Ryan Hennessee
Ryan, as far as I know, nobody is working on that task at the moment.
I wanted to start but am yet to actually buy an AMD64 :)
Jens
Thanks, would there be any advantage to a 64-bit Pearpc. Would it be
possible to do G5 emulation with the Athlon 64 and a 64-bit JITC?
Having more registers would help.
Also, being able to map the entire 32bit target address space within the
64bit host application would simplify memory management enormously.

Emulating a 64 bit G5 would negate the address space advantage for
little gain in my opinion.

FWIW I had a look at trying to port the JITC to AMD64 on linux but I
didn't get far as it's almost impossible to debug the generated code.

-- jeek
------------------------------------------------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/>
Daniel Foesch
2005-10-19 15:47:12 UTC
Permalink
Post by Ryan Hennessee
Thanks, would there be any advantage to a 64-bit Pearpc. Would it be
possible to do G5 emulation with the Athlon 64 and a 64-bit JITC?
It's possible to do G5 emulation in 16-bit DOS, just you're going to
take a speed hit from it. Same with 32-bit Windows or Linux.

The x86 and just about every processor that I've ever known of has
facilties to perform arbitrary length math. Through things like
chaining ADC (add with carry), multiplication and division are a
different story however, but it's still there. Thus 64-bit math is
"easy", and there's nothing about the 64-bit nature of the G5 that
causes it not to be emulated yet.

It's just another extention to the PowerPC architecture that we've not
written up yet.

--
Daniel Foesch
Loading...