10-04-2014, 03:28 AM
Safari crashed on my iPod, which is why this reply took so long, then I went out to dinner, then I spent time doing other stuff.
First off, I'm well aware what an instruction set is, I'm just bad with acronyms. I have never referred to an instruction set as an, "IS," so when you said that, I thought there was an IS component unique to redstone computers or a component I gave a different name to.
I know CISC is a blanket term (I actually don't know what defines the difference between RISC and CISC). In this case it means, "I don't actually quite have it worked out, but I have 44 operations I need this thing to perform, which is probably a lot more than any other minecraft computer, so I'll just call it CSIC." The actual opcodes aren't going to be created until after the computer is built, so that I can reverse engineer the whole system and have the codes mirror the processes that occur in the system, thus reducing the number of decoders.(I already know one typically does this the other way, buy my mind just doesn't quite work like that.) All I know is the first two bits of the opcodes, which will tell the CPU where to ship the information.
Memory space greater than 16 bits can easily be addresses using 16 bits and the secret sauce. Pointers are possible to write, but aren't needed, and not all the memory is registers or cache. There is an hierarchy that allows for addressing more than the bit space available to the word size. Although, I don't have a solution for fast registers yet...
Memory should only be around 19 ticks max to read or write, with nearer memory being faster. Special sauce is used here to fix that speed issue, and instant wire will fix bussing delays.
Now, I have discovered that memory actually does not induce lag, which makes sense if you think about it for more than two seconds and don't assume that anything you build with redstone automatically makes lag happen. The following things cause lag: sounds, light updates, block updates, complex rendering. If memory is really far away, you won't see or hear it, and there are no lighting updates because it isn't in render distance. The only time the blocks update are when it is being written to or read, in which case, only a very small part is actually updating. For memory in render distance: don't look at it. I'll make some images that show various frame rates for using it, looking at it, and looking away from it while standing near it. (Funny thing, if you stand inside it, you get a better fps than if you stand outside and look at it.)
The Von Newman architecture is why it needs so much memory, and more secret sauce makes sure the computer has the program data as it's needed.
The ALU uses some basic calculus to approximate large answers at a speed greater than what can be accomplished by other types of software implementations. (Mostly for division and any root, maybe real or complex)
The entire system could use two's compliment floating point encoding for large integers, or it will use standard binary if told to.
And most importantly: more than one computer can use the memory without any issues. This is where the secret sauce really gets lathered on there.
I'm willing to bet a few of you already figured out what the secret sauce is made of, and the only reason it is even there is so that the computer can be programmed in a language other than machine code (like c or maybe just assembly), but I discovered that this single piece would allow for all of these other magical properties to suddenly be available because it would make the CPU itself run much faster because it only really has to do one thing now: move memory between registers or cache. This is a five(ish) tick process.
There was something else I wanted to mention, but I have forgotten it now. No worries, though, you people will point out that I am an idiot because I forgot to mention that tiny detail.
I do suppose pipelining would be an option, but it would be more applicable toward the ALU than anything else. And this is just the first iteration anyway.
@LD, the only thin there I've never heard of is OOOexe.
First off, I'm well aware what an instruction set is, I'm just bad with acronyms. I have never referred to an instruction set as an, "IS," so when you said that, I thought there was an IS component unique to redstone computers or a component I gave a different name to.
I know CISC is a blanket term (I actually don't know what defines the difference between RISC and CISC). In this case it means, "I don't actually quite have it worked out, but I have 44 operations I need this thing to perform, which is probably a lot more than any other minecraft computer, so I'll just call it CSIC." The actual opcodes aren't going to be created until after the computer is built, so that I can reverse engineer the whole system and have the codes mirror the processes that occur in the system, thus reducing the number of decoders.(I already know one typically does this the other way, buy my mind just doesn't quite work like that.) All I know is the first two bits of the opcodes, which will tell the CPU where to ship the information.
Memory space greater than 16 bits can easily be addresses using 16 bits and the secret sauce. Pointers are possible to write, but aren't needed, and not all the memory is registers or cache. There is an hierarchy that allows for addressing more than the bit space available to the word size. Although, I don't have a solution for fast registers yet...
Memory should only be around 19 ticks max to read or write, with nearer memory being faster. Special sauce is used here to fix that speed issue, and instant wire will fix bussing delays.
Now, I have discovered that memory actually does not induce lag, which makes sense if you think about it for more than two seconds and don't assume that anything you build with redstone automatically makes lag happen. The following things cause lag: sounds, light updates, block updates, complex rendering. If memory is really far away, you won't see or hear it, and there are no lighting updates because it isn't in render distance. The only time the blocks update are when it is being written to or read, in which case, only a very small part is actually updating. For memory in render distance: don't look at it. I'll make some images that show various frame rates for using it, looking at it, and looking away from it while standing near it. (Funny thing, if you stand inside it, you get a better fps than if you stand outside and look at it.)
The Von Newman architecture is why it needs so much memory, and more secret sauce makes sure the computer has the program data as it's needed.
The ALU uses some basic calculus to approximate large answers at a speed greater than what can be accomplished by other types of software implementations. (Mostly for division and any root, maybe real or complex)
The entire system could use two's compliment floating point encoding for large integers, or it will use standard binary if told to.
And most importantly: more than one computer can use the memory without any issues. This is where the secret sauce really gets lathered on there.
I'm willing to bet a few of you already figured out what the secret sauce is made of, and the only reason it is even there is so that the computer can be programmed in a language other than machine code (like c or maybe just assembly), but I discovered that this single piece would allow for all of these other magical properties to suddenly be available because it would make the CPU itself run much faster because it only really has to do one thing now: move memory between registers or cache. This is a five(ish) tick process.
There was something else I wanted to mention, but I have forgotten it now. No worries, though, you people will point out that I am an idiot because I forgot to mention that tiny detail.
I do suppose pipelining would be an option, but it would be more applicable toward the ALU than anything else. And this is just the first iteration anyway.
@LD, the only thin there I've never heard of is OOOexe.