Login  •  Register


The time is now: Wed Dec 19, 2018 3:49 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 71 of 82 [ 2038 posts ]    Go to page Previous  1 ... 68, 69, 70, 71, 72, 73, 74 ... 82  Next
Print view Previous topic  |  Next topic
Author Message
PostPosted: Sat Apr 29, 2017 11:18 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 242
After you run risu you will see output that is a bunch of numbers. These are encoded PowerPC instructions. To decode them, copy the numbers and view them on onlinedisassembler.com. After pushing the "Start Disassembling" button you will see a button on the left side labelled "Platform: i386". Push it and fill out the form with these values:

Arch: Powerpc:common
Base Address: 0x0
Endian: Big
Mode: 32
CPU: ppc32

Paste your number into the text area below the form. The first interpretation of the value will be wrong. This is a bug with the site. Simply select Little in the Endian field then select Big again. The displayed instructions will change to the right values.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Apr 30, 2017 4:17 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Alternatively, if you have access to Ida, it will happily detect PPC assembly and output it in readable form. I believe there are demo versions of Ida for Mac available as well from the Ida website.

Thanks for getting this pushed out, Programmingkid! I have limited time over the next few months, but I'll eventually have my G4s hooked up to the same network as my emulation Mac, and will run everything through its paces.

Out of curiosity, what is your current list of buggy instructions? We could compare this against the ppc asm of an audio program (or Quicktime) and see where the overlap is to prioritize reimplementation.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Apr 30, 2017 1:28 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 242
adespoton wrote:
Alternatively, if you have access to Ida, it will happily detect PPC assembly and output it in readable form. I believe there are demo versions of Ida for Mac available as well from the Ida website.

I couldn't find a free demo of IDA that would disassemble PowerPC code. If you find it, please share the link with us. It does look like a great tool.
adespoton wrote:
Thanks for getting this pushed out, Programmingkid! I have limited time over the next few months, but I'll eventually have my G4s hooked up to the same network as my emulation Mac, and will run everything through its paces.

Out of curiosity, what is your current list of buggy instructions? We could compare this against the ppc asm of an audio program (or Quicktime) and see where the overlap is to prioritize reimplementation.


We definitely need someone to look at the G4 emulation. I hope to do more thorough testing later in the week, but here is what I found so far as problem instructions:

- fdivs
- fctiw
- fdiv
- divw
- fctiwz
- fsub

The emulated FPSCR appears to be the major problem. It is a register that stores settings and indicates the status of certain floating point operations. I plan on making some C code that will print all out of the settings of the FPSCR. When I do I will post it here for others to use to help debug QEMU.

To everyone who wants to help, risu is easy enough for most QEMU users to handle. You don't have to be a programmer to use it. The complete listing of supported PowerPC instructions can be found in the ppc.risu file. It can help you decide which instructions you wish to test.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Apr 30, 2017 4:26 pm 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 142
Programmingkid wrote:
adespoton wrote:
Alternatively, if you have access to Ida, it will happily detect PPC assembly and output it in readable form. I believe there are demo versions of Ida for Mac available as well from the Ida website.

I couldn't find a free demo of IDA that would disassemble PowerPC code. If you find it, please share the link with us. It does look like a great tool.
adespoton wrote:
Thanks for getting this pushed out, Programmingkid! I have limited time over the next few months, but I'll eventually have my G4s hooked up to the same network as my emulation Mac, and will run everything through its paces.

Out of curiosity, what is your current list of buggy instructions? We could compare this against the ppc asm of an audio program (or Quicktime) and see where the overlap is to prioritize reimplementation.


We definitely need someone to look at the G4 emulation. I hope to do more thorough testing later in the week, but here is what I found so far as problem instructions:

- fdivs
- fctiw
- fdiv
- divw
- fctiwz
- fsub

The emulated FPSCR appears to be the major problem. It is a register that stores settings and indicates the status of certain floating point operations. I plan on making some C code that will print all out of the settings of the FPSCR. When I do I will post it here for others to use to help debug QEMU.

To everyone who wants to help, risu is easy enough for most QEMU users to handle. You don't have to be a programmer to use it. The complete listing of supported PowerPC instructions can be found in the ppc.risu file. It can help you decide which instructions you wish to test.


