Remove port instructions

[jdryg]

Thinking about the Port Controller and how BENs can communicate, I have a feeling that separate port instructions might not be needed afterall.

[jdryg]

Possible implementation

TIS-100	This CPU
MOV reg/imm, port	ADD port, NIL, reg/imm
MOV port, reg	ADD reg, port, NIL
MOV port, port	???
ADD port	ADD ACC, port, ACC
SUB port	???

3 out of 5 instructions can be implemented with the current CPU design.

MOV port, port is problematic. We need a new ADD instruction which will indicate that both dst_isPort and srcA_isPort are 1. Currently, port instructions only raise one of the two, depending on whether it writes or reads from the port.

SUB port is also problematic. The problem is that srcB cannot be a port (only 2 bits long), so the only solution will be another instruction indicating that the subtraction should be reversed. Instead of d = a - b the new instruction will be d = b - a. Otherwise, the second source operand should be extended by 1 bit to be able to hold any of the available ports.

So, in order to implement the above instructions in one cycle, the operation part of the instruction for Instruction Type = 01 should be able to take the following values:

1. 000: ADD with dst_isPort = 0 and srcA_isPort = 1 (this is the same as RDP)
2. 001: ADD with dst_isPort = 1 and srcA_isPort = 0 (this is the same as WRP)
3. 010: ADD with dst_isPort = 1 and srcA_isPort = 1 (new operation)
4. 011: SUB for the inverse subtraction. (new operation)

Last but not least, the ALU should change to support the new SUB instruction. This also means that the aluOp signal should be extended by 1 bit, because we already have 4 operations (ADD, SUB, NEG and SLT).

[jdryg]

Tried it. Apparently there is a synchronization issue between the ALU and the port writer.

In Sample program #3 when the UP port writes the following sequence:

0,1,2,3,4,5,6...

The first value written to the LEFT port is 6, eventhough the ALU after the 3rd instruction "correctly" (*) calculates 0. Debugging didn't help, so I'll leave it at the moment and come back later.

(*) I say that 0 is correct eventhough someone might expect the correct value is -1 (0 + 1 - 2), because the first 0 is ignored due to the reset period of the BEN. So the actual calculated value is 1 + 2 - 3 = 0.