(10-03-2014, 10:39 AM)dylanrusell Wrote: Would you be kind enough to share your IS for your computer design or is that "secret sauce"?

(10-04-2014, 12:23 AM)TSO Wrote: I'm not using "command block bull shit". there are 256 chunks that never unload, I'm filling every single one of those, bedrock to sky, with memory, and then I'm filling half the load space with memory, bedrock to sky, than I'm putting the computer in the sky and placing more memory under it.

I probably know what the concept of IS is, I just don't know what the acronym stands for.

EDIT, it just occured to me you meant instruction set. CISC

Quote: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,

Quote: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)

(10-04-2014, 03:28 AM)TSO Wrote: 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.

(10-04-2014, 03:28 AM)TSO Wrote: 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.

(10-04-2014, 03:28 AM)TSO Wrote: 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...

(10-04-2014, 03:28 AM)TSO Wrote: instant wire will fix bussing delays.
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.

(10-04-2014, 03:28 AM)TSO Wrote: The ALU uses some basic calculus

(10-04-2014, 03:28 AM)TSO Wrote: The entire system could use two's compliment floating point encoding for large integers, or it will use standard binary if told to.

(10-04-2014, 03:28 AM)TSO Wrote: 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.

(10-04-2014, 03:28 AM)TSO Wrote: 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.

(10-04-2014, 03:28 AM)TSO Wrote: 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.

(10-04-2014, 03:28 AM)TSO Wrote: @LD, the only thing there I've never heard of is OOOexe.

(10-04-2014, 06:39 AM)TSO Wrote: Most of the instruction set actually just passes through the CPU, being routed to it's destination without any decoding at all.

(10-04-2014, 06:39 AM)TSO Wrote: Upon consideration, I could venture to say that if you stood back far enough from it and squinted real hard, you would see something that sort of looked like a pipelined CPU.

(10-04-2014, 06:39 AM)TSO Wrote: Also, just in case you still don't know the chunk loading thing I mentioned, I was talking about the spawn chunks. (Also, I had to look up what a command block was because I have never heard of them.)

(10-04-2014, 01:54 AM)LordDecapo Wrote: The best route is to do a pipeline CPU that is ATLEAST 10 tick clock

(10-04-2014, 06:39 AM)TSO Wrote: So when I say the CPU will work, it's because I don't even have a design yet that can be proven to not work, and we know CPU's exist that do work, so we can say it is possible for me to have a CPU that works in our hypothetical situation. Whether or not I designed it myself is irrelevant to the current conditions of the hypothetical.

(10-04-2014, 03:02 PM)LordDecapo Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: 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.

44 is ALOT, unless you have a HUGE IS that is just all your control lines bussed to one Program Memory bank, I highly recommend either finidng someones IS you like a lot on the server and then make yours based on there layout (only at first, you can change it 100%, but it will give you a great place to start) or you can throw together a quick one to make sure you have some of your CPU's functions predetermined,, it sucks adding a bunch of features to a CPU and realizing you only needed like 1/3 of them to actually do what all your IS needs.
An IS also helps define a lot of basic asspects of your CPU, making it almost a road map for how to build it with out ever touching hardware.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: 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...

how are you going to use more then 16bit addressing on a 16bit system? And be aware, you can make a CPU with as much memory as you want, but are you ever going to make a porgram that ACTUALLY uses it? Or could you program a tad bit better and have the program use your memory more wisely.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: instant wire will fix bussing delays.
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.

NO! instant wire bussing is a VERY VERY bad idea, I have seen many ppl (about half of which were long time MC CPU veterans) try and use it as one of those “cure all” solutions to bussing,, the timing will be hell, and you will end up wanting to pul ur hair out.
Also I personly dont ever use pistons.. in any CPU... ever... I hate them and there half tick nonsense and BUD glitches.. a Pistonless CPU (also called SS (Solid State) is much more predictible,
But if you like pistons and you want to use them, have at it just saying I personally dont like them at all.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: The ALU uses some basic calculus

“basic” is a very HARD word here...
Cause calculus isnt something that is normally done at a MC CPU level, due to the massive amount of ticks it will add to your CPU, and if ur only using a basic ALU to do these,, there will be a lot of time that it will be clogged preforming the “basic” task of your calculus.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: The entire system could use two's compliment floating point encoding for large integers, or it will use standard binary if told to.

2's comp is mainly for negitive, and floating point is decimal points (better known as Radix bits in binary) and you will need a good barrel shifter to be able to do FP well, I have a good design im working on if you want to use it.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: 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.

2 CPUs with one memory is a bad idea,, only do it if you have a system to manage memory that is independent from the CPU's themselves, otherwise you will have addressing confilicts and data hazards, as well as architectural hazards (more then 1 data packet wanting to go down same bus line at same time, and other stuff)

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: 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.

They may have but I have not figured this one out, but please tell me xD im curious.. and the way to make a CPU be able to be programmed in a higher lang, is by making a compiler and to have a GOOD IS that is small, yet feature rich, so you can easily port the coding in and out of the CPU's machine code.

LD Wrote:

(10-04-2014, 03:28 AM)TSO Wrote: 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.

just saying the ALU is like the ONLY place you do not pipeline like ever, I mean you can yes, but due to speed limitations in MC, it doesnt give you any speed advantage, and to pipeline an ALU, you have to have a good hazard detection system and possibly OOOExe,, considering the delay of an OOOexe system,,, unless you make a milestone discovery it wont be beneficial to your clock speed/throughput.

LD Wrote:

(10-04-2014, 06:39 AM)TSO Wrote: Most of the instruction set actually just passes through the CPU, being routed to it's destination without any decoding at all.

well yes, all inst. Go though the CPU, xD that is what they are instructing and no.. u have to decode your Op's unless you want something so big that the straight control line programming will end up adding more delay then a simple decoder would have, and be about 5x the space

LD Wrote:

(10-04-2014, 06:39 AM)TSO Wrote: Upon consideration, I could venture to say that if you stood back far enough from it and squinted real hard, you would see something that sort of looked like a pipelined CPU.

doesnt work like that, either you are pipelined or your not,
the best way I would suggest you to get into pipelining is to do a 2 maybe 3 stage at first, and if you would like to do that, I can let you know the best way to go about that.

LD Wrote:

(10-04-2014, 06:39 AM)TSO Wrote: Also, just in case you still don't know the chunk loading thing I mentioned, I was talking about the spawn chunks. (Also, I had to look up what a command block was because I have never heard of them.)

this could work,, but a CPU is RARELY that big that it even comes close to going outside a render distance, and nothing outside the render distance (besides spawn chucks) even register when redstone is activated,, well they do SOMETIMES,, but its buggy enough that you can not use the system for a CPU as it wil corrupt data

(10-06-2014, 03:12 AM)TSO Wrote: Check your PM. Precompile will account for the variable rates, even allow for variable clock rates.

I quickly rechecked the official definition. What I have in mind is like a mix between pipeline and superscaling, with more focus on superscaling. Pipelining that would be ideal.

I have run time stacks that I accidentally built as hardware because I wasn't thinking. They're really big.

---

Is a non approved user (such as myself) allowed to just stroll around the build server and look at stuff, or do they have to apply for a homestead and substantially improve the 260 acre property for five years and all that stuff first?

(10-06-2014, 04:52 AM)TSO Wrote: Hmm. Sounds easy enough. Don't know if I can do it in an hour.

Also, I have tried everything, but I can't connect to the server (I think it's my own fault though.)

