extracted imul from worker/system.js

[regular]

• extracted imul.js from worker/system.js
• fixed a couple of jshint warnings in that file (missing semicolons, === instead of ==)

(I am taking baby-steps in refactoring here to see if you like them)

If we would split the jor1k repo into jor1k-core and jor1k-demo (or simply named jor1k, if you prefer), we would get rid of the *-min.js diffs, which would help readability.

[s-macke]

I have always separated the browserify generated files in a separate commits. I would suggest to do the same. Change everything, and then when you think it should be published on gh-pages, you can commit the new -min files.

[s-macke]

I would also suggest to not change the var variables. ECMAScript6 is coming this year with "let", which finally has the correct behavior for variables in brackets.

[s-macke]

Maybe you don't see it, but I use every variable as typed. Never define just "var a; .... a=new UIntArray,,,,,". Most of the time I want to prevent some misunderstandings for the jit compiler. In this part it doesn't matter, but it might matter in the fastcpu.js part. I know, that such defined variables are flagged as polymorph in the intermediate code (Javascript byte code) and might change something in the compiled code. I just want to tell you the logic behind a few design decisions.

[s-macke]

For the moment I would keep one repository, but move all html and -min files to the examples folder keeping only one small index.html file in the main folder. We might separate this examples folder to different branches like gh-pages. But I don't like to start another repo. There are already 3 related to jor1k. Also the current link to the index.html file is used by a lot of websites. I don't want to change that.

[regular]

For a project with a level of complexity like yours, it is very common to split it up across even more repos, each with their own version number, package.json, readme.md describing the api, unit tests and issue tracker. It makes it much easier for outsiders to contribute to your project and re-use parts of it. As a rule of thumb: whenever a part could be re-used outside your project, it should live in its own repository. Obviously splitting up only makes sense after the project reached a certain level of maturity and stability and only you can judge this. My feeling is that it has reached this level though.

You could follow the example of npm itself and create a github organisation that holds together all those repos. (look into how many repos npm is broken). Over time, I would split off the terminal emulation, the different cpu flavours and devices etc. It would be cool if people could easily mix and match the different devices in the virtual computer and add their own virtual filesystems without forking jor1k. This would be more like an ecosystem.

[regular]

Thanks for clarifying the typed variable and jit stuff. I did not know it and will keep it in mind.

[regular]

And yes, I will not re-generate the -min.js files before committing in the future. How about having the -min.js files in the gh-pages branch only? Having build artefacts under version control often causes merge conflicts. This way we could limit that kind of problem to the gh-pages branch.

[regular]

The external links go to index.html in the gh-pages branch of the jor1k repo, right? By turning the jor1k repo into the demo repo, these links would stay intact.

[s-macke]

regenerating the -min.js files is Ok, but you shouldn't add them to the commit. :) This commit here didn't change anything on the functionality level. Therefore browserify was not necessary. First I would split the core and the different web-interfaces to different folders before doing anything like splitting repos. Other repositories have similar problems with minify and update these files only every few months, when they have a new release.