I changed the subject of this to try to pretend to be a little dignified. It's a stretch I realize. Anyway, I've discovered part of why the output of init I sent out earlier is garbled. The relevant chunk of the trace is below if you're curious. Finding this made me realize that it would be very useful to have a large test program that did nothing but make sure that adds add, that flags are set correctly, that if you try to access sph you get it, etc. The example programs I've run have flushed out a lot of those problems, but I'm sure there are still a lot in there. As M5 gets to be more and more correct, those bugs will be harder and harder to diagnose or even run across accidentally like they have been.
The "deliverables" would be a test program we could add to our regression suite and patches to fix, or at least a description of, what doesn't work. Initially the program should be for 64 bit Linux, but a 32 bit version would also be useful eventually. If you/they want to get fancy, you/they could even write a toy operating system which exercises some of the system level features of the ISA in creative and more complete ways. I think this works well in this situation for a few reasons. First, this would be a good learning experience for someone who isn't all that familiar with M5 and/or x86 as they'd get to interact with both in a relatively gentle way. Second, it's potentially illegal for me to work on something like this directly since it's similar to what I do at work. Gabe 5014266565500: system.cpu T0 : 0x2ba2fc5485c0.0 : MOV_R_M : ld rax, DS:[rsi] : MemRead : D=0x696e697379730063 A=0x7fffaec50f68 5014266566000: system.cpu T0 : 0x2ba2fc5485c3.0 : ADD_R_I : limm t1, 0x8 : IntAlu : D=0x0000000000000008 5014266566500: system.cpu T0 : 0x2ba2fc5485c3.1 : ADD_R_I : add rsi, rsi, t1 : IntAlu : D=0x0000000000000014 5014266567500: system.cpu T0 : 0x2ba2fc5485c7.0 : MOV_R_R : mov r9, r9, rax : IntAlu : D=0x696e697379730063 5014266568000: system.cpu T0 : 0x2ba2fc5485ca.0 : ADD_R_R : add r9, r9, r8 : IntAlu : D=0x0000000000000011 5014266569000: system.cpu T0 : 0x2ba2fc5485cd.0 : JNB_I : rdip t1, %ctrl153, : IntAlu : D=0x00002ba2fc5485d3 5014266569500: system.cpu T0 : 0x2ba2fc5485cd.1 : JNB_I : limm t2, 0x7d : IntAlu : D=0x000000000000007d 5014266570000: system.cpu T0 : 0x2ba2fc5485cd.2 : JNB_I : wrip , t1, t2 : IntAlu : 5014266570500: system.cpu T0 : 0x2ba2fc5485d3.0 : XOR_R_R : xor r9, r9, rax : IntAlu : D=0x0000000000000010 5014266571500: system.cpu T0 : 0x2ba2fc5485d6.0 : OR_R_R : or r9, r9, r8 : IntAlu : D=0x0000000000000094 5014266572000: system.cpu T0 : 0x2ba2fc5485d9.0 : INC_R : addi r9, r9, 0x1 : IntAlu : D=0x0000000000000090 5014266572500: system.cpu T0 : 0x2ba2fc5485dc.0 : JNZ_I : rdip t1, %ctrl153, : IntAlu : D=0x00002ba2fc5485de 5014266573000: system.cpu T0 : 0x2ba2fc5485dc.1 : JNZ_I : limm t2, 0x72 : IntAlu : D=0x0000000000000072 5014266573500: system.cpu T0 : 0x2ba2fc5485dc.2 : JNZ_I : wrip , t1, t2 : IntAlu : 5014266574000: system.cpu T0 : 0x2ba2fc548650.0 : MOV_M_R : st al, DS:[rdx] : MemWrite : D=0x0000000000000063 A=0x6c5fa7 5014266574500: system.cpu T0 : 0x2ba2fc548652.0 : TEST_R_R : and t0b, al, al : IntAlu : D=0x0000000000000010 5014266575000: system.cpu T0 : 0x2ba2fc548654.0 : JZ_I : rdip t1, %ctrl153, : IntAlu : D=0x00002ba2fc548656 5014266575500: system.cpu T0 : 0x2ba2fc548654.1 : JZ_I : limm t2, 0x12 : IntAlu : D=0x0000000000000012 5014266576000: system.cpu T0 : 0x2ba2fc548654.2 : JZ_I : wrip , t1, t2 : IntAlu : 5014266577000: system.cpu T0 : 0x2ba2fc548656.0 : INC_R : addi rdx, rdx, 0x1 : IntAlu : D=0x0000000000000004 5014266577500: system.cpu T0 : 0x2ba2fc548659.0 : MOV_M_R : st ah, DS:[rdx] : MemWrite : D=0x0000000000000063 A=0x6c5fa8 Gabe Black wrote: > It would be nice to have some help. There's a fairly steep learning > curve for both x86 and m5, but there are probably things that can be > done on their own timeline and that aren't too hard to figure out. I'll > see what I can come up with for people to work on and let you know. > > Gabe > > Dan Gibson wrote: > >> 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] >> <mailto:[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] <mailto:[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] <mailto:[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] >> <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> >>> > > http://m5sim.org/mailman/listinfo/m5-dev >> >>> > > >> >>> > > >> >>> > _______________________________________________ >> >>> > m5-dev mailing list >> >>> > [email protected] <mailto:[email protected]> >> >>> > http://m5sim.org/mailman/listinfo/m5-dev >> >>> > >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> m5-dev mailing list >> >>> [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> _______________________________________________ >> m5-dev mailing list >> [email protected] <mailto:[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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