Good work, Qemu's PPC emulation is about 1/2 to 1/3 of SS on my system and Altivec is about 1/10 of SS, and SS is nowhere near the performance of Apple's Rosetta.

If we could get CPU emulation up near what Rosetta can do, that would be nice, tho I don't think QemuPPC has a JIT.

I've put my Voodoo emulation on hold, until I get a motherboard that supports IOMMU( VT-d ). I'm having trouble getting the 3dfx drivers to load, under OS 9, so I need to plug in a real Voodoo cards and figure out what I'm doing wrong.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Apr 30, 2017 7:10 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 242
darthnvader wrote:
Good work, Qemu's PPC emulation is about 1/2 to 1/3 of SS on my system and Altivec is about 1/10 of SS, and SS is nowhere near the performance of Apple's Rosetta.

Sheepshaver sound like the superior technology. I think it has a two stage translation system: PPC -> x86. QEMU has a three stage system: PPC -> TCG -> x86. The extra stage is definitely going to slow down things.

darthnvader wrote:
If we could get CPU emulation up near what Rosetta can do, that would be nice, tho I don't think QemuPPC has a JIT.

It does. It is called Tiny Code Generator (TCG). I do wish someone would replace it with something that translates PPC to x86 without any extra stages.

darthnvader wrote:
I've put my Voodoo emulation on hold, until I get a motherboard that supports IOMMU( VT-d ). I'm having trouble getting the 3dfx drivers to load, under OS 9, so I need to plug in a real Voodoo cards and figure out what I'm doing wrong.

I wonder now if there is an easier way. A large amount of games support OpenGL. What if we implemented a video card that just used OpenGL? We would need to make guest OS drivers for it. I think with all the documentation and code we would have access to, making an OpenGL card might be much easier than implementing a real proprietary card. We would be spared the pain of reverse engineering hardware and closed source drivers. Does this sound feasible?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Apr 30, 2017 8:52 pm 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 142
Programmingkid wrote:
darthnvader wrote:
Good work, Qemu's PPC emulation is about 1/2 to 1/3 of SS on my system and Altivec is about 1/10 of SS, and SS is nowhere near the performance of Apple's Rosetta.

Sheepshaver sound like the superior technology. I think it has a two stage translation system: PPC -> x86. QEMU has a three stage system: PPC -> TCG -> x86. The extra stage is definitely going to slow down things.

darthnvader wrote:
If we could get CPU emulation up near what Rosetta can do, that would be nice, tho I don't think QemuPPC has a JIT.

It does. It is called Tiny Code Generator (TCG). I do wish someone would replace it with something that translates PPC to x86 without any extra stages.

darthnvader wrote:
I've put my Voodoo emulation on hold, until I get a motherboard that supports IOMMU( VT-d ). I'm having trouble getting the 3dfx drivers to load, under OS 9, so I need to plug in a real Voodoo cards and figure out what I'm doing wrong.

I wonder now if there is an easier way. A large amount of games support OpenGL. What if we implemented a video card that just used OpenGL? We would need to make guest OS drivers for it. I think with all the documentation and code we would have access to, making an OpenGL card might be much easier than implementing a real proprietary card. We would be spared the pain of reverse engineering hardware and closed source drivers. Does this sound feasible?


There's the Gallium3D project, and Virgil 3d project that already works with Qemu. The trouble is I don't know how to write drivers for OS 9, I've read through the old documentation, but it's all over my head. I've ported a few Linux pci device drivers to OS X, and even wrote my own driver for nVidia cards, to change the clock rates, control the TV Out, and report some values of the pci registers.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon May 01, 2017 7:27 am 
Offline
Tinkerer

Joined: Thu Aug 14, 2008 9:05 am
Posts: 96
Programmingkid wrote:
darthnvader wrote:
Good work, Qemu's PPC emulation is about 1/2 to 1/3 of SS on my system and Altivec is about 1/10 of SS, and SS is nowhere near the performance of Apple's Rosetta.

Sheepshaver sound like the superior technology. I think it has a two stage translation system: PPC -> x86. QEMU has a three stage system: PPC -> TCG -> x86. The extra stage is definitely going to slow down things.

