NLSC16 / CSC-16 My instruction set.

NLSC16 / CSC-16 My instruction set. - Printable Version

+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: Completed Projects (https://forum.openredstone.org/forum-21.html)
+---- Thread: NLSC16 / CSC-16 My instruction set. (/thread-3314.html)

Pages: 1 2

NLSC16 / CSC-16 My instruction set. - Nickster258 - 04-29-2014

So, here is my instruction set:

[Image: lCvfUb5.png]

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.

RE: NLSC16 / CSC-16 My instruction set. - greatgamer34 - 04-30-2014

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

RE: NLSC16 / CSC-16 My instruction set. - Nickster258 - 04-30-2014

(04-30-2014, 02:47 AM)greatgamer34 Wrote: 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...

RE: NLSC16 / CSC-16 My instruction set. - Cutlassw30 - 04-30-2014

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.

RE: NLSC16 / CSC-16 My instruction set. - Nickster258 - 04-30-2014

(04-30-2014, 04:31 PM)Cutlassw30 Wrote: 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.)

RE: NLSC16 / CSC-16 My instruction set. - Cutlassw30 - 04-30-2014

(04-30-2014, 04:48 PM)Nickster258 Wrote:
(04-30-2014, 04:31 PM)Cutlassw30 Wrote: 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

RE: NLSC16 / CSC-16 My instruction set. - Nickster258 - 04-30-2014

(04-30-2014, 05:34 PM)Cutlassw30 Wrote:
(04-30-2014, 04:48 PM)Nickster258 Wrote:
(04-30-2014, 04:31 PM)Cutlassw30 Wrote: 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.

RE: NLSC16 / CSC-16 My instruction set. - Cutlassw30 - 04-30-2014

(04-30-2014, 06:08 PM)Nickster258 Wrote:
(04-30-2014, 05:34 PM)Cutlassw30 Wrote:
(04-30-2014, 04:48 PM)Nickster258 Wrote:
(04-30-2014, 04:31 PM)Cutlassw30 Wrote: 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.

RE: NLSC16 / CSC-16 My instruction set. - Nickster258 - 04-30-2014

(04-30-2014, 06:29 PM)Cutlassw30 Wrote:
(04-30-2014, 06:08 PM)Nickster258 Wrote:
(04-30-2014, 05:34 PM)Cutlassw30 Wrote:
(04-30-2014, 04:48 PM)Nickster258 Wrote:
(04-30-2014, 04:31 PM)Cutlassw30 Wrote: 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.

RE: NLSC16 / CSC-16 My instruction set. - Cutlassw30 - 04-30-2014

(04-30-2014, 06:42 PM)Nickster258 Wrote:
(04-30-2014, 06:29 PM)Cutlassw30 Wrote:
(04-30-2014, 06:08 PM)Nickster258 Wrote:
(04-30-2014, 05:34 PM)Cutlassw30 Wrote:
(04-30-2014, 04:48 PM)Nickster258 Wrote: 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.