(10-05-2014, 09:24 PM)TSO Wrote: To answer the thing about my reasoning for the CPU working and saying lack of disproof is a sign of proof. You see this type of proof happen all the time in mathematics, but what I was saying was that in my hypothetical, I have this CPU that does CPU stuff, and detail is mostly ignored. Now, we can safely say the CPU will work because either a.) my design works, or b.) I shamelessly throw someone else's in there. Thus we know for certain that a working CPU stage is possible in that portion of the discussion. Do note that we can't say that my CPU design will work by that principle, but we can say the computer will work.

(10-05-2014, 09:42 PM)TSO Wrote: Yes, I just have been too busy as of late to fully respond to all that.

The only reason I'm hiding any of this is because there isn't a minecraft "patent" that prevents other people that see this from building it first and claiming it was their idea. There isn't a way to force people to say where they got the idea from. I can tell you right now I got it from when my father was explaining computer programming (i can't program at all) and said that the operating system was involved in a process. I have a personal bias against operating systems (lol), so I tried to think of a workaround for that particular function.

(10-06-2014, 03:05 AM)LordDecapo Wrote: with the variable completion time u will have between ur mult/root/divide/square/add/sub.. you will have to have a system to track that, or have to precompile with those time frames in mind, cause all ops have to save and u cant save 2 at the same time unless u make one of the first dual write Reg.

Quote:OK, I'm 99 percent certain I can't get onto the server because I'm one of those cheap bastards that uses the team extreme cracked minecraft.

(10-06-2014, 05:40 AM)TSO Wrote: We aren't in the same page as far as the proof thing, but I think I'm just going to give up on that.

I'm very good with electrical engineering, but that is completely useless in minecraft. (Not really a way to prove it since anything you ask me could just as easily be googled, so if you believe me or not is up to you)

CS I just kinda wing it. I know what it needs to do, trial and error suffice to get me the rest of the way pretty quickly.

My ideas are so vastly different because I often model compuers in thought expiriments. Though, this has led to some odd results. (For example, it is theoretically possible for a computer to run without a clock, which is actually the basis for some of my ocilloscope.)

MY most recent (mini) project has been the memory address decoder. Started and finished it today. This is the front view. (shown here with 256B of memory)


Top view.


View of output busses. The triangles are because the data input lines all had to be shifted exactly one to the right in order to be inline with the output lines.


Data input.


Address and controls. (L to R) bottom/top, selective read/read all, left/right select, read, write, address.


The address gets split four ways.


