+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Introductions (https://forum.openredstone.org/forum-18.html)
+--- Thread: I am TSO (/thread-4807.html)
RE: I am TSO - TSO - 10-08-2014
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.
RE: I am TSO - greatgamer34 - 10-08-2014
(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.
oh my bad xD this is the stack right?
![[Image: 2616713.png]](http://hostingbytes.us/images/3/2616713.png)
but you should really check out the one on lords CPU, it is way more compact!
RE: I am TSO - TSO - 10-08-2014
yeah... I can make it thinner by using vertical transmission instead of stairs for the data... I can make it eight blocks shorter... and the length will be the same.
Most of that width is in the pop. The other limit is the size of the eight registers, which is just made of those d flip flops that are shown in a different picture.
RE: I am TSO - TSO - 10-08-2014
SO, I was working out some IS stuff, and it dawned on me that I have no idea how to do conditional branching.
RE: I am TSO - greatgamer34 - 10-09-2014
compare your flags. based on your instructions, read the flags reg.
RE: I am TSO - TSO - 10-09-2014
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.
RE: I am TSO - greatgamer34 - 10-09-2014
(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.
Ive never thought of doing it this way, but its genius. Just have a SPR that can save the flags and then be read from and they can be AND'ed with a bit mask to find what you want, for the results that are one, then perform the jump condition.
RE: I am TSO - TSO - 10-09-2014
Yeah, he said that's what he always coded for, or at least that's how I imagined what he explained. (He only knows how to code for something, and I kinda imagine how that would convert back to the machine). It makes the most sense to me to do it that way. I should mention that the register can actually keep conditions across multiple cycles if you tell it to. In X86 instruction sets, you actually have to tell it to clear things like the carry overflow register because they hold values for a certain number of cycles after the overflow occurs. (I think they hold it for three cycles afterward so that you can reference it and move the value into a register in the next line of code). If you need it to be zero for the next line, you tell it to clear.
(Now to figure out what SPR means... simple push register?)
How have you been doing it?
An example he described was you run the multiply, mask the overflow register, (which has the OR of all most significant bits in the multiplier somewhere in there), if you get a true value, you write the overflow portion of the multiplier to a second register. This is actually coded as the least significant bits to Register A, followed by the AND of the multiplier overflow flag with the overflow bits of the multiplier into Register B.
RE: I am TSO - greatgamer34 - 10-09-2014
SPR=special purpose register
GPR=general purpose register
To set the flags, there needs to be a compare operation. The flags will only re update once a new compare op has been sent to the cpu. IIRC
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).
RE: I am TSO - TSO - 10-10-2014
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.