Opcode mods

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply
PurpleGirl
Posts: 38
Joined: 09 Sep 2019, 08:19

Opcode mods

Post by PurpleGirl » 22 Nov 2019, 01:01

In the past, I mentioned a way to use a spare NOP as a way to signal an external device, such as resetting a video circuit if you don't know the state. You could make a crude decoder to NOR the pins that are supposed to be off and AND them with the ones that belong on for your instruction. The NOPs do nothing, so they can trigger outside devices. Just leave one NOP as it is.

But then last night, an idea came to mind. There could be a way to expand the opcodes to have other instructions. Use 2 NOPs to do shifting. So one NOP switches in other control circuitry and another switches the original circuitry back. Thus a group of opcodes can do different things when shifted. Just save the ones used by video and the most commonly used IP-related instructions (like branches).

User avatar
marcelk
Posts: 433
Joined: 13 May 2018, 08:26

Re: Opcode mods

Post by marcelk » 22 Nov 2019, 07:11

The processor has no chips with hidden state. Therefore with the right programming and sometimes some extra decoding logic, you can trigger external devices from practically any signal on the board. There are many examples out there that do just that.

The XOUT register is a good example. After all, XOUT is an external device to the processor. The RAM and I/O expander is another good one, but it needs 3 new chips. A third example is how we used A15 to drive an LED in one of the first breadboard videos.

You can also use 3 output pins from XOUT to drive a chain of 74HC595 shift registers. That gives an unlimited number of output lines, 8 for each in the chain.

HG has designed a completely different decoding scheme (but not built it yet). I believe it's even part-neutral.

Anything goes.

PurpleGirl
Posts: 38
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 22 Nov 2019, 20:24

Yeah, I thought the concept of CPU escape sequences would be interesting. So intercept 2 of the unused NOPs and piggyback onto them. One of them switches out some of the control circuitry to allow for opcodes to be recycled to add additional functionality. The other piggybacked NOP switches the original circuitry back in and returns all opcodes back to their original functionality. Of course, besides the components, the cost would be 2 cycles, 1 for setup and 1 for cleanup. Plus it could make code a tad more confusing. So it would look a bit like this.
  • ALT NOP 1; enter alternative opcode set
  • New instructions that duplicate opcodes, perhaps 32 of them or some other even group of 16.
  • "
  • "
  • ALT NOP 2; return to original instructions
Some caveats would be not interfering with anything used by the video, the program counter, or any "interrupts," and the added functionality should justify the cost of changing modes/contexts. Plus the branch quirk would need to be taken into account when coding to not run the affected opcodes in the wrong context after a branch.

This idea is nothing new. The x86 processors did this. For instance, to do MMX and similar on the Pentium, they swapped out the entire FP set. The setup was costly to use the new multimedia or signal processing instructions. So programmers would make sure that the performance gained by the newer instructions would justify changing modes. Even for DOS programming, you could use the new 32-bit instructions of 386 and higher CPUs in real mode. They used an escape sequence to use the new instructions.

PurpleGirl
Posts: 38
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 19 Dec 2019, 08:41

Another mod that came to mind, though likely not attractive to use, would be replacing most of the instruction decoder with a ROM. The instruction register can drive the address lines and the data lines drive the control lines. So this replaces the logic with an instruction map. There would be no speed advantage, but you'd need a fast dedicated ROM (or two if 16-bits isn't wide enough, though they don't need to be deep) for this if you want to overclock.

The only advantage of this approach would be the ability to arbitrarily assign opcodes. Of course, if I were to do this, I'd leave all the used ones as they are for compatibility and only replace duplicated (about 62 if I remember right from the last time I counted) or nonsense opcodes. That would give room for things like more access modes, ability to copy between more registers, additional ALU instructions, or even additional registers. There would be no reason to add instructions to clear registers or set them to arbitrary values due to the Harvard architecture. In fact, the opcodes for assigning 0 could be fair game to change since they are no faster than assigning from immediates.

The above is the simplest implementation. However, this can be more complex. For instance, the map could be copied to fast SRAM and shadowed there. And perhaps better yet, there may be hybrid ROM/SRAM.

monsonite
Posts: 63
Joined: 17 May 2018, 07:17

Re: Opcode mods

Post by monsonite » 28 Dec 2019, 12:09

Hi PurpleGirl,

Using a ROM as the instruction decoder is an often used approach, but the problem is with the speed an instruction can be decoded.

Fast ROMs are not very common these days and the AT27C1024 from Microchip/Atmel has an access time of 45nS. You might find that you could sample a batch of them and find some that are faster, you might even get down to 30nS.

It would be a great way of obtaining 16 hardware control lines from either an 8-bit or 16-bit instruction field.

I have had similar thoughts for a TTL machine I am currently working on - and will experiment with the 27C1024.

This will be future work for 2020


Happy New Year to Everyone in the Gigatron Community


Ken

PurpleGirl
Posts: 38
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 18 Jan 2020, 18:22

A clarification. I've never said that the CPU has any hidden states. My idea to piggyback onto a NOP instruction is only for external devices. For instance, if an external video controller is used and there is the chance of losing the syncs or not knowing where the raster is, one of the spare NOPs could be used as a signal to reset the video controller.

User avatar
marcelk
Posts: 433
Joined: 13 May 2018, 08:26

Re: Opcode mods

Post by marcelk » 18 Jan 2020, 20:36

Thanks for clarifying. The only point I tried to make is that if you want to create extra output signals, every flip-flop's output on the board is exposed (as "bare metal you can solder to") and available for tapping into. None are hidden behind a buffer for example, as in many other designs. Therefore you don't need to restrict yourself to the IR flip-flop outputs. That's all.

Maybe I misunderstand, but if you reset a video controller while it is active, most screens will black out for a couple of seconds. Screens don't like discontinuities in the sync signals they receive. The more modern ones even less so than older ones. Just a caution.

PurpleGirl
Posts: 38
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 22 Jan 2020, 02:14

Thanks, now I understand. And yes, I didn't think of that issue. But an external device reset pin could still be of use. In the case of a video card, it could instead signal to not display data until the next frame. So if it has memory, it can then load the memory from the start without display until the next v-sync. I was trying to find out how to get around not signaling back from the video device.

---

Most of the NOPs and AC=0 ops are ones where a load, store, or ALU op is being done on AC with itself. I'm familiar with similar in Intel architecture. For instance, since most memory ops took 3-7 cycles (with the stack ops being the fastest), if you could use the ALU to do register only ops to assign to AX, it would be much faster. So Xor Ax, Ax is faster than MOV AX, 0. However, such ops are not needed here since we have the Harvard architecture, so ALU ops offer no speed advantage over register loads.

Post Reply