Forums - Open Redstone Engineers
My new and most thought out IS. - 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: My new and most thought out IS. (/thread-5218.html)

Pages: 1 2 3


RE: My new and most thought out IS. - GISED_Link - 12-13-2014

I think that if you have no opcode (00000) in the Instruction bus, that say that you have a huge error on the bus (it miss a redstone repeater, wires are too long, etc...). So I recommand to unuse the 00000 instruction (or use it to stop the computer and show a "stop" message).

And Addc and Subc is a good way to use the carry flag. By example :

I will add 2 numbers (unsigned) of 16 bits, with a 8 bit ALU. How can I proceed ?

Code:
Example :
  0011'0001 ' 1001'1010     //MSB  '  LSB
+ 0001'1000 ' 1110'0000
-----------------------
  0100'1010 ' 0111'1010

  1. I add the 2 LSB bytes (1001'1010 + 1110'0000)
  2. The result of this is 1'0111'1010, so you have a Carry out (carry is set to 1)
  3. You store this 8 byte value at Registre x
  4. So, the next instruction will be ADDC (add with carry) the 2 MSB bytes. With this you include the carry out of the previous operation. And the result will be 0100'1010 (with the carry !).
  5. You store this value at Registre x+1 (or x-1 ... depend of big or little Indian)



RE: My new and most thought out IS. - Chibill - 12-13-2014

I have registers resevered for the carry already I just have to make that sheet neat.


RE: My new and most thought out IS. - LordDecapo - 12-15-2014

(12-13-2014, 07:01 AM)GISED_Link Wrote: Aaaarg ! 00000 for NOP seems to be a bad idea. I really recommand to put the NOP instruction somewhere else and show an alert when the opcode (binary code of the instruction) is 00000.

And yes I think that addc and subc are very important.

No just no.. that means when ur not running anything at all, u will get an error. A noop should ALWAYS ALWAYS ALWAYS be 00000. So if u do something like pipeline and u have to stall, it simply just closes a read lock and nothing else can come though. Leaving the busses idling at 00000 during the stall, Hensel Noop.


RE: My new and most thought out IS. - GISED_Link - 12-15-2014

(12-15-2014, 05:10 PM)LordDecapo Wrote: A nop should ALWAYS ALWAYS ALWAYS be 00000. So if u do something like pipeline and u have to stall, it simply just closes a read lock and nothing else can come though. Leaving the busses idling at 00000 during the stall, Hensel Noop.

I've joined the HCS12 instruction set (not only the picture), made by Freescale. See by yourself, NOP isn't at 0x00. Here, 0x00 is used to put the CPU in background mode.

[Image: 713407Exemplekl26.jpg]

You can set NOP at 0x00, but I suggest to put something else (that shows something special for the user). With that, when a problem happens with the instruction bus, you will immediately know where the error is and you will earn a lot of time. Or use NOP and turn on a Redstone lamp...

But you are lucky, with Minecraft you can do whatever you want.

[Image: 468143KCPSM3InstructionSet.jpg]
Here, "000000" is a load instruction (see in the manual).
I've join a Instruction Set from a CPU coded in VHDL from Xilinx. And you can see that it doesn't have the NOP instruction. So ... We are fighting for something that doesn't matter at all XD.

I hope that those examples will help you (chibill).

By the way :
- I think that 3 kind of jump is not enough
- You can devide, but how can you store the remainder ?
- Same instruction? Why ? But why not... It's funny XD
- addc and subc... if you have the place to use those instructions, use them.
- INC, Increment a register


RE: My new and most thought out IS. - LordDecapo - 12-15-2014

dude,, a background mode is literally a noop with just a monitors for an interrupt or a system that only does low priority backround ops...
and those IS's are the rarity,,, 90% of the ones i look at have noop as 0000, as its 50x easier to set that way by default


RE: My new and most thought out IS. - GISED_Link - 12-16-2014

(12-15-2014, 11:54 PM)LordDecapo Wrote: and those IS's are the rarity,,, 90% of the ones i look at have noop as 0000, as its 50x easier to set that way by default

1. We must stop to discuss about the NOP.. . 6 posts about an instruction that do nothing is really enough
2. Please post here a IS where NOP is set at 0x00. I'm sure that will be intersting to see one of them in my life...
3. X86 Opcode : NOP is at 0x90,
4. European logic != American logic Big Grin

Anyway. I don't recommand to use the 0x00 bytecode if you have enough free bytecode in your IS


RE: My new and most thought out IS. - Chibill - 12-16-2014

Still using 00000 as noop as it is how I learned from a book on making your own computer that was printed in 1980.


RE: My new and most thought out IS. - LordDecapo - 12-17-2014

^ and all tutorial and learning CPUs I have read about, both euro and Us..
also here: Nop Wiki
note that
MIPS, Intel 8051, ARM A32, Z80, and the PIC microcontroller all use 0 as Nop.


RE: My new and most thought out IS. - Chibill - 12-18-2014

I am thinking about deleting this topic and reposting it after I finish the memory map.


RE: My new and most thought out IS. - TSO - 12-23-2014

I should like to state (after my long hiatus) that I agree with GISED_Link to some extent. You should try to avoid mapping a real opcode to 0x00 if you have the room in your IS to do so. Then, you can map a memory read error or a STOP to the opcode of 0x00. If you have microcoding, then not having a 0x00 opcode becomes more important because much of the math that most microcoding performs can have issues working around zero for either pointers or opcodes. In programming, a common practice is to set something to zero (like a pointer), perform an allocation, and then see if it isn't zero, meaning that it worked, or is zero, meaning that it failed and it's time to perform the exception routine and commit software suicide. In microcoding, a similar thing happens, you allocate 0 to the micro-operation being considered, allocate a temporary space for it on the table (at zero, oddly enough), then run the opcode through the tabling program, and it gives it a nonzero micro-operation in return at a nonzero table address for your instruction pointer to work with. If zero remains in either location, you know you have a problem, but if zero actually is something that can be returned as a valid and useful output, then it's your best guess as to whether or not your allocation worked or failed. Therefore zero is a common sign of an error in allocations and basically all other programs, to the point that x86 has a FLAG that is set if the output is zero simply because a zero output is bad juju. So, from a programming standpoint, I would say to avoid zero for consistency, if nothing else.

Now, for your computer, a really nice thing about mapping STOP to 0x00 is that an opcode execution could be wired as the bitwise OR down the entire opcode AND'ed with the clock all added to the instruction pointer with ADDC being invoked by a starting signal (basically: if there is an opcode at line x or a start signal at any point, push 1 to the carry in of the instruction pointer accumulator). This is a convenient way to make the STOP opcode 0x00 without adding any loss to overall throughput and adding one phase to the instruction pointer's pipeline. It is therefore unrelated to the execution pipeline and gives you an opcode usually reserved for a microcoded environment.

LordDecapo Wrote:I do like the repeat inst. Is there a way to tell it to repeat like several instructions in a row over and over? Like "repeat inst 1,2,, and 3, 10times"?

I can tell you how to do it in general pretty easily, it will take me a bit of thinking to put it in terms of this specific instruction set. I have to be somewhere right now, but tell me what you want to know and I'll explain it (this one is fairly simple in it's general form on a stack machine.)