Thread: [Algorithms] Threading by software emulation
Brought to you by:
vexxed72
From: Sebastian L. <del...@gm...> - 2008-05-18 01:33:56
|
Hi guys, I'm working in a ps2 emulator for educational purposes only. I could run some demos but when the demos tried to create a thread it all hangs out... that's because I didn't write any thread module xD So, how can I emulate threads without making them natives? I mean, the theory behind. Maybe this is not a big deal for you guys but I'm really stuck. Regards, -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Anders N. <ja...@an...> - 2008-05-18 19:01:03
|
Well threads is just one more thing to emulate. Say your standard emulation code is like this State state; // this could by registers, ports etc... emulation state Operations ops; // instruction pointer while (!ops.empty()) { op=ops.next(); emulate(op, ops, state); // might be a jump so needs the ops-object as well } Say this is your emulator. Now when threading comes into the picture you have to emulate several threads at the same time. On a modern computer there is some kind of manager that decides when to switch threads. When a switch occur some state is replaced and exchanged for a thread-specific-state. This probably means registers but perhaps not state of vga-port etc. Now you have to figure out how many operations you have to run for each thread. SharedState ss; PrivateState ps[numThreads]; // One per thread Operations ops[numThreads]; // One per thread while (true) { // needs some kind of termination... threadID, numOps=scheduler.next(); // next thread to process, restart when it comes to the end for (i=1..numOps) { if (ops[threadID].empty()) { scheduler.killThread(threadID); break; } op=ops[threadID].next(); emulate(op, ops[threadID], ss, ps[threadID]); } } Something like that! Now how many ops per thread and time slice depends on a lot on hardware dependant factors as well as thread properties (perhaps each thread has a priority etc). A note: if there are many different processors then perhaps you need a special shared state per processor, especially if they have different shared resources (such as video memory or so). Another problem then comes in if the thread scheduler can move threads from one processor to another or not. I've never written anything like this and this is but a guess, but hopefully it gives an idea! Good luck! /Anders Nilsson On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> wrote: > Hi guys, > > I'm working in a ps2 emulator for educational purposes only. > I could run some demos but when the demos tried to create a thread it all > hangs out... that's because I didn't write any thread module xD > > So, how can I emulate threads without making them natives? I mean, the > theory behind. > Maybe this is not a big deal for you guys but I'm really stuck. > > Regards, > > -- > █║▌│█│║▌║││█║▌│║ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |
From: Sebastian L. <del...@gm...> - 2008-05-19 02:37:30
|
Hi Anders, Thanks for the reply! =) I never wrote something like this before too and your suggestion sound really good. I'll try it! Thanks again for the reply, I didn't mind if this question would be Ok for this list, sorry for the other users if I bother them. =) Regards, On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson <ja...@an...> wrote: > Well threads is just one more thing to emulate. Say your standard > emulation code is like this > > State state; // this could by registers, ports etc... emulation state > Operations ops; // instruction pointer > > while (!ops.empty()) { > op=ops.next(); > emulate(op, ops, state); // might be a jump so needs the ops-object as > well > } > > Say this is your emulator. Now when threading comes into the picture > you have to emulate several threads at the same time. > > On a modern computer there is some kind of manager that decides when > to switch threads. When a switch occur some state is replaced and > exchanged for a thread-specific-state. This probably means registers > but perhaps not state of vga-port etc. Now you have to figure out how > many operations you have to run for each thread. > > SharedState ss; > PrivateState ps[numThreads]; // One per thread > Operations ops[numThreads]; // One per thread > > while (true) { // needs some kind of termination... > > threadID, numOps=scheduler.next(); // next thread to process, > restart when it comes to the end > > for (i=1..numOps) { > if (ops[threadID].empty()) { > scheduler.killThread(threadID); > break; > } > > op=ops[threadID].next(); > emulate(op, ops[threadID], ss, ps[threadID]); > } > } > > Something like that! Now how many ops per thread and time slice > depends on a lot on hardware dependant factors as well as thread > properties (perhaps each thread has a priority etc). > > A note: if there are many different processors then perhaps you need a > special shared state per processor, especially if they have different > shared resources (such as video memory or so). Another problem then > comes in if the thread scheduler can move threads from one processor > to another or not. > > I've never written anything like this and this is but a guess, but > hopefully it gives an idea! > > Good luck! > > /Anders Nilsson > > On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> > wrote: > > Hi guys, > > > > I'm working in a ps2 emulator for educational purposes only. > > I could run some demos but when the demos tried to create a thread it all > > hangs out... that's because I didn't write any thread module xD > > > > So, how can I emulate threads without making them natives? I mean, the > > theory behind. > > Maybe this is not a big deal for you guys but I'm really stuck. > > > > Regards, > > > > -- > > █║▌│█│║▌║││█║▌│║ > > Sebastian Javier Lucas > > Programmer & Guitar Hero > > working@: gameloft > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: David N. <da...@re...> - 2008-05-19 17:28:37
|
Hey, I remember back from school in my operating systems theory class we had to learn and implement different threading models. The book we were using is an operating systems book with the dinosaurs on the front 'Operating System Concepts'. It's the standard OS teaching book. If there is a local college in your area I'm sure you could check it out from their library. That should have everything you need to know on the subject. -= Dave ________________________________ From: Sebastian Lucas [mailto:del...@gm...] Sent: Sunday, May 18, 2008 7:38 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation Hi Anders, Thanks for the reply! =) I never wrote something like this before too and your suggestion sound really good. I'll try it! Thanks again for the reply, I didn't mind if this question would be Ok for this list, sorry for the other users if I bother them. =) Regards, On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson <ja...@an...> wrote: Well threads is just one more thing to emulate. Say your standard emulation code is like this State state; // this could by registers, ports etc... emulation state Operations ops; // instruction pointer while (!ops.empty()) { op=ops.next(); emulate(op, ops, state); // might be a jump so needs the ops-object as well } Say this is your emulator. Now when threading comes into the picture you have to emulate several threads at the same time. On a modern computer there is some kind of manager that decides when to switch threads. When a switch occur some state is replaced and exchanged for a thread-specific-state. This probably means registers but perhaps not state of vga-port etc. Now you have to figure out how many operations you have to run for each thread. SharedState ss; PrivateState ps[numThreads]; // One per thread Operations ops[numThreads]; // One per thread while (true) { // needs some kind of termination... threadID, numOps=scheduler.next(); // next thread to process, restart when it comes to the end for (i=1..numOps) { if (ops[threadID].empty()) { scheduler.killThread(threadID); break; } op=ops[threadID].next(); emulate(op, ops[threadID], ss, ps[threadID]); } } Something like that! Now how many ops per thread and time slice depends on a lot on hardware dependant factors as well as thread properties (perhaps each thread has a priority etc). A note: if there are many different processors then perhaps you need a special shared state per processor, especially if they have different shared resources (such as video memory or so). Another problem then comes in if the thread scheduler can move threads from one processor to another or not. I've never written anything like this and this is but a guess, but hopefully it gives an idea! Good luck! /Anders Nilsson On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> wrote: > Hi guys, > > I'm working in a ps2 emulator for educational purposes only. > I could run some demos but when the demos tried to create a thread it all > hangs out... that's because I didn't write any thread module xD > > So, how can I emulate threads without making them natives? I mean, the > theory behind. > Maybe this is not a big deal for you guys but I'm really stuck. > > Regards, > > -- > █║▌│█│║▌║││█║▌│║ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Osman, B. <BO...@vv...> - 2008-05-19 17:34:41
|
... I'm sure that many of the people reading this thread are thinking the same thing, so I'll be the one to say it. The PS2's threading model is absolutely insane (compared to any modern OS). The upside of this is that it's probably easier to implement a scheduler that does what the PS2 OS does. The downside is that if you don't know what the PS2 does, and you go read an OS textbook, you're going to end up implementing a real thread scheduler. And lots of PS2 software is unlikely to work correctly, because it almost certainly includes lots of hacks and workarounds for the crazy threading model. Good luck. -Brian ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of David Neubelt Sent: Monday, May 19, 2008 1:29 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation Hey, I remember back from school in my operating systems theory class we had to learn and implement different threading models. The book we were using is an operating systems book with the dinosaurs on the front 'Operating System Concepts'. It's the standard OS teaching book. If there is a local college in your area I'm sure you could check it out from their library. That should have everything you need to know on the subject. -= Dave ________________________________ From: Sebastian Lucas [mailto:del...@gm...] Sent: Sunday, May 18, 2008 7:38 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation Hi Anders, Thanks for the reply! =) I never wrote something like this before too and your suggestion sound really good. I'll try it! Thanks again for the reply, I didn't mind if this question would be Ok for this list, sorry for the other users if I bother them. =) Regards, On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson <ja...@an...> wrote: Well threads is just one more thing to emulate. Say your standard emulation code is like this State state; // this could by registers, ports etc... emulation state Operations ops; // instruction pointer while (!ops.empty()) { op=ops.next(); emulate(op, ops, state); // might be a jump so needs the ops-object as well } Say this is your emulator. Now when threading comes into the picture you have to emulate several threads at the same time. On a modern computer there is some kind of manager that decides when to switch threads. When a switch occur some state is replaced and exchanged for a thread-specific-state. This probably means registers but perhaps not state of vga-port etc. Now you have to figure out how many operations you have to run for each thread. SharedState ss; PrivateState ps[numThreads]; // One per thread Operations ops[numThreads]; // One per thread while (true) { // needs some kind of termination... threadID, numOps=scheduler.next(); // next thread to process, restart when it comes to the end for (i=1..numOps) { if (ops[threadID].empty()) { scheduler.killThread(threadID); break; } op=ops[threadID].next(); emulate(op, ops[threadID], ss, ps[threadID]); } } Something like that! Now how many ops per thread and time slice depends on a lot on hardware dependant factors as well as thread properties (perhaps each thread has a priority etc). A note: if there are many different processors then perhaps you need a special shared state per processor, especially if they have different shared resources (such as video memory or so). Another problem then comes in if the thread scheduler can move threads from one processor to another or not. I've never written anything like this and this is but a guess, but hopefully it gives an idea! Good luck! /Anders Nilsson On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> wrote: > Hi guys, > > I'm working in a ps2 emulator for educational purposes only. > I could run some demos but when the demos tried to create a thread it all > hangs out... that's because I didn't write any thread module xD > > So, how can I emulate threads without making them natives? I mean, the > theory behind. > Maybe this is not a big deal for you guys but I'm really stuck. > > Regards, > > -- > █║▌│█│║▌║││█║▌│║ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Randall T. <rturner@Volition-inc.com> - 2008-05-19 17:51:35
|
The threads do jump around a lot from one hw thread to the other but in a lot of ways the PS3 kernel is actually closer to what you want. It's deterministic. It doesn't have arbitrary priority bumping or timeslicing. Much closer to a realtime kernel than the 360's. Makes it easier to shoot yourself in the foot, but also easier (aside from the system threads) to control dispatch latency. Ie, it's not all bad. ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Osman, Brian Sent: Monday, May 19, 2008 12:35 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation ... I'm sure that many of the people reading this thread are thinking the same thing, so I'll be the one to say it. The PS2's threading model is absolutely insane (compared to any modern OS). The upside of this is that it's probably easier to implement a scheduler that does what the PS2 OS does. The downside is that if you don't know what the PS2 does, and you go read an OS textbook, you're going to end up implementing a real thread scheduler. And lots of PS2 software is unlikely to work correctly, because it almost certainly includes lots of hacks and workarounds for the crazy threading model. Good luck. -Brian ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of David Neubelt Sent: Monday, May 19, 2008 1:29 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation Hey, I remember back from school in my operating systems theory class we had to learn and implement different threading models. The book we were using is an operating systems book with the dinosaurs on the front 'Operating System Concepts'. It's the standard OS teaching book. If there is a local college in your area I'm sure you could check it out from their library. That should have everything you need to know on the subject. -= Dave ________________________________ From: Sebastian Lucas [mailto:del...@gm...] Sent: Sunday, May 18, 2008 7:38 PM To: Game Development Algorithms Subject: Re: [Algorithms] Threading by software emulation Hi Anders, Thanks for the reply! =) I never wrote something like this before too and your suggestion sound really good. I'll try it! Thanks again for the reply, I didn't mind if this question would be Ok for this list, sorry for the other users if I bother them. =) Regards, On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson <ja...@an...> wrote: Well threads is just one more thing to emulate. Say your standard emulation code is like this State state; // this could by registers, ports etc... emulation state Operations ops; // instruction pointer while (!ops.empty()) { op=ops.next(); emulate(op, ops, state); // might be a jump so needs the ops-object as well } Say this is your emulator. Now when threading comes into the picture you have to emulate several threads at the same time. On a modern computer there is some kind of manager that decides when to switch threads. When a switch occur some state is replaced and exchanged for a thread-specific-state. This probably means registers but perhaps not state of vga-port etc. Now you have to figure out how many operations you have to run for each thread. SharedState ss; PrivateState ps[numThreads]; // One per thread Operations ops[numThreads]; // One per thread while (true) { // needs some kind of termination... threadID, numOps=scheduler.next(); // next thread to process, restart when it comes to the end for (i=1..numOps) { if (ops[threadID].empty()) { scheduler.killThread(threadID); break; } op=ops[threadID].next(); emulate(op, ops[threadID], ss, ps[threadID]); } } Something like that! Now how many ops per thread and time slice depends on a lot on hardware dependant factors as well as thread properties (perhaps each thread has a priority etc). A note: if there are many different processors then perhaps you need a special shared state per processor, especially if they have different shared resources (such as video memory or so). Another problem then comes in if the thread scheduler can move threads from one processor to another or not. I've never written anything like this and this is but a guess, but hopefully it gives an idea! Good luck! /Anders Nilsson On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> wrote: > Hi guys, > > I'm working in a ps2 emulator for educational purposes only. > I could run some demos but when the demos tried to create a thread it all > hangs out... that's because I didn't write any thread module xD > > So, how can I emulate threads without making them natives? I mean, the > theory behind. > Maybe this is not a big deal for you guys but I'm really stuck. > > Regards, > > -- > █║▌│█│║▌║││█║▌│║ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Oscar F. <os...@tr...> - 2008-05-19 18:03:15
|
Its not that crazy ... its ... well .. different. But its a very simple system :) 2008/5/19 Osman, Brian <BO...@vv...>: > … I'm sure that many of the people reading this thread are thinking the > same thing, so I'll be the one to say it. The PS2's threading model is > absolutely insane (compared to any modern OS). The upside of this is that > it's probably easier to implement a scheduler that does what the PS2 OS > does. The downside is that if you don't know what the PS2 does, and you go > read an OS textbook, you're going to end up implementing a *real* thread > scheduler. And lots of PS2 software is unlikely to work correctly, because > it almost certainly includes lots of hacks and workarounds for the crazy > threading model. Good luck. > > > > -Brian > > > ------------------------------ > > *From:* gda...@li... [mailto: > gda...@li...] *On Behalf Of *David > Neubelt > *Sent:* Monday, May 19, 2008 1:29 PM > > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Threading by software emulation > > > > Hey, > > > > I remember back from school in my operating systems theory class we had to > learn and implement different threading models. The book we were using is an > operating systems book with the dinosaurs on the front 'Operating System > Concepts'. It's the standard OS teaching book. If there is a local college > in your area I'm sure you could check it out from their library. > > > > That should have everything you need to know on the subject. > > > > -= Dave > > > ------------------------------ > > *From:* Sebastian Lucas [mailto:del...@gm...] > *Sent:* Sunday, May 18, 2008 7:38 PM > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Threading by software emulation > > > > Hi Anders, > > Thanks for the reply! =) > I never wrote something like this before too and your suggestion sound > really good. > I'll try it! > > Thanks again for the reply, I didn't mind if this question would be Ok for > this list, sorry for the other users if I bother them. =) > > Regards, > > On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson <ja...@an...> > wrote: > > Well threads is just one more thing to emulate. Say your standard > emulation code is like this > > State state; // this could by registers, ports etc... emulation state > Operations ops; // instruction pointer > > while (!ops.empty()) { > op=ops.next(); > emulate(op, ops, state); // might be a jump so needs the ops-object as > well > } > > Say this is your emulator. Now when threading comes into the picture > you have to emulate several threads at the same time. > > On a modern computer there is some kind of manager that decides when > to switch threads. When a switch occur some state is replaced and > exchanged for a thread-specific-state. This probably means registers > but perhaps not state of vga-port etc. Now you have to figure out how > many operations you have to run for each thread. > > SharedState ss; > PrivateState ps[numThreads]; // One per thread > Operations ops[numThreads]; // One per thread > > while (true) { // needs some kind of termination... > > threadID, numOps=scheduler.next(); // next thread to process, > restart when it comes to the end > > for (i=1..numOps) { > if (ops[threadID].empty()) { > scheduler.killThread(threadID); > break; > } > > op=ops[threadID].next(); > emulate(op, ops[threadID], ss, ps[threadID]); > } > } > > Something like that! Now how many ops per thread and time slice > depends on a lot on hardware dependant factors as well as thread > properties (perhaps each thread has a priority etc). > > A note: if there are many different processors then perhaps you need a > special shared state per processor, especially if they have different > shared resources (such as video memory or so). Another problem then > comes in if the thread scheduler can move threads from one processor > to another or not. > > I've never written anything like this and this is but a guess, but > hopefully it gives an idea! > > Good luck! > > /Anders Nilsson > > > On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> > wrote: > > Hi guys, > > > > I'm working in a ps2 emulator for educational purposes only. > > I could run some demos but when the demos tried to create a thread it all > > hangs out... that's because I didn't write any thread module xD > > > > So, how can I emulate threads without making them natives? I mean, the > > theory behind. > > Maybe this is not a big deal for you guys but I'm really stuck. > > > > Regards, > > > > -- > > │││││ > > Sebastian Javier Lucas > > Programmer & Guitar Hero > > working@: gameloft > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > -- > │││││ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |
From: Sebastian L. <del...@gm...> - 2008-05-20 13:44:54
|
Thanks to all guys! I think then maybe mixing the things together and by doing some hacks I would let it work. I've written some demos with my ps2 (using the ps2link) using threads but it's different when you really want to write an emulator... remember that this is just to boost my knowledge. I'd really appreciated the replies =) Regards, 2008/5/19 Oscar Forth <os...@tr...>: > Its not that crazy ... its ... well .. different. But its a very simple > system :) > 2008/5/19 Osman, Brian <BO...@vv...>: > > … I'm sure that many of the people reading this thread are thinking the >> same thing, so I'll be the one to say it. The PS2's threading model is >> absolutely insane (compared to any modern OS). The upside of this is that >> it's probably easier to implement a scheduler that does what the PS2 OS >> does. The downside is that if you don't know what the PS2 does, and you go >> read an OS textbook, you're going to end up implementing a *real* thread >> scheduler. And lots of PS2 software is unlikely to work correctly, because >> it almost certainly includes lots of hacks and workarounds for the crazy >> threading model. Good luck. >> >> >> >> -Brian >> >> >> ------------------------------ >> >> *From:* gda...@li... [mailto: >> gda...@li...] *On Behalf Of *David >> Neubelt >> *Sent:* Monday, May 19, 2008 1:29 PM >> >> *To:* Game Development Algorithms >> *Subject:* Re: [Algorithms] Threading by software emulation >> >> >> >> Hey, >> >> >> >> I remember back from school in my operating systems theory class we had to >> learn and implement different threading models. The book we were using is an >> operating systems book with the dinosaurs on the front 'Operating System >> Concepts'. It's the standard OS teaching book. If there is a local college >> in your area I'm sure you could check it out from their library. >> >> >> >> That should have everything you need to know on the subject. >> >> >> >> -= Dave >> >> >> ------------------------------ >> >> *From:* Sebastian Lucas [mailto:del...@gm...] >> *Sent:* Sunday, May 18, 2008 7:38 PM >> *To:* Game Development Algorithms >> *Subject:* Re: [Algorithms] Threading by software emulation >> >> >> >> Hi Anders, >> >> Thanks for the reply! =) >> I never wrote something like this before too and your suggestion sound >> really good. >> I'll try it! >> >> Thanks again for the reply, I didn't mind if this question would be Ok for >> this list, sorry for the other users if I bother them. =) >> >> Regards, >> >> On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson < >> ja...@an...> wrote: >> >> Well threads is just one more thing to emulate. Say your standard >> emulation code is like this >> >> State state; // this could by registers, ports etc... emulation state >> Operations ops; // instruction pointer >> >> while (!ops.empty()) { >> op=ops.next(); >> emulate(op, ops, state); // might be a jump so needs the ops-object as >> well >> } >> >> Say this is your emulator. Now when threading comes into the picture >> you have to emulate several threads at the same time. >> >> On a modern computer there is some kind of manager that decides when >> to switch threads. When a switch occur some state is replaced and >> exchanged for a thread-specific-state. This probably means registers >> but perhaps not state of vga-port etc. Now you have to figure out how >> many operations you have to run for each thread. >> >> SharedState ss; >> PrivateState ps[numThreads]; // One per thread >> Operations ops[numThreads]; // One per thread >> >> while (true) { // needs some kind of termination... >> >> threadID, numOps=scheduler.next(); // next thread to process, >> restart when it comes to the end >> >> for (i=1..numOps) { >> if (ops[threadID].empty()) { >> scheduler.killThread(threadID); >> break; >> } >> >> op=ops[threadID].next(); >> emulate(op, ops[threadID], ss, ps[threadID]); >> } >> } >> >> Something like that! Now how many ops per thread and time slice >> depends on a lot on hardware dependant factors as well as thread >> properties (perhaps each thread has a priority etc). >> >> A note: if there are many different processors then perhaps you need a >> special shared state per processor, especially if they have different >> shared resources (such as video memory or so). Another problem then >> comes in if the thread scheduler can move threads from one processor >> to another or not. >> >> I've never written anything like this and this is but a guess, but >> hopefully it gives an idea! >> >> Good luck! >> >> /Anders Nilsson >> >> >> On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> >> wrote: >> > Hi guys, >> > >> > I'm working in a ps2 emulator for educational purposes only. >> > I could run some demos but when the demos tried to create a thread it >> all >> > hangs out... that's because I didn't write any thread module xD >> > >> > So, how can I emulate threads without making them natives? I mean, the >> > theory behind. >> > Maybe this is not a big deal for you guys but I'm really stuck. >> > >> > Regards, >> > >> > -- >> > │││││ >> > Sebastian Javier Lucas >> > Programmer & Guitar Hero >> > working@: gameloft >> >> > >> ------------------------------------------------------------------------- >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2008. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > _______________________________________________ >> > GDAlgorithms-list mailing list >> > GDA...@li... >> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> > Archives: >> > >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >> > >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >> >> >> >> >> -- >> │││││ >> Sebastian Javier Lucas >> Programmer & Guitar Hero >> working@: gameloft >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- │││││ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Oscar F. <os...@tr...> - 2008-05-20 15:26:42
|
Well i think the problem is that most of us who know will have signed NDAs ... If you have access to a PS2 proper than play about with some threading and check how it works. It really is pretty simple :) Though, admittedly, it'd be far easier to work out with something like the SN Debugger to help you along ... 2008/5/20 Sebastian Lucas <del...@gm...>: > Thanks to all guys! > I think then maybe mixing the things together and by doing some hacks I > would let it work. > > I've written some demos with my ps2 (using the ps2link) using threads but > it's different when you really want to write an emulator... remember that > this is just to boost my knowledge. > > I'd really appreciated the replies =) > > Regards, > > 2008/5/19 Oscar Forth <os...@tr...>: > > Its not that crazy ... its ... well .. different. But its a very simple >> system :) >> 2008/5/19 Osman, Brian <BO...@vv...>: >> >> … I'm sure that many of the people reading this thread are thinking the >>> same thing, so I'll be the one to say it. The PS2's threading model is >>> absolutely insane (compared to any modern OS). The upside of this is that >>> it's probably easier to implement a scheduler that does what the PS2 OS >>> does. The downside is that if you don't know what the PS2 does, and you go >>> read an OS textbook, you're going to end up implementing a *real* thread >>> scheduler. And lots of PS2 software is unlikely to work correctly, because >>> it almost certainly includes lots of hacks and workarounds for the crazy >>> threading model. Good luck. >>> >>> >>> >>> -Brian >>> >>> >>> ------------------------------ >>> >>> *From:* gda...@li... [mailto: >>> gda...@li...] *On Behalf Of *David >>> Neubelt >>> *Sent:* Monday, May 19, 2008 1:29 PM >>> >>> *To:* Game Development Algorithms >>> *Subject:* Re: [Algorithms] Threading by software emulation >>> >>> >>> >>> Hey, >>> >>> >>> >>> I remember back from school in my operating systems theory class we had >>> to learn and implement different threading models. The book we were using is >>> an operating systems book with the dinosaurs on the front 'Operating System >>> Concepts'. It's the standard OS teaching book. If there is a local college >>> in your area I'm sure you could check it out from their library. >>> >>> >>> >>> That should have everything you need to know on the subject. >>> >>> >>> >>> -= Dave >>> >>> >>> ------------------------------ >>> >>> *From:* Sebastian Lucas [mailto:del...@gm...] >>> *Sent:* Sunday, May 18, 2008 7:38 PM >>> *To:* Game Development Algorithms >>> *Subject:* Re: [Algorithms] Threading by software emulation >>> >>> >>> >>> Hi Anders, >>> >>> Thanks for the reply! =) >>> I never wrote something like this before too and your suggestion sound >>> really good. >>> I'll try it! >>> >>> Thanks again for the reply, I didn't mind if this question would be Ok >>> for this list, sorry for the other users if I bother them. =) >>> >>> Regards, >>> >>> On Sun, May 18, 2008 at 4:01 PM, Anders Nilsson < >>> ja...@an...> wrote: >>> >>> Well threads is just one more thing to emulate. Say your standard >>> emulation code is like this >>> >>> State state; // this could by registers, ports etc... emulation state >>> Operations ops; // instruction pointer >>> >>> while (!ops.empty()) { >>> op=ops.next(); >>> emulate(op, ops, state); // might be a jump so needs the ops-object as >>> well >>> } >>> >>> Say this is your emulator. Now when threading comes into the picture >>> you have to emulate several threads at the same time. >>> >>> On a modern computer there is some kind of manager that decides when >>> to switch threads. When a switch occur some state is replaced and >>> exchanged for a thread-specific-state. This probably means registers >>> but perhaps not state of vga-port etc. Now you have to figure out how >>> many operations you have to run for each thread. >>> >>> SharedState ss; >>> PrivateState ps[numThreads]; // One per thread >>> Operations ops[numThreads]; // One per thread >>> >>> while (true) { // needs some kind of termination... >>> >>> threadID, numOps=scheduler.next(); // next thread to process, >>> restart when it comes to the end >>> >>> for (i=1..numOps) { >>> if (ops[threadID].empty()) { >>> scheduler.killThread(threadID); >>> break; >>> } >>> >>> op=ops[threadID].next(); >>> emulate(op, ops[threadID], ss, ps[threadID]); >>> } >>> } >>> >>> Something like that! Now how many ops per thread and time slice >>> depends on a lot on hardware dependant factors as well as thread >>> properties (perhaps each thread has a priority etc). >>> >>> A note: if there are many different processors then perhaps you need a >>> special shared state per processor, especially if they have different >>> shared resources (such as video memory or so). Another problem then >>> comes in if the thread scheduler can move threads from one processor >>> to another or not. >>> >>> I've never written anything like this and this is but a guess, but >>> hopefully it gives an idea! >>> >>> Good luck! >>> >>> /Anders Nilsson >>> >>> >>> On Sun, May 18, 2008 at 3:33 AM, Sebastian Lucas <del...@gm...> >>> wrote: >>> > Hi guys, >>> > >>> > I'm working in a ps2 emulator for educational purposes only. >>> > I could run some demos but when the demos tried to create a thread it >>> all >>> > hangs out... that's because I didn't write any thread module xD >>> > >>> > So, how can I emulate threads without making them natives? I mean, the >>> > theory behind. >>> > Maybe this is not a big deal for you guys but I'm really stuck. >>> > >>> > Regards, >>> > >>> > -- >>> > │││││ >>> > Sebastian Javier Lucas >>> > Programmer & Guitar Hero >>> > working@: gameloft >>> >>> > >>> ------------------------------------------------------------------------- >>> > This SF.net email is sponsored by: Microsoft >>> > Defy all challenges. Microsoft(R) Visual Studio 2008. >>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> > _______________________________________________ >>> > GDAlgorithms-list mailing list >>> > GDA...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> > Archives: >>> > >>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >>> > >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >>> >>> >>> >>> >>> -- >>> │││││ >>> Sebastian Javier Lucas >>> Programmer & Guitar Hero >>> working@: gameloft >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >>> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >> > > > > -- > │││││ > Sebastian Javier Lucas > Programmer & Guitar Hero > working@: gameloft > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |
From: Axel W. <aw...@fr...> - 2008-05-20 15:59:15
|
Here is a counter question to get you on the right path: How have you implemented interrupts? Thread emulation depends a little bit on the kind of emulation that you are aiming for: Are you writing a HLE or a cycle-accurate emulator? Full and correct CPU emulation should give you the threading for free once you run the PS2 Kernel in your emulator (which would be naughty). On the other hand, the typical HLE approach would be to implement as much on the platform that the emulator runs on so in this case you probably would want to write the thread scheduler on your own. Axel On May 20, 2008, at 6:43 AM, Sebastian Lucas wrote: > Thanks to all guys! > I think then maybe mixing the things together and by doing some > hacks I would let it work. > > I've written some demos with my ps2 (using the ps2link) using > threads but it's different when you really want to write an > emulator... remember that this is just to boost my knowledge. > > I'd really appreciated the replies =) > > Regards, |
From: Sebastian L. <del...@gm...> - 2008-05-23 02:25:53
|
Hi, Sorry about the delay, I was too busy at work. Yes, I'm writing a HLE emulator, remember that this project is just to boost my knowledge. The interrupts are implemented in a queue with callbacks. So, according to your words the best way should be to make my own thread class and pass the pointer (in memory) to the app? Because I did that, but the scheduler was linear and too slow (I mean, really slooow) that was what get me here. I don't know how a thread by itself works, I mean, when they spawn they've a copy of the registers, pc, etc right? They would never share again the same registers or pc, etc right? For example, my first approach was (by each of the new threads that were created): 1) Copy registers, pc. 2) Add them to a list. I created a dummy thread at the entry point (a hack, I know). Each 4000 instructions I was switching them in this way: 1) Save the current registers, pc to the current thread. 2) Stop the current thread. 3) Find another one. 4) Copy the registers, pc to the cpu module. 5) Make it the current one. 6) Continue until we reach again the 4000 instructions executed. (I should explain that in the first email, my fault) I wrote a gameboy emulator a few years ago, but this thing of threads is something new for me. Well, hope that this will leave the things clear. BTW, thanks to all... all the ideas and interest are really helpful. =) Regards, On Tue, May 20, 2008 at 12:59 PM, Axel Wefers <aw...@fr...> wrote: > Here is a counter question to get you on the right path: How have you > implemented interrupts? > > Thread emulation depends a little bit on the kind of emulation that you are > aiming for: Are you writing a HLE or a cycle-accurate emulator? Full and > correct CPU emulation should give you the threading for free once you run > the PS2 Kernel in your emulator (which would be naughty). On the other hand, > the typical HLE approach would be to implement as much on the platform that > the emulator runs on so in this case you probably would want to write the > thread scheduler on your own. > > Axel > On May 20, 2008, at 6:43 AM, Sebastian Lucas wrote: > > Thanks to all guys! > I think then maybe mixing the things together and by doing some hacks I > would let it work. > > I've written some demos with my ps2 (using the ps2link) using threads but > it's different when you really want to write an emulator... remember that > this is just to boost my knowledge. > > I'd really appreciated the replies =) > > Regards, > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Simon F. <sim...@po...> - 2008-05-19 06:26:12
|
Hi Sebastian, I've not tried this myself but would http://it.slashdot.org/article.pl?sid=05/10/06/2223232&from=rss and http://www.sics.se/~adam/old-uip/uip-1.0-refman/a00142.html be of help? AFAIU it's basically a "duffs device-like" C trick to do light weight threading. Simon ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Sebastian Lucas Sent: 18 May 2008 02:34 To: gda...@li... Subject: [Algorithms] Threading by software emulation Hi guys, I'm working in a ps2 emulator for educational purposes only. I could run some demos but when the demos tried to create a thread it all hangs out... that's because I didn't write any thread module xD So, how can I emulate threads without making them natives? I mean, the theory behind. Maybe this is not a big deal for you guys but I'm really stuck. Regards, -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |
From: Jon W. <hp...@mi...> - 2008-05-23 20:47:00
|
Sebastian Lucas wrote: > Each 4000 instructions I was switching them in this way: > 1) Save the current registers, pc to the current thread. > 2) Stop the current thread. > 3) Find another one. > 4) Copy the registers, pc to the cpu module. > 5) Make it the current one. > 6) Continue until we reach again the 4000 instructions executed. > I think 4000 instructions is way too often for good performance. Try switching every 100,000 or even every 500,000 instructions, in addition to explicit switching if there's a blocking call. I don't know the exact behavior of the PS/2 scheduler, though, so perhaps that won't be compatible, but I would assume you want to run until you block in most cases. Also, I would implement context switch by storing PC, registers and other state in a struct, and allocate a new struct for each thread context. Instead of copying the context around, I would just use a pointer to the current context, and set that pointer to point to another context. Given that you probably are using a pointer to the current context anyway, that should not introduce any overhead in the innards of the emulator (other than host CPU cache misses on switch). Sincerely, jw |
From: Sebastian L. <del...@gm...> - 2008-05-24 00:17:53
|
Hi Jon, You're right! I didn't realize about the pointers. Thanks for the reply! =) As soon as I get free in my work I'll share this to all. Regards, On Fri, May 23, 2008 at 5:47 PM, Jon Watte <hp...@mi...> wrote: > Sebastian Lucas wrote: > > Each 4000 instructions I was switching them in this way: > > 1) Save the current registers, pc to the current thread. > > 2) Stop the current thread. > > 3) Find another one. > > 4) Copy the registers, pc to the cpu module. > > 5) Make it the current one. > > 6) Continue until we reach again the 4000 instructions executed. > > > > I think 4000 instructions is way too often for good performance. Try > switching every 100,000 or even every 500,000 instructions, in addition > to explicit switching if there's a blocking call. I don't know the exact > behavior of the PS/2 scheduler, though, so perhaps that won't be > compatible, but I would assume you want to run until you block in most > cases. > > Also, I would implement context switch by storing PC, registers and > other state in a struct, and allocate a new struct for each thread > context. Instead of copying the context around, I would just use a > pointer to the current context, and set that pointer to point to another > context. Given that you probably are using a pointer to the current > context anyway, that should not introduce any overhead in the innards of > the emulator (other than host CPU cache misses on switch). > > Sincerely, > > jw > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- █║▌│█│║▌║││█║▌│║ Sebastian Javier Lucas Programmer & Guitar Hero working@: gameloft |