• Please review our updated Terms and Rules here

Optimal Instruction Set for Homebrew Computer?

mmruzek

mmruzek

Experienced Member
Joined
Sep 28, 2011
Messages
232
Location
Michigan, USA
Hi, I have built a homebrew computer using TTL IC's according to the architecture described by Eckert in his paper "Microprogrammed Versus Hardwired Control Units: How Computers Really Work". The architecture is shown in the attached diagram. It is a fairly basic machine with a 12 bit bus consisting of 8 data bits and 4 control bits. I built a hardwired controller for my first pass, and am in the process of doing some testing. To do the testing I am hand coding to create hex files that go into a 'ROM A' and 'ROM B'

The computer has 8 possible instructions. They are:

Symbol, Hex Value, Description
LDA* 1 Load Accumulator with data from the address given
STA* 2 Store Accumulator data at the address given
ADD 3 Add B to the Accumulator, store in Accumulutor
SUB 4 Subtract B from the Accumulator, store in Accumulator
MBA 5 Copy Accumulator to B
JMP* 6 Jump to new program count (Program counter modified)
JN* 7 Jump if negative flag is set. (Program counter modified)
HLT 8-F Halt by stopping clock. (Not currently functional)

‘Fetch’ N/A Clock ticks 0, 1 and 2 always load the next instruction
*Any command with an asterik requires a ‘ROM A’ address or program count value in the first 8 bits.

So, basically I am at the starting point of creating a working language from these commands. Before I proceed with that I started wondering if these 8 instructions are the best choice from a practical point of view. It would be easy enough for me to substitute or change an instruction at this point... so I am wondering if anyone has some thoughts about this? Probably my biggest concern is the conditional jump is based on the negative flag being set.

More information about the project is here

http://www.mtmscientific.com/stack.html

Michael

eckert_2.jpg comcom.jpg
 
mmruzek said:
It would be easy enough for me to substitute or change an instruction at this point... so I am wondering if anyone has some thoughts about this?
Click to expand...

- subroutines
- memory indexed addressing

the pdp-8 had the notion of auto-indexed memory locations, which you could use to implement index or stack registers in memory

it doesn't appear there is any mechanism to change microcode flow conditionally

you could also make greater use of the ALU operations in the F181 if you had an instruction that exported the ALU control bits
 
Last edited:
I assume that you've seen this OIC article.

Having programmed very CISCy and RISC mainframes, when everything is said and done, I don't see a lot of difference. I do see that your ISA lacks logical operations, although left-shifts are possible with the ADD instruction.
 
Carry functions or increment. You can get rid of either add or subtract but you do need a bit wise complement.
Dwight
 
Addition and subtraction are equivalent - one is sufficient.
All logical operations can be synthesized from NAND or NOR, so you want either one.
For subroutine support, you need to be able to store and recall the program counter.
 
On the subject of OISCs, consider TTA The interesting part is that the instruction set (one instruction) never changes, but you can add functionality quite simply.
 
As others have said, I would drop the ADD as it can be done using SUB and complement. Strictly speaking you don't need a complement instruction as it can be synthesized with SUB, however if you do I would recommend XOR as it can both complement and be useful for other purposes as well.

You could also use a few memory locations to store things such as:
  • PC - in which case you could drop JMP if you wanted
  • STATUS - for carry/overflow, zero, etc
  • PREVIOUS-PC - This would be useful to implement returnable subroutines by having the first routine of a subroutine store this address to jump to later

Best wishes


Lorry
 
I've been thinking some more and you could also remove HLT, because you would rarely use it compared to other instructions and could have a location to jump to instead which would provide the same function.
 
To be certain, opencores is a great place to discover interesting machine implementations.

Another low-instruction count "CPU" candidate might be the SMS/Signetics 8x300. A little strange, but found in lots of controllers--amd a 16-bit processor done in bipolar Schottky logic. Still available today, 45 years after introduction.
 
Thank you everyone for your thoughts and ideas on this topic. I have spent the past several days reading, thinking and exploring the suggestions.

The elephant in the room is the ALU. Here I have a great ALU that is only being used for 2 math functions. My thinking is that I could change the ADD command to an ALU command. The ALU command would setup the ALU using 4 control bits (S0, S1, S2 and S3), and the Mode (M) and the Carry (Cn). I could do the ALU setup by using a register programmed from the data byte space that accompanies the instruction. (12 bits: 8 data + 4 command). This approach would allow me to use all 16 math and logic functions of the ALU. However, it would make hand writing the code more of an exercise trying to keep track of everything. I have started a PCB layout to try this idea...

Some of the other things that I need to think about are making a way to read the Program Counter, and a way to PUSH and POP to a stack. For the stack, I have been thinking about a hardware inmplementation that auto-indexes during a read or write. Still thinking about that one.

Michael
 
mmruzek said:
The ALU command would setup the ALU using 4 control bits (S0, S1, S2 and S3), and the Mode (M) and the Carry (Cn).
Click to expand...

You may want to consider using a subset of the 181 bits in the opcode with a mapping prom.
It was common to do this in microcoded machines to reduce the number of bits needed since many of the functions aren't that useful.
 
Technically, the entire computer can be made with NAND or NOR operations and a shift left. You need one more instruction for flow control but like many bit slice, that can be combined with the operation. You might include the ability to just leave the result in the ALU register or write it out to RAM space.
So, the entire computer doesn't even need a 181 ALU. Another way of doing it is to just use a large ROM. There are a lot of combinations. You could even make the flow control and the operations in two or three EPROMs. The entire computer could then be completely reconfigured to try out different computer models.
The only thing most people don't get about EPROMs is that the output must be registered into a flop or latch. I've seen attempts where the output went directly to the address pins for the next step ( it always fails ).
Dwight
 
You must log in or register to reply here.
Back
Top