Great, thanks for the offer. We may well take you up on that. We're
actually very far along on the new CPU model (FS support is the only
major thing that's lacking), but we need to do some major cleanup on the
memory system interface(s) before it's worth having you look at it.
My goal is to get that done by the first of the year.
Replacing the encumbered code is another one of our motivations for all
the rewriting; the only pieces of encumbered code that we're not
planning on obsoleting are the EIO trace support (since we only read EIO
traces and you need SimpleScalar to generate them, it's kind of
pointless to rewrite it just to eliminate the license issue; plus the
EIO format is kind of awkward anyway and we'd rather just come up with
our own format if we need to) and the TurboLaser device support from
SimOS (since that's only used to boot Tru64, not Linux).
Steve
Antti P Miettinen wrote:
Steve Reinhardt <[EMAIL PROTECTED]> writes:
.. maybe earlier if you're willing to be a
guinea pig for this code.
Sure - as far as time permits.
So far I've been playing with M5 on my spare time but I'm a bit
worried about the encumbered directory as my interest in M5 is related
to the work I do. And that work, although research, is done in a
clearly commercial context. So to me the licensing is another reason
to get a replacement for the use of the functional memory model. If I
were able to use M5 at work I might also be able to contribute..
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
m5sim-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/m5sim-users
