Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Counting cycles from one instead of zero? #377

Open
silvigon opened this issue Nov 7, 2024 · 3 comments
Open

Counting cycles from one instead of zero? #377

silvigon opened this issue Nov 7, 2024 · 3 comments

Comments

@silvigon
Copy link

silvigon commented Nov 7, 2024

An issue that was brought up in my latest meeting about the project described in #349 (which, I'm happy to report, is progressing nicely) is that students are routinely confused by Ripes counting processor cycles from zero instead of one, and my professors have asked me to investigate whether this could be changed.

I've come up with an initial implementation for this that seems to work, but I'd like to know if there's a reason for the default behaviour that we're missing.

@mortbopet
Copy link
Owner

It's a good question... hmm, I don't think any grander thoughts have been put behind why it starts from 0, but now that i think about it, i can see the confusion. The initial state of the processor is one where the instruction has already been loaded from instruction memory - regardless of processor model. Which somewhat implies that a clock cycle has occurred to make that load occur - do you agree? If we agree, I think that's a good argument for start at 1!

@silvigon
Copy link
Author

silvigon commented Dec 11, 2024

Sounds good to me! If it's something you're interested in merging into mainline Ripes, I'll do a pull request with my implementation as soon as I get the green light to host a mirror of our repo here.

Some of the other features we're working on are also either done (additional processor models from #349, improved "About" dialog), or in progress (modified processor selection dialog); let me know if you'd be interested in getting any of these merged as well :>

@mortbopet
Copy link
Owner

Great!

There's been a couple of Ripes forks already (which is awesome!), however, they've all taken the rough shape of "student semester projects". Fine for a working demo, not fine for maintainable software. Mainly because this has resulted in mono-commits that have been impossible to review, with code quality and standards that doesn't match the remainder of the project, and with a lack of willingness from the contributor(s) to comply with normal open source contribution standard and review cycles.

So with that said, I'm very open to accepting PRs into Ripes, but they have to be of open-source standards, and submitters have to be willing to follow some minimum level of diligence in submitting their changes (atomic PRs, code quality, formatting, ...).

It's a shame that quite a few promising contributions have stopped at that point, but unfortunately, i don't think the students (or their professors) had any incentive in making their work available and a benefit to a wider audience. That's unfortunate, because i think that kind of open-source involvement teaches students (and professors 😉) a lot of valuable skills.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants