-
Notifications
You must be signed in to change notification settings - Fork 53
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
Replace JMP with a CMP instruction, and rename JMR to JMP #26
Comments
So far as I know, your ISA is based on a two-register form (register file with 1 read port and 1 write port). If you plan having a three-register form (register file with 2 read ports and 1 write port) so you should offer a better ALU instruction set (like D = S ¤ T instead of D = D ¤ S) but that would change 16bitjs deeply.
then
the other parts can obtained by inverting D and S and/or using SETZ to invert boolean
And Jcc now:
The issue is that you have only 4 registers so it would make a little bit difficult to allocate T. As for JRcc, the situation is worse : 4 registers ! That's just some ideas to try to have conditional jump around two instructions but there is still some issues how to implement with a two-form and only 16-bit wide instruction. Need more thinking... |
My thinking was along the lines of having a non-jump based comparison
The final 3 bits I'm not sure. An offset of up to 7 doesn't seem that useful. |
Ok, there is one thing you must observe if you are trying to mimic a true hardware CPU. That register file I was talking about is a very important thing to consider or 16bitjs won't be a viable solution if ported to hardware. So far as I can see your ISA only accepts a two-register form. If you plan to add a third register, it does mean your CPU can accept a three-register form with a more complex register file (two read ports instead of only on read port). If you do this way, it also means your actual ISA is underusing the CPU and its register file capacity. So I strongly recommend you define that feature in a more general way and to extend the three-register form in ALU and MDU components. That is, having something like Just a remark, "Less than" means you're comparing signed words, not unsigned words. The choice of unsigned 16-bit word instead of signed word is weird for a CPU indeed. See for instance: http://unixwiz.net/techtips/x86-jumps.html. I don't understand how your Moreover, I can see this instruction is always followed by two instructions to set R3 which is a big cost. |
take a look at https://github.com/Domipheus/TPU/blob/master/isa/TPU%20Instruction%20Set%20Architecture.pdf. It is a good example of 16-bit CPU ported to hardware and so aware of the hardware limitation. |
Hey - thanks for the feedback! Honestly I haven't been thinking of making a real hardware version of 16bitjs, but now that you say it I can't imagine anything cooler. I am by no means an expert in this field, and this project was just as much about me learning more about the subject as anything else. With that said, my approach to software is constant, incremental change, optimisation and refactoring. So the changes made do not necessarily have to reflect a permanent solution - but can be a jumping off point for discussion (pun definitely intended). So I'm going to read into the resources you've shared, and if you're up for it we can try and come up with a solution that would allow an eventual hardware implementation to take place. I want to allow this one thing though: It does not need to the be the fastest or most optimal CPU 😄 I want to keep the original philosophical "as simple as possible but no simpler" intact. To address your other points, I was also thinking that unsigned is a weird way of doing things. I had already run into the fact that without a dec instruction, reducing a value would be impossible. Thankfully a software implementation allows for this change from uint16 to int16 with essentially no effort (I'll make an issue for that following this post). Finally with regard to Anyway lots of stuff to consider! |
|
Sorry I don't understand fully. You mean keep JMP but using a relative offset, which after switch from uint16 to uint16 would allow backwards and forward jumping? Or are you suggesting that JMP itself encode some conditional information? |
The actual |
It would be great to have a conditional relative branching as well because most loop kernels (the thing being iterated several times) are in the local scope of a relative branching. So we could have a special instruction to set a jump register to the result of a relative branching: |
I've been thinking more about this in the last week and I think it would be best to switch the ALU to work with a three-register form like you suggested. Also allowing for the program counter to be written directly is definitely seeming more and more appealing. I was misunderstanding before with the whole signed/unsigned representation - it's now obvious to me that any conversions from unsigned can happen within a given context (e.g. MVV). So the question is how to allow for such a number of new instructions. |
If so, any plan to revise a new ISA mapping? or do you want to keep the actual ISA and fill it with new instructions ? |
CMP
should should take 3 arguments: two comparison registers and result register. If the two comparison registers are equal, the result register is set to 1, otherwise 0.The text was updated successfully, but these errors were encountered: