On Thu, 2 Aug 2012, Nathan Froyd wrote: > As $SUBJECT says. There's not too much interesting here. I did a > fairly literal-minded conversion, so it's possible there's smarter ways > to do some things.
Doesn't look too bad though, but ... > Compiled with cross to mmix-knuth-mmixware and spot-checked by comparing > libgcc object files. I have no idea how to set up a simulator > environment. Find the MMIXware simulator ("mmix"), install it. Following the links from our "further readings" page will take you to <http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html> or <http://mmix.cs.hm.edu/src/index.html> which both have links to the simulator. At time of this reading, the links point to identical tarballs, for example is <http://mmix.cs.hm.edu/src/mmix-20110831.tar.gz>. A dejagnu baseboard was in dejagnu-1.4.4 already, use "RUNTESTFLAGS=--target_board=mmixware-sim", which should not be a surprise to you, have you ever tested using a simulator before. Though if nothing changed in GCC in the last month (ha-ha), expect a lot of timeouts, and lots of LTO FAILs. Also, better wrap the executable in a script that does e.g. "ulimit -v 300000", as the simulator allocates memory on access (kind of like stack on modern systems), making debugging a bit harder than expected and letting the oomkiller run around out of control otherwise. (On my virtual todo-list to have MMIXware patches for controlled memory allocation; right after looking into the LTO FAILs.) > H-P, if you'd like to test beforehand, that'd be great. ...yes, I'd like to test this before, please. Thanks for your work. (Let's set a timeout at the end of August; ok to commit Sep 1 have I not got back to you.) (Now, from where did I get that H constraint?) brgds, H-P