As I have said before, we have a lot of interest in M5/x86, but not a lot of expertise. So the question is: Can we realistically find tasks to be done by M5 amateurs? ... or will the overhead of simultaneously learning M5 is so high that we should all just praise Gabe as he blazes though the problems? I think Gabe could help to answer that.
I also should emphasize that I am speaking generally here. I do not command a giant willing army of graduate students. Regards, Dan On Wed, Feb 4, 2009 at 3:58 PM, nathan binkert <[email protected]> wrote: > Do Wisconsin or Stanford have people that are motivated to help Gabe? > If so, Gabe should certainly get that going. Gabe, I think it's > probably time for you to put out a call to the m5 list explaining that > x86 has come a long way and it is getting near the point of being > useful. You might find people willing to send you patches, especially > for things like fleshing out the instruction set. > > Nate > > 2009/2/4 Dan Gibson <[email protected]>: > > Gabe, > > I'll second this and go a little farther to say that your are in a very > good > > position to /direct/ work on the x86 codebase as well... its simply > unclear > > to a lot of us mortals what /needs/ to be done. So, posts here about > those > > things might be helpful. > > > > ... on the other hand, it might lead to pollution and weirdness in the > x86 > > codebase, so its certainly your call. > > > > Regards, > > Dan > > > > 2009/2/4 Korey Sewell <[email protected]> > >> > >> Hi Gabe, > >> I just wanted to chime in and say good work! I'm sure lots of people > will > >> benefit from your x86 efforts so you should feel very good about > yourself! > >> > >> On Wed, Feb 4, 2009 at 3:07 PM, <[email protected]> wrote: > >>> > >>> Even if people wouldn't normally run init (the scripts, not /sbin/init > >>> I'm > >>> assuming), there's an error here that I'd like to fix. I'm expecting > it's > >>> just > >>> that a string got mangled while being copied around so I shouldn't even > >>> have to > >>> dreg kernel innards to fix it. > >>> > >>> There are few things that are next. The first thing I'd like to do, > after > >>> fixing > >>> the apparent issues with the output below, is to go back and fix up the > >>> two > >>> hacks I'm aware of that I have in my tree. The first is handling TLB > >>> misses > >>> more cleanly. The second is that my syscall tracer is still just stuck > to > >>> the > >>> side of the exec tracer, but that should be mostly mechanical to > correct. > >>> > >>> After that, I'd like to take care of the unimplemented instructions > which > >>> are > >>> being skipped/warned about, support checkpointing, set up a golden > model > >>> to > >>> compare execution against somehow, start working on 32 bit support in > SE, > >>> and > >>> work on propagating my new message based interrupt scheme into the > other > >>> ISAs. > >>> I'd also like to try other kernel versions/compiles with other config > >>> options > >>> to see what errors those expose. > >>> > >>> Beyond that, in no particular order, I'd like to work on some sort of > >>> BIOS/boot > >>> loader set up so I can boot all the way from power on to power off, add > >>> minimal > >>> ACPI support, fill out my SMBios table, add a simple graphics device of > >>> some > >>> sort, and try to tighten up performance. Performance might actually be > >>> something to work on earlier since it would make all the other work a > >>> little > >>> more palatable. There are stretch marks on the simple CPU specifically > >>> from the > >>> microcode stuff but also unaligned memory accesses which I'd like to > >>> address at > >>> some point. > >>> > >>> Gabe > >>> > >>> Quoting nathan binkert <[email protected]>: > >>> > >>> > Woo! Super awesome! We generally don't run init and do our own > thing, > >>> > so it should be even easier to move forward. > >>> > > >>> > What's next? > >>> > > >>> > Nate > >>> > > >>> > On Wed, Feb 4, 2009 at 1:08 AM, Gabe Black <[email protected]> > >>> > wrote: > >>> > > A little over dramatic perhaps, and it's not quite right, but tada! > >>> > > Again! It even echoed when I typed! > >>> > > > >>> > > > >>> > > Freeing unused kernel memory: 232k freed > >>> > > INIT: version 2.86 booting > >>> > > /bin/bash: /sbin/rccùü¢+: No such file or directory > >>> > > /bin/baahh: /sbinnrr: No such file or directory > >>> > > INIT: Entering runlevel: 3 > >>> > > /bin/bash: /sbin/rccyðLý*: No such file or directory > >>> > > > >>> > > > >>> > > This is (none).unknown_domain (Linux x86_64 2.6.22.9) 00:00:05 > >>> > > > >>> > > (none) login: > >>> > > > >>> > > _______________________________________________ > >>> > > m5-dev mailing list > >>> > > [email protected] > >>> > > http://m5sim.org/mailman/listinfo/m5-dev > >>> > > > >>> > > > >>> > _______________________________________________ > >>> > m5-dev mailing list > >>> > [email protected] > >>> > http://m5sim.org/mailman/listinfo/m5-dev > >>> > > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> m5-dev mailing list > >>> [email protected] > >>> http://m5sim.org/mailman/listinfo/m5-dev > >> > >> > >> > >> -- > >> ---------- > >> Korey L Sewell > >> Graduate Student - PhD Candidate > >> Computer Science & Engineering > >> University of Michigan > >> > >> _______________________________________________ > >> m5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > > > > > -- > > http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson>[esc]:wq! > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