One decoder of my own simplistic and intuitive design (this is line 01111, #16 because the count starts at zero)


Some of the instruction set. It's a bit out of date, the CPU state (d) is no longer being considered, so z is six lines instead of five.


Some of the expected ALU operations and maximum allowed times. Most of these were calculated for an 8 bit ALU servicing a 16 bit computer, so many of the numbers are much lower now. I don't know which way AND and OR point because I just use * and +, but for this case, AND is pointing up and OR is pointing down.


16 bit insta-carry 4 tic adder/subtractor. I can speed this up by two or three ticks using some special logic tricks, but I haven't gotten around to it.


It uses Bennyscube's XNOR derived design.


A two bit example of the AND lattice for the Multiplier.


The eight bit version.


Bussing the multiplier. It uses lattice multiplication.


Least significant portion. (None of this was made with world edit because I hadn't downloaded it yet.)

Overflow portion. (Hand built) The use of the three tick adders makes this an 18 tick device, moving down to a one tick adder will make it 10 tick, accelerating the diagonal busses will bring it to 8 tick, and making the lattice instant will bring it down to 6 or 7 tick (depending on how instant you make the lattice.)


A single memory bit, again bennyscube.


A single register bit, I got it from a bennyscube video, but he said it came from someone else. (I only really watch bennyscube because I just need some occasional tricks to make things smaller, a good example is this d flip flop, which is not made from two nor gates and two and gates.)


Small memory block (64B)


Something I mentioned earlier, a hardware implementation of stacks. This was intended to be the run-time stack so that subroutine branching could be done easily. If you want more information about this, just ask.
Push control side.

Input side (inputs on ground)


Output side (also on ground)


Push mechanism


Pop mechanism


Register OR. Oddly enough, a zero tick inline output with stacked inputs is extremely difficult to implement, but I made it work. Took forever, though. I have the other Boolean operators, but none of them are worth mentioning because they were extremely easy to build.


The thing we've been waiting for. Below are my spawn chunks, if you look at my y altitude, it's 302, which was basically the minimum height you can view this thing in it's entirety from. The dimensions are roughly 128*127*132 blocks. The spawn chunks aren't entirely filled because it needs room for the decoder and data bussing. The bottom right corner takes the longest to address, an ungodly 42 tick process. The whole thing totals up to around a glorious 12KB (yawn), I'll check the exact value later, but all of it can be addressed. I can stack one more big block on there to make it 16KB, but I really don't have half an hour to kill at the moment (my laptop is completely useless for the entire time that the paste is occurring.)


Standing on it, 11 FPS. y=168


Same location looking up, 47 FPS.


Some views from y=1 to give you an idea of how big it is.

(10-08-2014, 02:40 PM)TSO Wrote: The stack or the big blocks of memory?

(10-08-2014, 06:17 PM)TSO Wrote: I was thinking of data KB, thus powers of two.

The stack is entirely solid state except for a single instant repeater that moves the pop command from the left to the right side.

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

(10-08-2014, 06:17 PM)TSO Wrote: I was thinking of data KB, thus powers of two.

The stack is entirely solid state except for a single instant repeater that moves the pop command from the left to the right side.

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum. I advise you get around to reading it, we've been discussing making the impossible possible, and (at least according to GG) have actually made a small breakthrough in redstone computing (it sounds like I knocked a tick or two off of the fastest theoretical clock rate)

Hi

(10-07-2014, 02:42 AM)TSO Wrote: Or you can rename registers as you go... but that's for noobs

(10-07-2014, 11:52 PM)Magazorb Wrote:

(10-06-2014, 05:40 AM)TSO Wrote: Full Quote lol

EE knowledge can be applied very well in MC, just not the fundamentals.

Look on my plot and you'll see nothing interesting, my brain is my library of knowledge, not my plot i probably can't compare to Decapo but i do definitely simulate just about everything in my head, so we are much alike if that's how you truly are (Yay for dyslexia power )

(10-08-2014, 02:04 PM)greatgamer34 Wrote: umm, you'd be surprised how much better Solid state is. Just ask decapo, his stack is super small and super fast!

(10-09-2014, 10:18 PM)greatgamer34 Wrote: Most people(including me) in minecraft have a Compare instruction then followed by a Flag register read.

The Flag register read can be BEQ(branch if equal to), BGT(branch if greater than), BLT(branch if less than), BNEQ(branch if not equal to)....etc, along these lines of any amount of possible conditions.

This then reads from the proper flags register and performs a jump to a specified address(usually found in the IMM or a pointer).

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

(10-10-2014, 08:26 PM)LordDecapo Wrote: No please no, do not do a 3 tick clock its "theoretically" the fastest u can get with torches,,, but NO just NO! MC bugs are so disgraceful that ur clock cycles will be come uneven and will corrupt data in ways u never knew were possible... trust me, i had a huge project, and backed off the complexity and simplified the logic i was gonna use in my CU to get it to be a little longer clock,, well more then a little,, 3 ticks to 10 ticks, but the through put and penalty %ages are ridiculously less now as well. so it gives you better performance under normal operating conditions. Clock speed DOESNT mean more Power,, u have to take into consideration the IS, and the possible penalties the CPU could suffer from such small pipeline stages,,, and a 3 tick clock, leave 2 ticks for logic, 1 tick to store, so its really dumb xD i learned this the hard way... PC was the thing that we found killed it the fastest.

(10-10-2014, 04:22 PM)Magazorb Wrote: Metric prefixes:
8Mb = 1(1x10^6) or 1,000,000B, 8KB = 8(8x10^3) or 64,000b, 4Kb = 1(4x10^3) or 4,000b
Binary Prefixes:
8Mib = 1(1024^2) or 1,048,576B, 8KiB = (8x8)(1024^1) or 65536b, 4Kib = 4(1024^1) or 4096b
the 1024 came from 2^10 which is the bases of which binary prefixes are powering from, so 8GB = 8((2^10)^3) = 8589934592Bytes or 6871947674bits.
The Binary prefixes was losely based around the French metrics or later came SI metrics

magazorb Wrote:

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

Computers back in the 90's did have registers, if they was GPRMs, this wasn't used to often though because the processors at the time was slower then the memory speeds so having registers didn't improve performance much, and added to the instruction size, so was deemed uncesseriy for the time because of the extra memory requirements for the IS.

Two other popular PE types wear Stack based and Acumulator based, this two wear both popular for near enough the same reason, positives and negatives of each are near the same and are mainly the other type of PEs that pros and cons wear oposite of GPRM PEs, there was also other types of PEs that other systems used but the 3 most popular and main ones where the Stack,Accumulator and GPR based PEs

"all your possible conditions are computed at the same time and given a true/false value."
The idea and direction you're going with this is good, irl some do this, however in MC it isn't really a thing with most things being small enough they reach the new address and return before clock, thus giving no performance gain, or are predictivly prefetched for pipelined CPUs which also gives no gain.
This is a good idea though and in bigger MC things maybe useful, the idea has gone around a couple of times but has yet to be implemented, so 5pts. to you if you do it first with at least some gain

"(back when programmers actually had to be good at programming.)" actual programming is harder now then it's ever been for pro's, the only programmers that aren't good tend to be game devs (sometimes they know some code but they aren't really programmers, they use software instead) and those who can't be asked to learn how to write optimal code, but for those doing it professionally are made to max their hardwars abilitys out and this becomes very hard.
To do this you have to learn verious languages (normaly this would be done with a combination of fortran, C++ and ASM, with GPGPU being utilised heavily.
Generically this style of programming is never learned but is in high demand of, also tends to not run to well on various configurations other then it's intended system config(s).

I'm also unclear as to what you're defining as a compiler, probably correct but sounds almost like you want to use it in active programs instead of compiled before use.

magazorb Wrote:

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

Doesn't really matter how much you speed up things that are going slow, if you have them before your next clock comes it's waiting, so if you can, put other stuff their and let that be further out, again this is a unique thing with your designs, most don't have this issue so might be a little tricky figuring out a method of doing this automatically for the programmer or for the programmer to know where to do this.

magazorb Wrote:

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum. I advise you get around to reading it, we've been discussing making the impossible possible, and (at least according to GG) have actually made a small breakthrough in redstone computing (it sounds like I knocked a tick or two off of the fastest theoretical clock rate)

Hi

we've/you've not really been talking about things that was seemingly imposible, albe it you do have some great ideas in general, also sorry to say it to you but you won't be caliming performancing king just yet. maybe after a few revisions and optimisations once you settle in and learn stuff your combination with some of our members of ideas might do though (it's not really expected that new members even know half this much about CS really, so you're doing good )

If it's not much to ask for, once you have a IS drawn up may i see it please?

(10-10-2014, 08:26 PM)LordDecapo Wrote:

(10-07-2014, 02:42 AM)TSO Wrote: Or you can rename registers as you go... but that's for noobs.

cough cough, i can do that, and it only takes 3 ticks.

LordDecpo Wrote:

(10-09-2014, 10:18 PM)greatgamer34 Wrote: Most people(including me) in minecraft have a Compare instruction then followed by a Flag register read.

The Flag register read can be BEQ(branch if equal to), BGT(branch if greater than), BLT(branch if less than), BNEQ(branch if not equal to)....etc, along these lines of any amount of possible conditions.

This then reads from the proper flags register and performs a jump to a specified address(usually found in the IMM or a pointer).

Ok so my branching works a bit different, cause my crazy ass cRISC or CISC or what ever u want to consider it Architecture.
I have 2 modes in my IS, Memory/System is mode0 and ALU functions are Mode1
Branching is a Mode0, And it is also a multi line
I have a specially made 3 deep Queue with mutliread so when a branch is detected, it reads Locations (Inst)0, (Inst)1, and (Inst)2 from the Queue, and routes there data to specific parts

Inst0 is the Main Inst, it tells what conditions to look for, weather it is a Call or a Return, weather it is conditional or not, if its direct, relitivePos. or RelitiveNeg.

Inst1 is the Destination address (so i can have 65535 or what ever lines of code on just a PROM, more if i access external memory, which is easy to do) that is only loaded into the PC if the condition is true

Inst2 is the function that defines where the flag can arise from, and this inst MUST be a Mode1, so u can add, sub, or, xor, compare, ect to generate any flag you want.

All of that gets decoded and sorted out in about 7ticks, then the branch is determined on the next cycled wether the conditions are mett, it has static prediction of False, so u only get hit with a 1 cycle penalty after a True flag comes through, leaving the penalty of branching not that devastating.

I will be making a forum post this weekend with pics and such of my MC CPU, since u cant join server, and will explain the IS in detail in it for those who are interested.

LordDecapo Wrote:

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

No please no, do not do a 3 tick clock its "theoretically" the fastest u can get with torches,,, but NO just NO! MC bugs are so disgraceful that ur clock cycles will be come uneven and will corrupt data in ways u never knew were possible... trust me, i had a huge project, and backed off the complexity and simplified the logic i was gonna use in my CU to get it to be a little longer clock,, well more then a little,, 3 ticks to 10 ticks, but the through put and penalty %ages are ridiculously less now as well. so it gives you better performance under normal operating conditions. Clock speed DOESNT mean more Power,, u have to take into consideration the IS, and the possible penalties the CPU could suffer from such small pipeline stages,,, and a 3 tick clock, leave 2 ticks for logic, 1 tick to store, so its really dumb xD i learned this the hard way... PC was the thing that we found killed it the fastest.

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum.

(10-11-2014, 06:02 AM)TSO Wrote:

(10-10-2014, 04:22 PM)Magazorb Wrote: Metric prefixes:
8Mb = 1(1x10^6) or 1,000,000B, 8KB = 8(8x10^3) or 64,000b, 4Kb = 1(4x10^3) or 4,000b
Binary Prefixes:
8Mib = 1(1024^2) or 1,048,576B, 8KiB = (8x8)(1024^1) or 65536b, 4Kib = 4(1024^1) or 4096b
the 1024 came from 2^10 which is the bases of which binary prefixes are powering from, so 8GB = 8((2^10)^3) = 8589934592Bytes or 6871947674bits.
The Binary prefixes was losely based around the French metrics or later came SI metrics

1.) I know my prefixes quite well, possibly better than some of you guys, so I don't need help with that.
2.) 8Mb is not equal to 1(1*10^6), it's much more like 8*10^6 b, and you have similar math errors throughout this section. Also, they are by no means "loosely" related, the relationship of the digits between base ten and base two is log(n)=bl(n)/bl(10). Every (useful) metric prefix is a factor of 1000. Log(1000)=bl(1000)/bl(10), now log(1000)=3 and bl(1000)= 9.96. Let's re examine that number as 10. Now we are looking at 2^10, which is 1024. So the relationship between the two is just (10^(log(1024)log([prefix])/3))B=[prefix]iB. End of story.

