Replace JMP with a CMP instruction, and rename JMR to JMP

[francisrstokes]

Replace JMP with a CMP instruction, and rename JMR to JMP

[hlide]

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.

JZ D, V : jump to IP+sext12(V) if D is 0.
JNZ D, V : jump to IP+sext12(V) if D is not 0.
JZR D, S : jump to S if D is 0.
JNZR D, S : jump to S if D is not 0.

then

SETLT D, A, B : Set Less Than, D = signed(A) > signed(B) ? 1 : 0
SETB D, A, B : Set Below, D = unsigned(A) > unsigned(B) ? 1 : 0
SETNE D, A, B : Set Less Than, D = (A != B) ? 1 : 0
SETZ D, A : Set if Zero, D = A ? 0 : 1

the other parts can obtained by inverting D and S and/or using SETZ to invert boolean

SETGT D, A, B :  SETLT D, B, A
SETGE D, A, B :  SETLT D, A, B; SETZ D, D
SETLE D, A, B : SETLT D, B, A; SETZ D, D

SETA D, A, B :  SETB D, B, A
SETAE D, A, B :  SETB D, A, B; SETZ D, D
SETBE D, A, B : SETB D, B, A; SETZ D, D

SETEQ D, A, B : SETNE D, A, B; SETZ D,D 

And Jcc now:

JLT A, B, V: SETLT T, A, B; JNZ T, V
JGT A, B, V: SETLT T, B, A; JNZ T, V
JGE A, B, V: SETLT T, A, B; JZ T, V
JLE A, B, V: SETLT T, B, A; JZ T, V

JB A, B, V: SETB T, A, B; JNZ T, V
JA A, B, V: SETB T, B, A; JNZ T, V
JAE A, B, V: SETB T, A, B; JZ T, V
JBE A, B, V: SETB T, B, A; JZ T, V

JEQ A, B, V: SETNE T, A, B; JZ T, V
JNE A, B, V: SETNE T, A, B; JNZ T, V

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...

[francisrstokes]

My thinking was along the lines of having a non-jump based comparison CMP essentially for flag setting. Then JLT which currently has 8 unused bits would become a general conditional jump instruction in the form:

JCP R1, R2, R3, Op (Jump ComPare)

R1 is compared against R2, and the jump address is stored in R3. Operation will be in the list:

• Equal
• Not equal
• Less than
• Greater than
• Less than or equal
• Greater than or equal
• Zero (in which case R2 is ignored)
• Not zero (in which case R2 is ignored)

The final 3 bits I'm not sure. An offset of up to 7 doesn't seem that useful.

[hlide]

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 ADD D, S, T instead of ADD D, S.

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 CMP and your JCPwork. Wouldn't it be something like 'CMP D1, S1, T1; JCP D1, S2, O, that is D1is a bitmask set byCMPandJCPwill try to matchD1and Oto see if condition is true? having JCP R1, R2, R3, Op` seems to imply it is a native instruction and not a pseudo.

Moreover, I can see this instruction is always followed by two instructions to set R3 which is a big cost.

[hlide]

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.

[francisrstokes]

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 CMP and JCP: JCP replaced the JLT instruction - the existing conditional jump instruction. CMP would replace JMP V which would jump directly to literal 12 bit address. However thinking that through in signed terms, that could better be a 12 bit signed offset from the instruction pointer, right?

Anyway lots of stuff to consider!

[hlide]

JMP V: if relative branch, you could place your code anyway unlike the actual version.

[francisrstokes]

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?

[hlide]

The actual JMP V jumps to an absolute address between |0..4095], right? so you're condemning the access of the code beyond 4095 whereas your memory is between [0..65535]. If you use a relative branching instead (that, is: PC + sext12(V)), you can jump from anywhere in the memory to a relative place between [-2048, +2047] which should be enough for local forward/backward branching and you are not blocked in the first [0..4095]. You can still jump to absolute address (so beyond the relative branching scope) through a register.

[hlide]

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:
ADDPC D, V|VVVVVVVVVVVVDDxxxx| Set the effective address of PC added by a sign-extended 10-bit immediate value to destination register
Doing so, you only need 2 instructions instead of 3 to make a conditional relative jump: ADDPC R3, V; JCP R1, R2, R3, O. In most CPU architecture I know, PC points to the adjacent instruction when an instruction reads PC and set it to a register. Right now, you need to do so: LDV16 R3, label; JCP R1, R2, R3, O which cost 3 instructions.

[francisrstokes]

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.

[hlide]

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 ?