+- 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: In Progress (https://forum.openredstone.org/forum-20.html)
+---- Thread: We Suck At MC Computers :/ (/thread-789.html)
We Suck At MC Computers :/ - WrytXander - 08-20-2013
Hello everyone, I just wanted to post this thread of me thinking about somethin for quite a while now.
As you all know, the level we are at with programming our MC Computers are pretty low level. To be spesific, we are just programming machine code, right into the memory, with 1's and 0's. The only way we could get the high level programming experience is by developing fast and reliable MC Computers. Now here are (what I think) the ways we can make them faster, and what people seem to be doing wrong (in my opinion again):
Tradeoffs at ISA and Microarchitecture (uArch) Level
There are quite a few ways we can improve our Instructions. But the question is, were do we start? Lets think of a complex instruction, for example branching. People have been using branching in MC computers for quite some time now. But is there a better way of doing it? What we basically do (generally speaking) is say "Branch to the instructions at line 22 if Register A's content is equal to the contents of the Register B" Well this is simple right? We just send the "22" to the Program Counter register and demux between program counter value and the IP (Instruction Poiter) we defined in the program. If the given condition is true, PC register is loaded with "22", if not, we continue the normal cycle. Now, this is one way of doing it. But there are several more ways to perform "Conditional Execution". One is branch predictors, which is not very easy in MC :D. The other and the simpler way of doing is, is what its called using "Condition Codes" or the way ARM Architecture describes it, "Conditional Execution". Basically there is one bit, that tells if the following code is going to be executed or not. This is way simpler, becouse it needs less hardware, and it makes programmers job easier.
Another thing I want to point out is Instruction Sets. Now lets be honest, 70% of the people do not know how to make Instruction Sets, that are optimized for their needs, and the capabilities of their hardware. Now please someone tell me, why would you use a CICS architecture while you do not know how to do multiplication, calls/interrupts, and such complex tasks. Why would you acquire such complex tasks if it cant even be programmed efficiently for a simple fibonacci sequence. So this is my point here, I really think that it is pretty idiotic, to go for a CICS arch. before we make our computers practical, by that I mean it should actually take max. 2 seconds to execute a single instruction. So what I am trying to say, is people are using diffrent IS's that actually does not make sense, becouse it is not well optimized for their needs and their hardware, they give them names like SAARMCISC or something, so please please please, if you are reading this, think on your IS more deeper before you start your next Computer project :))
We could even try diffrent uArch systems, such as dataflow, or a more proper Von Neumann then we are using today.
If we want to program our MC Computers more efficiently and with more High-Level we should fix what is lying underneath, the ISA and uArch!
I could talk about this more and more (like how people put 9856748 bytes of RAM and only use 3 of it, how people put all the logic operations in their IS's and much more :D) but it would take a book for me to do that. So instead, please tell me what is your take on this one, and lets discuss on those. Thanks for reading this big mess text :D
Leave yo comments!
RE: We Suck At MC Computers :/ - CMOSprinkles - 08-20-2013
Gah, who actually uses CISC? It would have ridiculously slow instruction cycles. I think you totally forgot to talk about RISC architectures, which a few people are starting to use. I don't think it would be possible to implement a finer IS like MISC in minecraft, and RISC IS's are far more practical for our uses. I definitely agree that instruction cycles need to be at least 2 seconds if not faster for a practical computer. As for the branching, I'd like to hear more about these "Conditional Codes", that sounds like a much better way of handling that task.
RE: We Suck At MC Computers :/ - bannanalord - 08-21-2013
RISC Gang or die.
RE: We Suck At MC Computers :/ - Chibill - 08-21-2013
Me and hime are using the zilog 80's IS in MCX.
RE: We Suck At MC Computers :/ - Thor23 - 08-22-2013
I was under the impression that most people made their own instruction sets that were suited to their hardware. That's what I did, though I think that I might be a bit different in that I planned out the entire thing before I even started building.
And actually, on the topic of instruction sets, how would something like networking work? We can't just all have our own ways to send data across the network, we'd need something that we'd all agree on. A standard, if you will.
RE: We Suck At MC Computers :/ - Chibill - 08-22-2013
We are using the Z80.s because its all ready there and many people know about it and there's a assembler so we can write the assembly version of the code.
RE: We Suck At MC Computers :/ - WrytXander - 08-22-2013
(08-20-2013, 08:20 PM)CMOSprinkles Wrote: Gah, who actually uses CISC? It would have ridiculously slow instruction cycles. I think you totally forgot to talk about RISC architectures, which a few people are starting to use. I don't think it would be possible to implement a finer IS like MISC in minecraft, and RISC IS's are far more practical for our uses. I definitely agree that instruction cycles need to be at least 2 seconds if not faster for a practical computer. As for the branching, I'd like to hear more about these "Conditional Codes", that sounds like a much better way of handling that task.
Hahaha, there are some people that "try" cisc. And I didn't want to talk about RISC since it would take more than a day for me to write "What are wo doing wrong with RISC" kinda stuff. Yeah, ofc, RISC is the way to go for now. But really, there is only a handful of people that can really optimize their IS's. What I tried to say was that people actually use like already existing archs, and build around that. What should have been the case is: you define what your hardware capable of, then define what is your goal. Say, is it speed of cycles, is it the complexity of instruction, or finding where those two meet. And then you build your IS, which you select between ISA's. Like RISC. SISC and all that theories.
(08-21-2013, 01:33 AM)bannanalord Wrote: RISC Gang or die.
Hell yeah gangsta!
(08-22-2013, 01:25 PM)Thor23 Wrote: I was under the impression that most people made their own instruction sets that were suited to their hardware. That's what I did, though I think that I might be a bit different in that I planned out the entire thing before I even started building.
And actually, on the topic of instruction sets, how would something like networking work? We can't just all have our own ways to send data across the network, we'd need something that we'd all agree on. A standard, if you will.
If you are doing that well done boy!! Really! I mean, I know I had hard times sleeping thinking of ISA's nonstop. I have replied to another fellow, read that, that was what I meant when I was trying to say when stating that it was the premade IS that decides the hardware sometimes.
And the networking! That is just a huge ass topic, but I could explain briefly. The way It would work, is very close to whatyou have said actually. We dont have to agree on a common IS ofcourse, but we would build assemblers or converters if you will, that will convert your computers IS, into a shared higher-level protocol. So that nobody has to modify their computers to support this protocol.And if we talk about thw connection, well that is the cheesy part :D DOing that ingame requires the computers to be in the same world, and with command blocks. If we choose to make it off-game (which sounds harder, but would be much practical, since internet is already there for us) we would use plugins for servers, or mods for singleplayer. Becouse I dont think there is a way to read out redstone signals, or any kind of data off of the game dynamically. That would lead us to off game assemblers and even compilers for known high level programming languages
RE: We Suck At MC Computers :/ - WrytXander - 08-22-2013
(08-22-2013, 03:19 PM)Chibill Wrote: We are using the Z80.s because its all ready there and many people know about it and there's a assembler so we can write the assembly version of the code.
Now that is logical and makes sense, since it is well optimized and as you said aseemblers are there. I dont know why people love using IS s that they find on university lab session sheets.. I mean yeah go ahead and use the IDEA, not the whole IS, :D They are reall life, this is MC and real life and mc can differ quite a lot
RE: We Suck At MC Computers :/ - Chibill - 08-22-2013
And we are baseing part of the MCX system off the Z80. Like Doing some 16 operations on the 8 bit CPU.
RE: We Suck At MC Computers :/ - WrytXander - 08-22-2013
(08-22-2013, 08:02 PM)Chibill Wrote: And we are baseing part of the MCX system off the Z80. Like Doing some 16 operations on the 8 bit CPU.
Oh wow ! I suggest you make a fresh MCX post, since that project is pretty worthwhile.
But yeah, post yo comments and I will make a version 2 of this post, which will be a little more wide-range!