(10-11-2014, 06:02 AM)TSO Wrote:

magazorb Wrote:[spoiler]

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

Computers back in the 90's did have registers, if they was GPRMs, this wasn't used to often though because the processors at the time was slower then the memory speeds so having registers didn't improve performance much, and added to the instruction size, so was deemed uncesseriy for the time because of the extra memory requirements for the IS.

Two other popular PE types wear Stack based and Acumulator based, this two wear both popular for near enough the same reason, positives and negatives of each are near the same and are mainly the other type of PEs that pros and cons wear oposite of GPRM PEs, there was also other types of PEs that other systems used but the 3 most popular and main ones where the Stack,Accumulator and GPR based PEs

"all your possible conditions are computed at the same time and given a true/false value."
The idea and direction you're going with this is good, irl some do this, however in MC it isn't really a thing with most things being small enough they reach the new address and return before clock, thus giving no performance gain, or are predictivly prefetched for pipelined CPUs which also gives no gain.
This is a good idea though and in bigger MC things maybe useful, the idea has gone around a couple of times but has yet to be implemented, so 5pts. to you if you do it first with at least some gain

"(back when programmers actually had to be good at programming.)" actual programming is harder now then it's ever been for pro's, the only programmers that aren't good tend to be game devs (sometimes they know some code but they aren't really programmers, they use software instead) and those who can't be asked to learn how to write optimal code, but for those doing it professionally are made to max their hardwars abilitys out and this becomes very hard.
To do this you have to learn verious languages (normaly this would be done with a combination of fortran, C++ and ASM, with GPGPU being utilised heavily.
Generically this style of programming is never learned but is in high demand of, also tends to not run to well on various configurations other then it's intended system config(s).

I'm also unclear as to what you're defining as a compiler, probably correct but sounds almost like you want to use it in active programs instead of compiled before use.

(10-11-2014, 06:02 AM)TSO Wrote:

magazorb Wrote:[spoiler]

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

Doesn't really matter how much you speed up things that are going slow, if you have them before your next clock comes it's waiting, so if you can, put other stuff their and let that be further out, again this is a unique thing with your designs, most don't have this issue so might be a little tricky figuring out a method of doing this automatically for the programmer or for the programmer to know where to do this.

(10-11-2014, 06:02 AM)TSO Wrote:

magazorb Wrote:[spoiler]

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum. I advise you get around to reading it, we've been discussing making the impossible possible, and (at least according to GG) have actually made a small breakthrough in redstone computing (it sounds like I knocked a tick or two off of the fastest theoretical clock rate)

Hi

we've/you've not really been talking about things that was seemingly imposible, albe it you do have some great ideas in general, also sorry to say it to you but you won't be caliming performancing king just yet. maybe after a few revisions and optimisations once you settle in and learn stuff your combination with some of our members of ideas might do though (it's not really expected that new members even know half this much about CS really, so you're doing good )

If it's not much to ask for, once you have a IS drawn up may i see it please?

(10-11-2014, 06:02 AM)TSO Wrote:

(10-10-2014, 08:26 PM)LordDecapo Wrote:

(10-07-2014, 02:42 AM)TSO Wrote: Or you can rename registers as you go... but that's for noobs.

cough cough, i can do that, and it only takes 3 ticks.

Noob.

LordDecpo Wrote:[spoiler]

(10-09-2014, 10:18 PM)greatgamer34 Wrote: Most people(including me) in minecraft have a Compare instruction then followed by a Flag register read.

The Flag register read can be BEQ(branch if equal to), BGT(branch if greater than), BLT(branch if less than), BNEQ(branch if not equal to)....etc, along these lines of any amount of possible conditions.

This then reads from the proper flags register and performs a jump to a specified address(usually found in the IMM or a pointer).

Ok so my branching works a bit different, cause my crazy ass cRISC or CISC or what ever u want to consider it Architecture.
I have 2 modes in my IS, Memory/System is mode0 and ALU functions are Mode1
Branching is a Mode0, And it is also a multi line
I have a specially made 3 deep Queue with mutliread so when a branch is detected, it reads Locations (Inst)0, (Inst)1, and (Inst)2 from the Queue, and routes there data to specific parts

Inst0 is the Main Inst, it tells what conditions to look for, weather it is a Call or a Return, weather it is conditional or not, if its direct, relitivePos. or RelitiveNeg.

Inst1 is the Destination address (so i can have 65535 or what ever lines of code on just a PROM, more if i access external memory, which is easy to do) that is only loaded into the PC if the condition is true

Inst2 is the function that defines where the flag can arise from, and this inst MUST be a Mode1, so u can add, sub, or, xor, compare, ect to generate any flag you want.

All of that gets decoded and sorted out in about 7ticks, then the branch is determined on the next cycled wether the conditions are mett, it has static prediction of False, so u only get hit with a 1 cycle penalty after a True flag comes through, leaving the penalty of branching not that devastating.

I will be making a forum post this weekend with pics and such of my MC CPU, since u cant join server, and will explain the IS in detail in it for those who are interested.

LordDecapo Wrote:

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

No please no, do not do a 3 tick clock its "theoretically" the fastest u can get with torches,,, but NO just NO! MC bugs are so disgraceful that ur clock cycles will be come uneven and will corrupt data in ways u never knew were possible... trust me, i had a huge project, and backed off the complexity and simplified the logic i was gonna use in my CU to get it to be a little longer clock,, well more then a little,, 3 ticks to 10 ticks, but the through put and penalty %ages are ridiculously less now as well. so it gives you better performance under normal operating conditions. Clock speed DOESNT mean more Power,, u have to take into consideration the IS, and the possible penalties the CPU could suffer from such small pipeline stages,,, and a 3 tick clock, leave 2 ticks for logic, 1 tick to store, so its really dumb xD i learned this the hard way... PC was the thing that we found killed it the fastest.

(10-12-2014, 02:25 AM)Magazorb Wrote: In short you will waste away your life playing a stupid block game building outdated computers that serve no purpose

(10-12-2014, 03:14 AM)͝ ͟ ͜ Wrote:

(10-12-2014, 02:25 AM)Magazorb Wrote: In short you will waste away your life playing a stupid block game building outdated computers that serve no purpose

fix'd

(10-12-2014, 02:25 AM)Magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

(10-10-2014, 04:22 PM)Magazorb Wrote: Metric prefixes:
8Mb = 1(1x10^6) or 1,000,000B, 8KB = 8(8x10^3) or 64,000b, 4Kb = 1(4x10^3) or 4,000b
Binary Prefixes:
8Mib = 1(1024^2) or 1,048,576B, 8KiB = (8x8)(1024^1) or 65536b, 4Kib = 4(1024^1) or 4096b
the 1024 came from 2^10 which is the bases of which binary prefixes are powering from, so 8GB = 8((2^10)^3) = 8589934592Bytes or 6871947674bits.
The Binary prefixes was losely based around the French metrics or later came SI metrics

1.) I know my prefixes quite well, possibly better than some of you guys, so I don't need help with that.
2.) 8Mb is not equal to 1(1*10^6), it's much more like 8*10^6 b, and you have similar math errors throughout this section. Also, they are by no means "loosely" related, the relationship of the digits between base ten and base two is log(n)=bl(n)/bl(10). Every (useful) metric prefix is a factor of 1000. Log(1000)=bl(1000)/bl(10), now log(1000)=3 and bl(1000)= 9.96. Let's re examine that number as 10. Now we are looking at 2^10, which is 1024. So the relationship between the two is just (10^(log(1024)log([prefix])/3))B=[prefix]iB. End of story.

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

