Hi all, Firstly: Jakub, great work getting HelenOS going, and Boris many thanks for helping things along.
Secondly: No one is suggesting removing things for the sake of removing things. It is simply software-development hygiene. I hope we all agree that unused or non-working parts of the code base are not bringing value to anyone (in their current form), and are merely slowing down the progress of future _useful_ changes and additions. If we can identify and remove any unused or non-working code it benefits everyone: less confusion, less maintenance, and less testing. Removing stale code also gives more freedom to tune things for what is really working, and more focus on things that actually _do_ add value. More half-supported ISAs is clearly _not_ equivalent to a more useful simulation tool. I actually feel sorry for those users that struggle unnecessarily, similar to what Bjoern describes. The key question is what should be removed? Suggestions are welcome. As Bjoern points out, if someone feels compelled to put in the effort the code is still available as part of the repo and can be re-surrected. Andreas On 06/06/2016, 21:27, "gem5-dev on behalf of Bjoern A. Zeeb" <gem5-dev-boun...@gem5.org on behalf of bzeeb-li...@lists.zabbadoz.net> wrote: > >> On 06 Jun 2016, at 19:05 , Beckmann, Brad <brad.beckm...@amd.com> wrote: >> >Hi, > >> As others have already pointed out, there is still significant industry >>support for MIPS, SPARC, and POWER. Perhaps an argument could be made >>against ALPHA, but how hard is that ISA to maintain? Also there is some >>historical significance to ALPHA, since it was the first ISA. As Boris >>just pointed out, if anything, we should actively be encouraging someone >>to add RISC-V. We only drive people away from the simulator when we >>discuss removing features. > >I looked at MIPS (FS) support a few months back; it’s just not there; I >mean literally, what is there is not even a start to get it to working in >any reasonable timeframe. I’d love to see 64bit MIPS support but that’s >quite a lot of man hours. > >One thing people need to remember however is that retiring (currently) >unusable code does not mean that the code disappears, it sits in attic >and could be brought back; the effort to get it working is needed now >and will be then. The question simply is how likely is it going to >happen and when does the cost of keeping it around by far exceed the cost >of resurrecting it. > >My experience with x86_64 on non-Linux was not entirely happy the last 9 >months, that I’d rather wish the “advertising” would have been correct or >I might have never gone down that path; you need to be realistic in terms >of what people can expect and I’d rather have 3 properly working ISAs >than 7 out of which I waste a year of time to get anywhere. In that way >I think Andreas is right: you need at least 3 people per ISA that feel >responsible and commit themselves to (a) review patches and get them in, >(b) keep enough Open Source bits available for tests and reproducibility, >and (c) fee actively responsible for further development, documentation, >keeping things going. > >Just my 3cts >Bjoern > >_______________________________________________ >gem5-dev mailing list >gem5-dev@gem5.org >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