Well, that depends on your definition of "superior." SheepShaver has more bugs than a summer's day in Minnesota, and is more crash-prone than a Formula One racer on meth. But it is fast.

I for one am content to have a slower emulator, if it is reliable.

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 03, 2017 8:35 am 
Offline
Mac Mechanic
User avatar

Joined: Tue Mar 29, 2011 8:57 pm
Posts: 184
Location: London, UK
CharlesS wrote:
Well, that depends on your definition of "superior." SheepShaver has more bugs than a summer's day in Minnesota, and is more crash-prone than a Formula One racer on meth. But it is fast.

I for one am content to have a slower emulator, if it is reliable.


Great metaphors/puns! :mrgreen:


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 03, 2017 9:44 am 
Offline
Apple Corer

Joined: Wed Apr 10, 2013 9:32 am
Posts: 254
I don't like all these rating possibilities on the net. But for comments like CharlesS' we should introduce the possibility to up vote a post :-)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 03, 2017 4:50 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Indeed: SheepShaver is the experimental track-only emulator, where qemu is more like a tank: slow, but it can go pretty much everywhere. Neither are quite ready for a regular commute.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 03, 2017 8:39 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4446
Location: Sittard, The Netherlands
Quote:
It does. It is called Tiny Code Generator (TCG). I do wish someone would replace it with something that translates PPC to x86 without any extra stages.


That tiny code generator is the successor of the now problematic jit that is included in SheepShaver. Qemu used to use the same jit. That's why at one point I contacted one of the tgc developers to get some insights into how to adapt sheepshaver to the tgc. But the answer was way over my head...

A better speed comparison could be made by looking at SheepShaver performance with the jit disabled.

It looks like enabling a multi threaded tcg for 32 bit ppc is considered for the future. The 64 bit ppc version is currently available.

We'll see what speed improvements that brings.

Best,
Cat_7


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu May 04, 2017 2:20 am 
Offline
Tinkerer

Joined: Thu Aug 14, 2008 9:05 am
Posts: 96
adespoton wrote:
Indeed: SheepShaver is the experimental track-only emulator, where qemu is more like a tank: slow, but it can go pretty much everywhere. Neither are quite ready for a regular commute.

Actually, SheepShaver is more like a skateboard with a rocket from the ACME corporation strapped to it. If it works, you'll go really fast, but it's more likely to either blow up, go the wrong direction, slam you into a rock wall, swerve into a lake, cause you to fall off a cliff, or fail in some other crazy way that only Chuck Jones could come up with.

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu May 04, 2017 6:39 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Ah; so it's the hoverboard of emulators ;)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun May 07, 2017 9:58 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 242
I made a program that tests various floating point instructions. Just double clicking on the "fpscr test" program is all it takes to make it work. The program indicated that most of the floating point instructions in qemu-system-ppc are not correctly implemented. If you want to try testing it I would suggest using Mac OS 10.4 as a guest operating system. The source code is included.

http://www.mediafire.com/file/6j9tqubvk ... rogram.zip

When I ran the program I saw 18 failures. :sad:


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon May 08, 2017 6:29 am 
Offline
Student Driver