Computers back in the 90's did have registers, if they was GPRMs, this wasn't used to often though because the processors at the time was slower then the memory speeds so having registers didn't improve performance much, and added to the instruction size, so was deemed uncesseriy for the time because of the extra memory requirements for the IS.

Two other popular PE types wear Stack based and Acumulator based, this two wear both popular for near enough the same reason, positives and negatives of each are near the same and are mainly the other type of PEs that pros and cons wear oposite of GPRM PEs, there was also other types of PEs that other systems used but the 3 most popular and main ones where the Stack,Accumulator and GPR based PEs

"all your possible conditions are computed at the same time and given a true/false value."
The idea and direction you're going with this is good, irl some do this, however in MC it isn't really a thing with most things being small enough they reach the new address and return before clock, thus giving no performance gain, or are predictivly prefetched for pipelined CPUs which also gives no gain.
This is a good idea though and in bigger MC things maybe useful, the idea has gone around a couple of times but has yet to be implemented, so 5pts. to you if you do it first with at least some gain

"(back when programmers actually had to be good at programming.)" actual programming is harder now then it's ever been for pro's, the only programmers that aren't good tend to be game devs (sometimes they know some code but they aren't really programmers, they use software instead) and those who can't be asked to learn how to write optimal code, but for those doing it professionally are made to max their hardwars abilitys out and this becomes very hard.
To do this you have to learn verious languages (normaly this would be done with a combination of fortran, C++ and ASM, with GPGPU being utilised heavily.
Generically this style of programming is never learned but is in high demand of, also tends to not run to well on various configurations other then it's intended system config(s).

I'm also unclear as to what you're defining as a compiler, probably correct but sounds almost like you want to use it in active programs instead of compiled before use.

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

Doesn't really matter how much you speed up things that are going slow, if you have them before your next clock comes it's waiting, so if you can, put other stuff their and let that be further out, again this is a unique thing with your designs, most don't have this issue so might be a little tricky figuring out a method of doing this automatically for the programmer or for the programmer to know where to do this.

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum. I advise you get around to reading it, we've been discussing making the impossible possible, and (at least according to GG) have actually made a small breakthrough in redstone computing (it sounds like I knocked a tick or two off of the fastest theoretical clock rate)

Hi

we've/you've not really been talking about things that was seemingly imposible, albe it you do have some great ideas in general, also sorry to say it to you but you won't be caliming performancing king just yet. maybe after a few revisions and optimisations once you settle in and learn stuff your combination with some of our members of ideas might do though (it's not really expected that new members even know half this much about CS really, so you're doing good )

If it's not much to ask for, once you have a IS drawn up may i see it please?

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

(10-10-2014, 08:26 PM)LordDecapo Wrote:

(10-07-2014, 02:42 AM)TSO Wrote: Or you can rename registers as you go... but that's for noobs.

cough cough, i can do that, and it only takes 3 ticks.

Noob.

LordDecpo Wrote:[spoiler]

(10-09-2014, 10:18 PM)greatgamer34 Wrote: Most people(including me) in minecraft have a Compare instruction then followed by a Flag register read.

The Flag register read can be BEQ(branch if equal to), BGT(branch if greater than), BLT(branch if less than), BNEQ(branch if not equal to)....etc, along these lines of any amount of possible conditions.

This then reads from the proper flags register and performs a jump to a specified address(usually found in the IMM or a pointer).

Ok so my branching works a bit different, cause my crazy ass cRISC or CISC or what ever u want to consider it Architecture.
I have 2 modes in my IS, Memory/System is mode0 and ALU functions are Mode1
Branching is a Mode0, And it is also a multi line
I have a specially made 3 deep Queue with mutliread so when a branch is detected, it reads Locations (Inst)0, (Inst)1, and (Inst)2 from the Queue, and routes there data to specific parts

Inst0 is the Main Inst, it tells what conditions to look for, weather it is a Call or a Return, weather it is conditional or not, if its direct, relitivePos. or RelitiveNeg.

Inst1 is the Destination address (so i can have 65535 or what ever lines of code on just a PROM, more if i access external memory, which is easy to do) that is only loaded into the PC if the condition is true

Inst2 is the function that defines where the flag can arise from, and this inst MUST be a Mode1, so u can add, sub, or, xor, compare, ect to generate any flag you want.

All of that gets decoded and sorted out in about 7ticks, then the branch is determined on the next cycled wether the conditions are mett, it has static prediction of False, so u only get hit with a 1 cycle penalty after a True flag comes through, leaving the penalty of branching not that devastating.

I will be making a forum post this weekend with pics and such of my MC CPU, since u cant join server, and will explain the IS in detail in it for those who are interested.

LordDecapo Wrote:

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

No please no, do not do a 3 tick clock its "theoretically" the fastest u can get with torches,,, but NO just NO! MC bugs are so disgraceful that ur clock cycles will be come uneven and will corrupt data in ways u never knew were possible... trust me, i had a huge project, and backed off the complexity and simplified the logic i was gonna use in my CU to get it to be a little longer clock,, well more then a little,, 3 ticks to 10 ticks, but the through put and penalty %ages are ridiculously less now as well. so it gives you better performance under normal operating conditions. Clock speed DOESNT mean more Power,, u have to take into consideration the IS, and the possible penalties the CPU could suffer from such small pipeline stages,,, and a 3 tick clock, leave 2 ticks for logic, 1 tick to store, so its really dumb xD i learned this the hard way... PC was the thing that we found killed it the fastest.

(10-12-2014, 03:52 AM)Magazorb Wrote:

(10-12-2014, 03:14 AM)͝ ͟ ͜ Wrote:

(10-12-2014, 02:25 AM)Magazorb Wrote: In short you will waste away your life playing a stupid block game building outdated computers that serve no purpose

fix'd

Well that's not nice :'(

(10-12-2014, 03:59 AM)TSO Wrote:

(10-12-2014, 02:25 AM)Magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

(10-10-2014, 04:22 PM)Magazorb Wrote: Metric prefixes:
8Mb = 1(1x10^6) or 1,000,000B, 8KB = 8(8x10^3) or 64,000b, 4Kb = 1(4x10^3) or 4,000b
Binary Prefixes:
8Mib = 1(1024^2) or 1,048,576B, 8KiB = (8x8)(1024^1) or 65536b, 4Kib = 4(1024^1) or 4096b
the 1024 came from 2^10 which is the bases of which binary prefixes are powering from, so 8GB = 8((2^10)^3) = 8589934592Bytes or 6871947674bits.
The Binary prefixes was losely based around the French metrics or later came SI metrics

1.) I know my prefixes quite well, possibly better than some of you guys, so I don't need help with that.
2.) 8Mb is not equal to 1(1*10^6), it's much more like 8*10^6 b, and you have similar math errors throughout this section. Also, they are by no means "loosely" related, the relationship of the digits between base ten and base two is log(n)=bl(n)/bl(10). Every (useful) metric prefix is a factor of 1000. Log(1000)=bl(1000)/bl(10), now log(1000)=3 and bl(1000)= 9.96. Let's re examine that number as 10. Now we are looking at 2^10, which is 1024. So the relationship between the two is just (10^(log(1024)log([prefix])/3))B=[prefix]iB. End of story.

