I have no plans to fix any of this, but please do not just check in
fixes without sending out patches for review.    I'm particularly
interested in the first two.  For the generated protocol code, are you
trying to simultaneously compile multiple protocols into the same
binary or just trying to make it so you don't have to recompile if you
switch between the two.  I don't know if you can do the latter without
doing the former because of how scons does dependencies.  I can say
that I do know how to do the former.

For the error messages, I see no reason not to fix this now.

  Nate

> Tushar and I have noticed a few issues with GEM5 and we were wondering
> if anyone had plans to fix them.  If not, we'll go ahead and check in
> fixes to the global repository.  I just want to make sure we're not
> stepping on anyone's toes.
>
> - Fix SLICC so that protocol generated files are created in separate
> protocol specific folders. Currently they are created in the same
> mem/protocol folder overwriting older files (eg.
> build/ALPHA_SE/mem/protocol//ControllerFactory.cc).
> - Fully integrate SLICC parsing errors into scons.  Right now the error
> messages don't give any useful info.  Should we hold off on fixing this
> until SLICCer is added to GEM5?
> - Support broadcast protocols with NetDest ruby functions.  I notices
> that one of Derek's recent checkins removed all the NetDest functions in
> RubySlicc_ComponentMapping.hh.  Most of them were lot old, protocol
> specific, and needed to go.  However there were a few general ones that
> are needed by any broadcast based protocol.  Are there plans to add
> these back into the tree?
> - I appreciate that a lot of the controller assumptions on the ruby side
> have been removed.  However, it appears that Ruby now assumes a DMA
> controller is present.  Is there plans to clean this up.
>
> Again, we're happy to fix this stuff up ourselves.  I just want to be
> sure there aren't plans already in progress.
>
> Thanks,
>
> Brad
>
>
>
> _______________________________________________
> 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

Reply via email to