Joined: Thu Dec 02, 2010 5:50 pm
Posts: 18
Location: Austria
Floating-point math is probably the most tricky part of CPU/FPU emulation. I have spent lots of time improving 68k FPU emulation to a point where one expect to get "99% correct results" recently. I don't know how QEMU emulates floats (native or software floating point library?). Using any native floats will lead to different results on different platforms, which is definitely bad behavior for an emulator. I decided to use SoftFloat as a base for FPU emulation. But I had to modify it heavily to generate the same results as a real 68k does (even though the 68k is IEEE compliant!).
The main problem is handling of edge cases and exceptions. I also had to extend SoftFloat with additional functions (FSCALE, FMOD, FSIN, FLOGN, ...), but I think that won't be an issue emulating a RISC processor.
I think (it is really just a guess) your problems might derive from the emulator not generating traps if certain exceptions occur. The RISC design might make use of those exceptions to implement missing features, like handling of NaN and infinity, in software (for example the i860 RISC processor does that).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue May 09, 2017 3:42 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 242
andreas_g wrote:
Floating-point math is probably the most tricky part of CPU/FPU emulation. I have spent lots of time improving 68k FPU emulation to a point where one expect to get "99% correct results" recently. I don't know how QEMU emulates floats (native or software floating point library?). Using any native floats will lead to different results on different platforms, which is definitely bad behavior for an emulator. I decided to use SoftFloat as a base for FPU emulation. But I had to modify it heavily to generate the same results as a real 68k does (even though the 68k is IEEE compliant!).
The main problem is handling of edge cases and exceptions. I also had to extend SoftFloat with additional functions (FSCALE, FMOD, FSIN, FLOGN, ...), but I think that won't be an issue emulating a RISC processor.
I think (it is really just a guess) your problems might derive from the emulator not generating traps if certain exceptions occur. The RISC design might make use of those exceptions to implement missing features, like handling of NaN and infinity, in software (for example the i860 RISC processor does that).


Your work sounds impressive. Which emulator do you work on?

QEMU uses a softfloat implementation. I have dreamed about implementing an x87 (x86 floating point unit) backend.

Interesting fact Rosetta actually has an even worse PowerPC floating point implementation than QEMU. 23 tests failed for Rosetta compared to QEMU's 18 failures.

The testing has shown that the PowerPC floating point status and control register is not correctly implemented. All of the calculations done in the tests are correct.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 10, 2017 6:38 am 
Offline
Student Driver

Joined: Thu Dec 02, 2010 5:50 pm
Posts: 18
Location: Austria
I am working on Previous (NeXT Computer emulator). My FPU improvements have only been possible with the help of Toni Wilen (WinUAE), who tested lots of instructions on his machines. Documentation of the 68k is not clear about many details.
If QEMU uses SoftFloat then there is a good chance to be able to implement the missing things. The only problem will be that SoftFloat is also used to emulate other platforms which is likely to cause conflicts when one changes SoftFloat's behavior to be PPC specific. That is the cause why a dedicated emulator is always superior to an emulation system like QEMU or MESS when it comes to compatibility and precision (and maintainability).
It is certainly possible to get the information necessary for correct status register implementation out of SoftFloat. Btw, I quickly checked PPC 601 data sheet and it seems to handle special cases, like NaN and infinity, all in hardware. But one would need to extend SoftFloat with some instructions, like fused multiply-add, if not already done.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 10, 2017 7:50 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4446
Location: Sittard, The Netherlands
Here is some discussion about the future of softfloat in Qemu.

http://lists.nongnu.org/archive/html/qe ... 01730.html

Best,
Cat_7


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed May 10, 2017 9:11 am 
Offline
Student Driver

Joined: Thu Dec 02, 2010 5:50 pm
Posts: 18
Location: Austria
Interesting discussion, thank you for the link. If I were them and if the only issue they have with SoftFloat 2 is missing half precision, then I'd recommend to just write an own implementation of 16 bit floats. Using single precision as a template it should not be too difficult. If they need it for ARM emulation they have to customize it anyway (obviously ARM uses no or a different NaN and infinity encoding). Porting everything to SoftFloat 3 is definitely no easy task and much harder then just implementing half precision.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue May 16, 2017 6:02 pm 
Offline
Tinkerer

Joined: Thu Aug 14, 2008 9:05 am
Posts: 96
andreas_g wrote:
If QEMU uses SoftFloat then there is a good chance to be able to implement the missing things. The only problem will be that SoftFloat is also used to emulate other platforms which is likely to cause conflicts when one changes SoftFloat's behavior to be PPC specific. That is the cause why a dedicated emulator is always superior to an emulation system like QEMU or MESS when it comes to compatibility and precision (and maintainability).

Don't you think that's a strong statement to make, given that every dedicated emulator we have for every Mac machine other than the original 68000-based models is far inferior to QEMU and MESS in all three of those categories, despite most of them being far more mature?

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu May 18, 2017 5:58 am 
Offline
Student Driver

