Clocked ADD, SUB

[larsbrinkhoff]

New ADD, SUB, and fixed flags in NEG, NEGX, NOT.

[larsbrinkhoff]

These are the first instructions with one ea operand and one register operand.

[larsbrinkhoff]

Also, if the destination is a data register, there may be 2 or 4 additional cycles. This isn't handled very prettily. The four extra arguments to ea_begin_modify doesn't help much here.

[stefanberndtsson]

2 or 4 additional cycles compared to what?

[larsbrinkhoff]

After the last prefetch, when writing a long. See the Yacht table for ADD and SUB.

[stefanberndtsson]

Should that really be handled through the EA? Isn't that just because the ALU is 16bit and there aren't enough 'n':s to handle a 32bit addition without them?

[larsbrinkhoff]

I'm saying the current solution isn't satisfactory.

[stefanberndtsson]

In that case, I would suggest moving the additional cycle bits into the ADD/SUB states. This should pop up in several other instructions as well, I'd imagine.

[larsbrinkhoff]

I'm trying to save us some work by having ea_begin_modify help out. It could handle the extra cycles without having to add explicit states in the instructions.

But those four arguments should go away.

[larsbrinkhoff]

I have a vague idea that the instruction state machines could be replaced with some microcode like the EA calculation. This would probably solve the problem with varying cycle counts for operand writes using ea_begin_modify.

[stefanberndtsson]

Yes, I was thinking about this a bit last night.

I'm sort of leaning towards EA not having its own state machine. ucode should be able to be the state machine, and each instruction is responsible for building the state chain (or modifying it live).

EA is then responsible for being something macro-like that provides part of that state chain, instead of actually running it.

Pretty much all instructions should need only the following:

• nop
• prefetch word
• read word from bus
• write word to bus
• perform instruction operation (this varies between instructions of course)

Pretty much all instructions also do the following (each one could be optional):

1. prepare things before execution
2. do source EA
3. do some calculation on value from EA
4. do dest EA (can be same as source)
5. finish up afterwards

Is there any instruction opcode and cpu-register state where it cannot be known upon initial execution of the instruction what the entire state chain would look like?

[stefanberndtsson]

I wrote a more concise (I think :)) proposal regarding this in https://github.com/nocrew/ostis/issues/143

[larsbrinkhoff]

I had a similar idea today, so I think we basically agree. I'll reply in #143.

Can we merge this now, and fix it later?

[stefanberndtsson]

Indeed we can.