[/spoiler]

OK, first of you did originally use it incorrectly, i didn't say that you didn't know it, i just merely was clearing, sorry if it seemed i was suggesting you didn't know, also i said 8Mb is 1(1*10^6)B which is true, B= Byte, b=bit, you just miss read it.

Also the prefix naming of binary prefixed is losely based on metric prefixs, they just change the ending of metric prefixes to bi instead, hence why i said losely based, the values them self are all together different yes, but the names of prefixes are related.

You can easily tie the powers of prefixes to together rather easily by saying 10^3~1024^1, or 10^9~1024^3, basically powers of binary be metric_power/3, this become less accurate as the powers increase, so best to keep metrics and binary's separate, but regardless name still relates.

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-09-2014, 05:16 AM)TSO Wrote: Sorry, I meant mostly how to generate the conditions (flags, I guess) in the same cycle as the operation, then I started wondering how many of these conditions I need... then I asked my father for help. He programmed back in the 90's when computers had no memory and actual program speed mattered because computers were still so slow (back when programmers actually had to be good at programming.)

What I learned was this: all your possible conditions are computed at the same time and given a true/false value. These values then go to a single register the same size as all the possible conditions (between eight and sixteen), you then use a bit mask to get the conditions you want out of this register (you can actually call more than one flag at the same time, then operate a condition on those two). Your goal is to never jump, EVER, especially more than one or two lines. Long goto jumps take longer, are harder to understand in debugging, and are a sign that the programmer does not understand the program being written. If, Then, Else statements also slow down the system, but are far better than a goto because the compiler will place the destination code for the if statement near the line the condition is on. The compiler will preload the program data line by line regardless of condition destinations, if an if, then, else occurs, a path is chosen, and all code for the other path is deleted, followed by loading all the subsequent program data for the line that was chosen. The nearer these lines are to the jump condition, the less gets loaded and unloaded. The amount of qued data that gets deleted depends upon how large the jump is, with a goto being the worst. Nearly all data is dumped and reloaded and all stages of the CPU are completely cleared in a goto because they inherently do not jump near the line their condition is on. And if you pipelined and it jumps conditionally, you have to somehow rid yourself of all the crap in the pipeline that is no longer correct because it was part of the other conditional side.

Luckily, my design inherently helps with this, but it will still suck to have to think about it.

Computers back in the 90's did have registers, if they was GPRMs, this wasn't used to often though because the processors at the time was slower then the memory speeds so having registers didn't improve performance much, and added to the instruction size, so was deemed uncesseriy for the time because of the extra memory requirements for the IS.

Two other popular PE types wear Stack based and Acumulator based, this two wear both popular for near enough the same reason, positives and negatives of each are near the same and are mainly the other type of PEs that pros and cons wear oposite of GPRM PEs, there was also other types of PEs that other systems used but the 3 most popular and main ones where the Stack,Accumulator and GPR based PEs

"all your possible conditions are computed at the same time and given a true/false value."
The idea and direction you're going with this is good, irl some do this, however in MC it isn't really a thing with most things being small enough they reach the new address and return before clock, thus giving no performance gain, or are predictivly prefetched for pipelined CPUs which also gives no gain.
This is a good idea though and in bigger MC things maybe useful, the idea has gone around a couple of times but has yet to be implemented, so 5pts. to you if you do it first with at least some gain

"(back when programmers actually had to be good at programming.)" actual programming is harder now then it's ever been for pro's, the only programmers that aren't good tend to be game devs (sometimes they know some code but they aren't really programmers, they use software instead) and those who can't be asked to learn how to write optimal code, but for those doing it professionally are made to max their hardwars abilitys out and this becomes very hard.
To do this you have to learn verious languages (normaly this would be done with a combination of fortran, C++ and ASM, with GPGPU being utilised heavily.
Generically this style of programming is never learned but is in high demand of, also tends to not run to well on various configurations other then it's intended system config(s).

I'm also unclear as to what you're defining as a compiler, probably correct but sounds almost like you want to use it in active programs instead of compiled before use.

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

Doesn't really matter how much you speed up things that are going slow, if you have them before your next clock comes it's waiting, so if you can, put other stuff their and let that be further out, again this is a unique thing with your designs, most don't have this issue so might be a little tricky figuring out a method of doing this automatically for the programmer or for the programmer to know where to do this.

(10-12-2014, 03:59 AM)TSO Wrote:

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

magazorb Wrote:[spoiler]

(10-10-2014, 05:45 AM)TSO Wrote: That completely defeats the purpose of a forum. I advise you get around to reading it, we've been discussing making the impossible possible, and (at least according to GG) have actually made a small breakthrough in redstone computing (it sounds like I knocked a tick or two off of the fastest theoretical clock rate)

Hi

we've/you've not really been talking about things that was seemingly imposible, albe it you do have some great ideas in general, also sorry to say it to you but you won't be caliming performancing king just yet. maybe after a few revisions and optimisations once you settle in and learn stuff your combination with some of our members of ideas might do though (it's not really expected that new members even know half this much about CS really, so you're doing good )

If it's not much to ask for, once you have a IS drawn up may i see it please?

[/spoiler]

Due to a particular breakthrough I had (it was legitimately like a moment of enlightenment, LD sort of knows about it), I actually have almost all the instruction set drawn up now, as well as the entire bussing arrangement. I also don't think I'm going to ever be performance king, but I will certainly be the king of dual purpose logic.

I have a programmer father that hates wasting time in a program, my friend's father is a hardware developer at HP, one of my father's friends is a hardware developer at IBM, and one of my father's other friends has a degree in library science. Between my inquisitive nature and their experience, there is literally no way I wouldn't know this much about computer engineering. (Although, it is funny to get the two hardware developers in the same room, because they suddenly get real cautious about how they answer my questions. Let's just say neither of them are the low guy on the totem pole at their company.)

magazorb Wrote:

(10-11-2014, 06:02 AM)TSO Wrote: [spoiler]

(10-10-2014, 08:26 PM)LordDecapo Wrote:

(10-07-2014, 02:42 AM)TSO Wrote: Or you can rename registers as you go... but that's for noobs.

cough cough, i can do that, and it only takes 3 ticks.

Noob.

LordDecpo Wrote:[spoiler]

(10-09-2014, 10:18 PM)greatgamer34 Wrote: Most people(including me) in minecraft have a Compare instruction then followed by a Flag register read.

The Flag register read can be BEQ(branch if equal to), BGT(branch if greater than), BLT(branch if less than), BNEQ(branch if not equal to)....etc, along these lines of any amount of possible conditions.

This then reads from the proper flags register and performs a jump to a specified address(usually found in the IMM or a pointer).

Ok so my branching works a bit different, cause my crazy ass cRISC or CISC or what ever u want to consider it Architecture.
I have 2 modes in my IS, Memory/System is mode0 and ALU functions are Mode1
Branching is a Mode0, And it is also a multi line
I have a specially made 3 deep Queue with mutliread so when a branch is detected, it reads Locations (Inst)0, (Inst)1, and (Inst)2 from the Queue, and routes there data to specific parts

Inst0 is the Main Inst, it tells what conditions to look for, weather it is a Call or a Return, weather it is conditional or not, if its direct, relitivePos. or RelitiveNeg.

Inst1 is the Destination address (so i can have 65535 or what ever lines of code on just a PROM, more if i access external memory, which is easy to do) that is only loaded into the PC if the condition is true

Inst2 is the function that defines where the flag can arise from, and this inst MUST be a Mode1, so u can add, sub, or, xor, compare, ect to generate any flag you want.

All of that gets decoded and sorted out in about 7ticks, then the branch is determined on the next cycled wether the conditions are mett, it has static prediction of False, so u only get hit with a 1 cycle penalty after a True flag comes through, leaving the penalty of branching not that devastating.

I will be making a forum post this weekend with pics and such of my MC CPU, since u cant join server, and will explain the IS in detail in it for those who are interested.

LordDecapo Wrote:

(10-10-2014, 01:48 AM)TSO Wrote: So you would be saving a clock cycle per instruction.

I spoke with him, and yes you do exactly what I described when programming assembly for the 386, with one slight exception. The instruction set does not carry the conditional with it, there is a branching operation and the CPU uses some kind of hardware look ahead in order to set the flags in one clock cycle so that the next cycle will pipeline correctly.


Also, when optimizing for speed on an ALU where not every operation takes the same amount of time but multiple simultaneous operations are possible, is it better to put the fast operations close to the CPU and have them be a hell of a lot faster than the slow ones, or put the fast farthest away and have it all kinda balance out? For example, my current instruction set, which I have discussed with LD would allow for a bit shift to occur three ticks after being instructed, and repeatable every six ticks, with the ability to run all the other operations at such speeds as well (the CPU can have a three tick clock). The Boolean operators are four ticks out, but also repeatable every six ticks. At the other end, the MOD function is 106 ticks out, so that's like 34 near operations for every far operation.

No please no, do not do a 3 tick clock its "theoretically" the fastest u can get with torches,,, but NO just NO! MC bugs are so disgraceful that ur clock cycles will be come uneven and will corrupt data in ways u never knew were possible... trust me, i had a huge project, and backed off the complexity and simplified the logic i was gonna use in my CU to get it to be a little longer clock,, well more then a little,, 3 ticks to 10 ticks, but the through put and penalty %ages are ridiculously less now as well. so it gives you better performance under normal operating conditions. Clock speed DOESNT mean more Power,, u have to take into consideration the IS, and the possible penalties the CPU could suffer from such small pipeline stages,,, and a 3 tick clock, leave 2 ticks for logic, 1 tick to store, so its really dumb xD i learned this the hard way... PC was the thing that we found killed it the fastest.

(10-12-2014, 03:59 AM)TSO Wrote:

---

(10-12-2014, 03:52 AM)Magazorb Wrote:

(10-12-2014, 03:14 AM)͝ ͟ ͜ Wrote:

(10-12-2014, 02:25 AM)Magazorb Wrote: In short you will waste away your life playing a stupid block game building outdated computers that serve no purpose

fix'd

Well that's not nice :'(

But it is true

magazorb Wrote:Assumed you wouldn't do it then because that's to easy XD, would give a overhead though that maybe annoying.

magazorb Wrote:you don't need to be philosophical about this, if you wanted a 3tick pipeline for instance, 1tick would be on the repeater lock as a stage buffer and other 2 would be logic between stage, or say a 8tick it would be 1 tick on locks and 7 on logic, it's just quicker then using Sr-latches, if you wanted to make a extream data loop with simple pipelining and 1 Fwd, you can theorticly achive a effective dataloop of 5 ticks, 1 tick for buffer, 4 for ULG or Adder/Subtractor with a CU that looks ahead to see if Fwd is required and redirects Data Fwd into the Buffer before the stage, a little messy and large, but still holds in theory and also the PE would require two computes to the final half of the logic for the ALU stage, half acting as Fwd which output is naturally disabled by CU unless Fwd is required, the other is unobstructed and continues to the GPRs, though good luck to anyone trying to implement a 8bit version of that.

But it's a good idea to have stage buffers as sometimes interrupts can disrupt the flow of data and currupt things without it being noticeable by the CU it's self, in tern invalid result and calculations there on that are unknown.

Probably not so much of a worrie for a more simple system without them.

If you really want you can go without stage buffers in MC if all is sync enough, and you know where everything will be and when, but it can make it trickier to implement and get working.

TSO Wrote:Let's have an extremely short thought experiment. If you don't rearrange or alter data in runtime, and you don't rearrange or alter data at programming time, where would it happen? What other time could possibly exist in the program development flow chart where the data could be rearranged or altered?

TSO Wrote:All the additions to the CPU are unnecessary, they can be removed. All the buffers, all the locking repeaters, all the hardware for the register renaming and the out of order execution disappear. There is no wasted time in the CPU and nothing inside is idle or unused. There is 100% hardware efficiency in the pipeline, with none of the clock cycle lost to buffer and all of the clock cycle in the logic.

TSO Wrote:Is it the way to go? Do you honestly need that repeater to even lock? If we multiply by accumulation, and place 16 3 tick adders with output connected to input incorrectly so the shift happens on it's own, do you really need to hold the other operand's data in a locking repeater, or do we just need it to pause for three ticks at the front of each add? If they are 1 tick adders sixteen blocks long, does the data for the second operand need to have any pause at all, or does the repeater every fifteen blocks suffice?

TSO Wrote:If they are 1 tick adders sixteen blocks long, are they really 1 tick... or are they zero tick because redstone needs a repeater every fifteen blocks?
If you direct this multiplier back toward the registers, did you remove the output bussing, or is the bus performing the operations?
Could that be applied to other elements of the processor?

(10-12-2014, 03:55 PM)Magazorb Wrote: This hot air is to steamy, you're recycling to much, TSO you have some good ideas but you're overlooking key details, the Fwd is a good thing to have and utilise, it allows you to forward a data from the ALU back into the ALU rather then having to write it back before use, this increases serial performance, you wouldn't want to rid of that.

So say we have the example i gave, which you seem to missunderstand the setup, the alu stage has no buffers in it, only around it, now i'll be more realistic this time and use stuff based on what we can currently implement with no issues what so ever, which is a 6 tick ALU with 1 tick forward being CU assisted and 1 tick repeater lock stage buffer.
Now i'm going to be unrealistic to give your suggesting system as much of a advantage as posible, we shall have a write back of 1tick, and a read from that new write back 1 tick, now you'll notice that that equates to the same as the Fwd, but the difference is the Fwd only has to go back to the buffer before, meanwhile to achive this speed with the registers you would have to have them all repeater locked and comparative read disabled, in turn this means it's memory dencity is low and gives you a only aprox 30 dust of singal total (15 before lock and 15 after) to get all your registers back to ALU input, so ignoring the buffer as you suggest you don't want that.
And what you'll find is that yours is no quicker, in serial compute and that's in your most favorable configuration.
Now allow me to explain further in that those register setups havn't been done before except maybe in a 4G/SPRM, we always tend to use at least 8G/SPRs in our PEs, so you can easly see without that Fwd you can very easily loss serial performance, and unfortunately your oversight is that you forgotten about serial computations, you though so much that you could fill ideals with out of order executions, but unfortunately their's times where this isn't possible.

The resulting difference is that when comes a serial computation which is inevitable at some point, you will lose computations via ideal, this is still a big issue in IRL mass computations.
I guess you could via pulse timing achieve a max of 3 ticks per instruction through put but that's unlikely due to MC being a derp, 5 ticks is likely though, but theirs nothing stopping our systems from doing that anyhow providing the data isn't serial, and if it is based on current creations all that would do is slow us down to 8 ticks, but with timing comes a issue of how easily can a interrupt cause a corruption.

Now to go back to go back to the device you have, that one that gives instructions to other "CPUs" as you called it, How do you intend to have multiple of these PEs attached to one of these and fully satuate them when you have so few commands that would actually take up multiple PE cycles if you will, Besides, it's not like we don't have thise functions, it's just we don't bother to reorder instructions in compile time due to the amount of overhead that would be on what ever has to compile it before you could finaly exe. (I'd say it's overhead as it's actualy something that has to be processed before it can have a use, so it does add to making something longer in some ways)

Heck i'v stated i'm currently planning on making a SIMD array and how to address all the PEs is a similar issue, because i have to fetch data as quickly as i can while it's computing and SIMD computations are vastly more quicker computing speed vs memory speed which brings the same issue as what you will have with addressing multiple PEs, that you will only bealbe to use multiples when you have multiples executing instructions that would take multiple cycles.
The only difference between the my SIMD array and your multi-MIMD PE would be mine's data limited and your's is instruction limited.
When these kinds of things happen you'll need a PE that can stockpile multiple instructions/data coherently.

I've seen other guys do things similar to your suggestions, they gave up not realising how much they got them self's in, but you seem to know a lot of what you want to do but you've yet to figure out the short comings.

(10-12-2014, 02:28 PM)Xray_Doc Wrote: Tl;dr

(10-14-2014, 05:24 PM)TSO Wrote: It stops when branching? Why?

(10-14-2014, 01:53 PM)LordDecapo Wrote: And maga, I fwd on an 8bit, it's easy with a simple XOR array to detect hazards..

A fwd is like this
Say u have these inst.
(($ means register and & means RAM btw)
$1+&2=$3
$3+$4=$5

(10-14-2014, 02:47 PM)LordDecapo Wrote: "Resembles pipelineing"
It's pipelined or not pipelined, no grey area.

And your system IS TIMING based, u wanted to keep control wires and data in synce so u don't need buffers,. Is like the literal definition of pipelineing via timing base system, since u have to focus A LOT of time to timing it all PERFECT.

A compiler won't be able to rename registers effectively, as renaming usually used a pool of "tags" that is a lot larger then ur actuall register count.
And it will only be able to rearrange things so much,, u have to Fwd or do some tricky CU magic to get it fully optimized, a good computer system is a mix of A BUNCH of individually complex systems all working together, not just a simple data loop and a smart compiler.
Compiler also can not help get ur branch conditions sooner, as ur branching effectiveness is determined by your architecture and ur CU/branch hardware.
Memory allocation only helps with preventing storage corruption and inter program security, it doesn't speed up a system unless u plan to access a lot of data quickly and only use it once or twice each. If u have a way for it to speed up processing, due share In better refined explainations please.

Your whole "make logic same as buss time" isn't that effective.. At all., buss time in a well thought out system can be near zero, and ur parts are usually smaller then like 90 blocks (6tick ALU with each tick of logic being the 15block apart)
U would end up with the same speed but a MUCH MUCH bigger system, and the bussing delay would actually be greater.

Also what are u referring to as chunks? The game chucks of blocks loaded? (16x16)
A fwd router.. Doesn't necisarrily take any ticks at all, use a 1tick shifter at output of ALU that inverts signal, then have it invert again before the fwd, in which u can disaple the torches by giving them a 2nd control power source. So u can have in essence a 0tick output demux (it's a demux not router)

All Boolean should be sync, and take the same, if you have anything except a shit ALU, then add, sub and all Boolean will ALWAYS take same time frame.
And FWD is only for ALU, not Mult/div, ur right on that. And for a Mult div sequential system to work, you HAVE TO have a buffer or u will get MC glitches fucking up ur data at a 3 tick through put.. I have tried 3 ticks,, it DOESNT WORK. AT ALL.. Minecraft has a bug with torches, your data tick width will not always be 3 u will find that the bug will randomly give u data tick widths between 1 and 4.. Which isn't consistent enough at all to be feasible, a 4 tick clok MAY work.. But 5 is the only garentee it would function at all. But good luck wit FWD on a 5 tick, u would need at least a Dual Fwd system (so u can not only give data to the immediately following inst, but the one following that one as well... This isn't TOO hard, but if u don't know pipelining and hazard detection well (no offense, it doesn't seem like u are grasping those concepts that well) it can e a BITCH AND A HALF to implement. I suggest lengthining ur clock.
A slower clock can increase speed and preformance due to lower stage counts. Of u don't believe me.. I'll post a picture of my math I did that tests 3 clock speed, 2 different counts of stages.. The faster clock speed only helps if you like hardly wet branch.. It avg out that a 8tick clock with 8 stages.. Is 0.56% slower then a 10tick 5 stages on avgerage over a corse of tests I ran
The test uses a static branch prediction of true, which is actually a worse case scenario. Static False is better but fuck it.
I used these scenarios
(The format is %false branches-%true branches-1branch/(per x inst)
0-100-1/2
30-70-1/2
50-50-1/2
70-30-1/2
0-100-1/4
30-70-1/4
50-50-1/4
70-30-1/4
0-100-1/8
30-70-1/8
50-50-1/8
70-30-1/8
0-100-1/16
30-70-1/16
50-50-1/16
70-30-1/16

Note that IRL programs average like a 30-70-1/8 for calculation heavy programs
And like 50-50-1/16 for memory intensive programs, and with the normal programs I see ppl running in MC, it's like 30-70-1/4 sometimes 30-70-1/2
My 10tick 5 stages handles more frequent branches A LOT better over the course of 100inst.

Minecraft Name: TSO

What do you hope to learn: multiple pistion extension and automated tree farming

What past experience (if any) do you have in redstone: A 16 bit fully pipelined out of order execution multicore computer with a three (maybe four) tick clock made in collaboration with GreatGamer34, LordDecapo, and Magazorb.

Do you agree with the rules? Only on Tuesdays and Thursdays... other than that it's fair game.

(10-14-2014, 03:03 AM)͝ ͟ ͜ Wrote: stop talking and start building
tl;dr

(10-16-2014, 01:15 AM)͝ ͟ ͜ Wrote:

(10-14-2014, 03:03 AM)͝ ͟ ͜ Wrote: stop talking and start building
tl;dr

(10-17-2014, 07:42 PM)TSO Wrote: I have never seen building from any of you guys... (It's true)

(10-17-2014, 07:24 PM)LordDecapo Wrote: lol i dont see any building of CPU stuffs much at all from you either ͝ ͟ ͜ ,,, and u know i know who u are

(10-17-2014, 07:42 PM)TSO Wrote: I have never seen building from any of you guys... (It's true)

(10-18-2014, 06:25 PM)Nuuppanaani Wrote: Let'sperformthedyslexiacheckonthemysterypersontoseeifit'sMaga!

(10-18-2014, 08:07 PM)LordDecapo Wrote:

(10-18-2014, 06:25 PM)Nuuppanaani Wrote: Let'sperformthedyslexiacheckonthemysterypersontoseeifit'sMaga!

sofuckedandsogreatXD

(10-18-2014, 09:37 PM)͝ ͟ ͜ Wrote: I am mergerzehrb

Everything I have ever done has led me to this

(10-19-2014, 09:28 PM)Magazorb Wrote: Thanks lord... and seemingly so

(10-21-2014, 05:20 AM)TSO Wrote: *returns*
WTF?

So, I leave for like three days, and this is the best you guys could do with your time?

Also, my update: I haven't even launched the minecraft application in over a week.

(10-21-2014, 05:20 AM)TSO Wrote: *returns*
WTF?

So, I leave for like three days, and this is the best you guys could do with your time?

Also, my update: I haven't even launched the minecraft application in over a week.