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