Joined: Thu Dec 02, 2010 5:50 pm
Posts: 18
Location: Austria
CharlesS wrote:
Don't you think that's a strong statement to make, given that every dedicated emulator we have for every Mac machine other than the original 68000-based models is far inferior to QEMU and MESS in all three of those categories, despite most of them being far more mature?

Explaining this is simple. There has been no development on PearPC or SheepShaver for years, while QEMU is improving continuously.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu May 18, 2017 2:24 pm 
Offline
Tinkerer

Joined: Thu Aug 14, 2008 9:05 am
Posts: 96
SheepShaver and Basilisk were worked on for many, many years longer than QEMU's Mac guest has been, and it's not as if it suddenly became less accurate when work stopped on it. Part of why the work did stop, in addition, was because SheepShaver was/is a maintainability nightmare. QEMU has very quickly surpassed it in a very short amount of time, which speaks to its quality IMO.

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu May 18, 2017 5:51 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
The architecture of qemu (and MESS for that matter) also forces developers to use best practices, as changes they make to make one thing work could affect something else as well.

So SheepShaver has a lot of single-product custom performance tweaks (kind of like snes9x) to make it run fast in situations people have commonly encountered, and there are a lot of logic patches to make it behave the way people want. The down side of that is that it's a mess from an architectual and maintenance perspective, and a single change in host hardware or compiler can cause the entire structure to fail in a manner that is difficult to discover.

Qemu on the other hand has a general core that is shared between multiple sets of emulation logic, so no shortcuts can be taken in one set of code to make some unrelated feature work properly/quickly. This means that changes to the code are much more thoroughly understood and vetted, resulting in a higher quality product.

The down-side of course is that there are specific structures that must be adhered to, which prevents quick hack features and performance optimizations, which can make it seem slower or less feature-complete compared to other software, for a limited set of host configurations.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri May 19, 2017 5:52 am 
Offline
Student Driver

Joined: Thu Dec 02, 2010 5:50 pm
Posts: 18
Location: Austria
That SheepShaver is a mess is not caused by it being a dedicated emulator. One could also make MESS a mess and it still would work and one could also make SheepShaver a best practice programming example. Connecting bad coding style and dedicated emulators is illegitimate.

An example: Let's say we want to implement 68k emulation into QEMU. At some point we need to add correct FPU emulation. We then notice that the extended precision floating-point format of the 68k does not match the one in SoftFloat, which is identical to x87. So we need to change that ... lots of quite complicated changes and pre-processor switches in almost every function necessary. Some functions need to be duplicated and totally re-written. Some functions need to be added because they are missing. Then at some point we notice that for emulating arithmetic exceptions we need to get internal intermediate values from SoftFloat. Therefore we need to customize SoftFloat even further to get those intermediate values as an output. Again more pre-processor switches for not breaking other platforms causing more mess. This requires to be extremely careful to not break other platforms. So finally we are done. But then ... the lead of the project comes to the conclusion that everything needs to be switched from SoftFloat 2 to SoftFloat 3, because it better suits some more common platform. Back to the start.

I don't want to spam this thread with this off-topic discussion any further. But I hope the example explains my opinion.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri May 19, 2017 7:52 am 
Offline
Tinkerer

Joined: Thu Aug 14, 2008 9:05 am
Posts: 96
andreas_g wrote:
That SheepShaver is a mess is not caused by it being a dedicated emulator. One could also make MESS a mess and it still would work and one could also make SheepShaver a best practice programming example. Connecting bad coding style and dedicated emulators is illegitimate.

I guess the main thing I was objecting to was the statement that a dedicated emulator is *always* superior, when there are other factors which are far more important, IMO, than whether an emulator is dedicated or not (especially when, as adespoton points out, shortcuts of the sort used by SheepShaver and Basilisk are far less likely to be practical in a system like MESS).

Anyway, I'm extremely grateful for the amazing work being done on QEMU-PPC right now, which seems to be working toward something far better than any dedicated emulator we have. Hats off to all of the developers that have been working on this. :)

_________________
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 71 of 82 [ 2038 posts ]    Go to page Previous  1 ... 68, 69, 70, 71, 72, 73, 74 ... 82  Next


Who is online

Users browsing this forum: Bing [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group