Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Optimal Instruction Set for Homebrew Computer?

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,572
    Blog Entries
    18

    Default

    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.

  2. #12

    Default

    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

  3. #13

    Default

    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.

  4. Default

    Just ran across this description of a CPU implemented in a 32-cell CPLD. They get by with four instructions.

    https://lniv.fe.uni-lj.si/courses/iv/mcpu.pdf

  5. #15
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,572
    Blog Entries
    18

    Default

    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.

  6. #16
    Join Date
    Sep 2011
    Location
    Michigan, USA
    Posts
    188

    Default

    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

  7. #17

    Default

    Yeah, that makes sense, and also frees up an instruction (SUB) for something else.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  8. #18
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,572
    Blog Entries
    18

    Default

    It's a shame that SN74S481s are so hard to come by. They'd make a great alternative to the 181.

  9. #19
    Join Date
    Sep 2006
    Location
    Silicon Valley
    Posts
    2,291

    Default

    Quote Originally Posted by mmruzek View Post
    The ALU command would setup the ALU using 4 control bits (S0, S1, S2 and S3), and the Mode (M) and the Carry (Cn).
    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.

  10. #20

    Default

    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

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •