NLSC16 / CSC-16 My instruction set.

[Nickster258]

So, here is my instruction set:



This is my second iteration of this instruction set and I think it will do well for what it is designed.

My goal with this was to be simple, compact, and easy to program/understand. As I put a fair amount of study and thought into it (have been working on it for over a month), it seems that some of the "ease of understanding" was simple out-done with my ever-increasing knowledge of these things .I designed this RiSC IS with a mix of 6502 and MIPS. I believe that this IS is nice and versatile. This supports 8 registers, however register 000 is a blank register, always reading 0 when called.

With the IS having a 7 bit address, one can have up to 128 bytes of RAM which is specified by that address on were to save each word. With further manipulation, one can extrapolate an 10 bit address for SW and LW and increase the RAM capacity from 128 bytes to 1024 bytes, or 1KiB. An 8 bit CPU may not need 1024 bytes, but it would still be an interesting side for both execution and performance.

This CPU can perform basic tasks and even has capabilities for multiple I/O options. With the GPU function, a 10 bit address could be used both for a simple plotting of points on a 10x10 black&white screen. A simple GPU that can process line graphing, ellipse drawing, and even graphing of any 3-4-5-6 sided figure given only the coordinates of each point (basically line drawing but processing multiple lines at once.)

More branch functions could be added since the 4 bit function code will support up to 16 separate functions. Branching is done by using the 10 bit address for the prog the cycle after the branch is defined. Yes, this will take two cycles, but many other CPUs do.

I plan not only that this IS be used for minecraft CPUs, but also to be either built on a breadboard or on a simulator and have a decent clock speed.

Thanks,
Nickster258

Edit: I just saw a few typos. LUI, SW, and LW use type RI wit the 10 bit address. And type RRI has a typo. It is 7 bits, not 8.

[greatgamer34]

Like that there are screen ops, but what about interrupt support?

[Nickster258]

Like that there are screen ops, but what about interrupt support?

I was going to do that, but found little need. I may be able to incorporate it later under another opcode but I don't think there is enough room...

[Cutlassw30]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

[Nickster258]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

[Cutlassw30]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

Do you mean in terms of a branch delay slot? for example:

BEQ, R1, R5, 0x5
NOP

Or a compare before a branch:

CMP, R1, R5
BEQ, 0x5

MIPS uses the first way while x86 and ARM use the second. While they are not recommended if you can avoid them but if it allows you to add 13 more branches then go for it. Kind of a necessary evil

[Nickster258]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

Do you mean in terms of a branch delay slot? for example:

BEQ, R1, R5, 0x5
NOP

Or a compare before a branch:

CMP, R1, R5
BEQ, 0x5

MIPS uses the first way while x86 and ARM use the second. While they are not recommended if you can avoid them but if it allows you to add 13 more branches then go for it. Kind of a necessary evil

Either one actually. I am debating on making both of those plausible since I have so much room in the branch function.

[Cutlassw30]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

Do you mean in terms of a branch delay slot? for example:

BEQ, R1, R5, 0x5
NOP

Or a compare before a branch:

CMP, R1, R5
BEQ, 0x5

MIPS uses the first way while x86 and ARM use the second. While they are not recommended if you can avoid them but if it allows you to add 13 more branches then go for it. Kind of a necessary evil

Either one actually. I am debating on making both of those plausible since I have so much room in the branch function.

I perfer the second one to keep assembly closer the x86/z80 and ARM. Its more well known and easier to program. The first option is used to speed up pipelines.

[Nickster258]

This looks nice, im glad to see you're moving away from the microcoded style ISAs which directly interact with hardware.

I have a few gripes about it but meh, thats me the person who likes x86.

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

Do you mean in terms of a branch delay slot? for example:

BEQ, R1, R5, 0x5
NOP

Or a compare before a branch:

CMP, R1, R5
BEQ, 0x5

MIPS uses the first way while x86 and ARM use the second. While they are not recommended if you can avoid them but if it allows you to add 13 more branches then go for it. Kind of a necessary evil

Either one actually. I am debating on making both of those plausible since I have so much room in the branch function.

I perfer the second one to keep assembly closer the x86/z80 and ARM. Its more well known and easier to program. The first option is used to speed up pipelines.

That would probably be best. If I was to add branch functions, what should I add? BET, BGT, and BLT, is not many.

[Cutlassw30]

Thanks! I spent a long time just thinking about it and slowly making adjustments. I want my next CPU to be well planned out and have great functionality with good speed.

Is the fact that it will take 2 cycles to branch all that bad? I notice many use that and I can add 13 more branch functions if I wanted to, but it may not be worth it. (Plus others can add their own branch functions and have it somewhat customizable.)

Do you mean in terms of a branch delay slot? for example:

BEQ, R1, R5, 0x5
NOP

Or a compare before a branch:

CMP, R1, R5
BEQ, 0x5

MIPS uses the first way while x86 and ARM use the second. While they are not recommended if you can avoid them but if it allows you to add 13 more branches then go for it. Kind of a necessary evil

Either one actually. I am debating on making both of those plausible since I have so much room in the branch function.

I perfer the second one to keep assembly closer the x86/z80 and ARM. Its more well known and easier to program. The first option is used to speed up pipelines.

That would probably be best. If I was to add branch functions, what should I add? BET, BGT, and BLT, is not many.

I do not like BGT/BLT for one. For signed numbers you need a 2's complement comparator then for unsigned you're screwed. This is my current list of branches for my ISA:

Branch if equal to zero (BEQZ)
Branch if not equal to zero (BNEQZ)
Branch if greater than zero (BGTZ)
Branch if less than zero (BLTZ)
Branch if greater than or equal to zero (BGETZ)
Branch if less then or equal to zero (BLETZ)
Branch if odd parity (BOP) (used for checking data corruption)
Branch if even parity (BEP) (same as above but even parity)

Parity checking is checking the amount of one bits that are on. For example the number 101 is a even parity number because there is a even amount of 1s compared to 0s. This is really useful for checking for data corruption because one sends a extra "parity check bit" with data to compare it. In a odd parity checking system there is always a odd number of data bits on or there is a corruption. More of that here: http://en.wikipedia.org/wiki/Parity_bit

This is why ASCII was made to be 7 bits as the last bit could be used as a parity check bit.

[jxu]

I thought there was a noticeable omission of a jump (J) command. I'm basing my knowledge off of MIPS, I know it may not be the best option but if you choose to implement a stack, either hardware or software, you should include push/pop commands too.

[Nickster258]

Okay, so there are some current qwerks about my instruction set that need some attention so that it is in operable condition before I would strongly advice it to be used.

Some things like the omission of interrupts and the obvious incompatibility for a 10 bit immediate. I may need to add room for jump commands and other branch functions are not going to be a problem.(as I have room for 13 more xD)

[elliottjudd]

I can't handle it nick, my futile mind is blown.

[Jallen]

I may be being dim witted, but where does the 6-bit address come from in the branch command? as far as I can work our, you use: 3-bit op code, 2x 3-bit register adresses, 4-bit branch condition code... that leaves (16-3-3-3-4=)3-bits... I'm confuzd

[Nickster258]

I may be being dim witted, but where does the 6-bit address come from in the branch command? as far as I can work our, you use: 3-bit op code, 2x 3-bit register adresses, 4-bit branch condition code... that leaves (16-3-3-3-4=)3-bits... I'm confuzd

The branch address is defined in the register. One can LUI or ADDI+0 then save that data. To branch, it will simply read that data and save it to the counter register. So basically, write an immediate value and save it to a register. The comparing function would then compare/contrast the numbers, decide whether to branch or not, then write the immediate to the counter register.

I am working on this system a bit on my plot and I can show you next time I am online. It also works as a jump command.

Because of this, the computer easily supports up to 256 lines of ROM.

[Jallen]

I figured that you can cover push/pop/relative (jumping/branching) in a single op code. If you loop the current state of the PC into the read slot of the register address of the PC. You then have an op code that saves the current state of the PC plus an immediate to a register.

EDIT: you actually don't even need that, you can just use the ADDi again as long as the current state is addressable as the read.

EDIT: It seems I have some misconceptions about push and pop. They require a stack to be implemented but it would still be useful to have these functions