redacted

Interesting, but oversimplified, of course. Microprocessor design is very complex and advanced, and introducing pipelining makes it even more complex. Then you have branch prediction, caching, etc. that is a mess.

I suggest you google for microprogrammed control units. Control units at their most fundamental and basic level are just state machines that control the data path units, such as ALUs and registers.

I suggest that you take a look at the ARM instruction set if you want to see CPU instruction design at it's most elegant. It features several of the things you were thinking of, and is incredibly well thought-out.

Quote:

Original post by Nice Coder Egsample: ADD reg1 Reg2 Reg3 (reg3 = reg1 + reg2) SUB reg3 reg2 Reg4 Now, both of these would be executed simultaniously, by the way that the parellel instruction set works. It executes as many instructions simultainiously as possible and theres guarenteed to be more then one addition bank on the chip.

You're not making any sense at all. First of all

ADD reg1 reg2 reg3
SUB reg3 reg2 reg4

can never be executed in parallel. The result of the second operation depends on the result of the first operation.

Quote:

So now, if you wait long enough, it does both the addition and the subtraction together, without the result going to the register (saving some time?).

If the result doesn't go in a register (which contradicts what you said earlier), where does it go? Do the banks write the ALU results straight to memory?

Quote:

Branch predictions not going to be very worthwile in this little processor. This is because every instruction can run from any register to any register (or constants, for normal operations), you could litterally multip.y the instruction counter by two, before adding a register to it. Also, lots of things run in parellel, and these would probably run simultaniously. What do i mena by that?

What does this mean? How does an instruction run from a register? Registers load and store data, they do not "run" anything. You also didn't answer what the processor would do when it encounters a jump. Does it assume branch taken? Does it assume branch not taken? Does it load both branch taken and branch not taken in parallel, then flush the one that's wrong when the result is known? What does multiplying the PC by two and adding a register to it have to do with branch prediction?

The context switch regs are already implemented in some chipsets. Though they
are not "slower" it is more of a processor mode switch. You tell the chip
to switch to bank X then those are the registers that are used. You still
push and pop regesters to the stack, but you can swap you apps in/out of
bank1, and keep the kernel in bank0. All the banks of regesters are fast
regesters, but you only have 2 or 3 sets of them to work with.

Some of what you are talking about sounds like multi-processor designs, or
something that you should look at the Cell chipset (think "banks" of processors?)

Add r3.... to a sub .. r3, the "flow" you talk about is already part of pipelining on most chips.
But, the "flow" only works within one ALU, otherwise you need too many communication lines between the ALU's.
Even with this "flow" it still takes time to calculate, so there is
no point in exicuting Subtract untill the Add is done/almost done. Your tieing
up one of you ALU/processor things with instructions that can do anything imediatly, so you have gained nothing but complexity.

Branch prediction is key if you dont want bad preformance from unneeded mem-fetching, and unneeded stalls in computation.

If every instruction can change the state of the system, you cant run them in
parallel if you expect the result to be defined. Again, back to the add r3, sub r3. You have a standard race condition there, and one of the two needs to exicute first, or you could get:
5-2 = 3 running with 5+3 = 8, so you get 5 or 8, but the instructions exicuted
in order give 5-2+3 = 6, is what you really wanted to happen.

[Edited by - KulSeran on March 11, 2005 4:09:42 PM]

Again, look at the Cell processor, since it works the cache like a block of mem.
Good because you are in complete control.
Bad because you are in complete control.
I'm not sure how this one is going to work out for everyone. Prolly like
everything else, horibly at first but much better once people get the hang
of it and start writing to others about how to use it.

And the "flow" design is already implemented in the pipeline, since
a single ALU on some chips has a feedback loop, so that you can feed the output
of a step in as the input of the next step.
the problem with your "flow" is that you are trying to do it across alu's,
so every alu needs access to the result of every alu... ie the regesters. or
a massive amount of complexity in dataflow lines.

You use fast regesters since a switch of a single reg ( the mode ) is faster
than any read/write of a list of regesters. So a context switch takes only
one write, and not many. ( in the best case )

Quote:

No waiting to get things out of registers, or even waiting for something to finish!

No registers: feed outputs back as inputs. in a chain. only works in some cases.
or wait for finish: if A->B, you need A before you can have B, something has
to finish at some point before the next step takes place, even if you are passing
the result through to the next step without taking time to store it.

[Edited by - KulSeran on March 11, 2005 6:51:44 PM]

Quote:

Original post by Nice Coder if your wondering about flow-through, maybe this would help. For the commands: ADD reg1 reg2 reg3 SUB reg3 reg4 reg5 Which is basically reg5 = (reg1 + reg2) - reg4 You start off, working out the first few bits of the add (ripple adder in this egsample, its a little harder to explain when your using more complex adders). That means that noe, a few bits of the output change. Those then go back (via a few switches) to reg3, where it gets written to and read from (by the sub unit), which then reads back the result. So now, its like the two units are connected together, via the register, so instead of waiting for the add to work, then do the sub, your doing both, simultainously. Nice eh?

No, it's not like the two units are connected together. I don't think you understand how registers work. You don't just write to a register a few bits at a time and hope that the next ALU unit is getting the correct answer. Registers are typically not transparent to their input. Usually, they latch onto their input either on a rising clock edge or a falling clock edge. This allows the circuit to be synchronized and prevents various elements of the processor from reading junk values from a register. You would have to wait until the ALU operation is complete before loading it into a register. Read after write dependencies in typical hardware is handled by data forwarding, a tried and true technique. I don't see why you need to conjure up a half-baked idea to solve an already solved problem.

Quote:

Its a bit complex, but it should work well. (imagine computing a whole function in series parallel, as if you actually made a circuit to do it. No waiting to get things out of registers, or even waiting for something to finish!)

Outside the realm of imagination, you can't compute an arbitrary function in parallel. Processors have pipelines to increase throughput, but dependencies are still unavoidable. Once again, you're coming up with half-baked ideas that don't hold a candle to what thousands of engineers at Intel, AMD, and other companies came up with many many years ago.

Quote:

Also, i'm not adding complexity, because i would have to add additional circuitry to prevent this.

The following statement is false.
The previous statement is true.

Adding additional circuitry is the very definition of adding complexity.

You main issue Nice Coder, is synchronisation.
You keep trying to due atomic operations on the same variable. Both
in parallel. It is not posible to predict the results of the action,
unless you know for a fact that one starts after the other.

And as cwhite stated, you will end up adding complexity if you try to formulate
something other than a clock to make sure everything happens to what you want
when you want.

(removed post quoted below, since i noted "test", and testing indicates that
it will NOT work on anything but a ripple adder setup, and only on add/subtract.
AND needs bit level syncronisation, so it takes more time than WORD level. )

[Edited by - KulSeran on March 11, 2005 7:00:09 PM]

Quote:

Original post by Nice Coder That doesn't seem to work well either (I'm trying to keep the clock out as much as possible for the alu, and iether way, its just complex.), How do other systems do this? (or do you have an idea?)

They use something called a clock.

Also:

There was a fun article in Scientific American in 2002(03?), about clockless chips.
In the place of a single clock line, they had to replace each logical gate
with a special logical gate that had 4-8 more transisters on it... and those are the basic building blocks of digital electronics. Just imagine the complexity of it.

Clocks are simple and easy compared to other ways.

NOTE: electronics have a limit to how fast they can settle to a steady state.
Clock ticks are spaced to make sure everything has time to settle.
If you try to do too much with a circut feedback without
gating the feedback, it takes forever to settle (or never does.. flipflops)
Clocks allow gating of the feedback.

[Edited by - KulSeran on March 11, 2005 7:10:40 PM]

The idea of parallelizing at the instruction level is not a new one. Intel's Itanium does it, but it doesn't try to do it "automatically" like your design, it relies on the compiler to tell it when statements can be run in parallel. That is, it has special instructions which tell the processor when things can run in parallel.

The circuitry needed to synchronize two related instructions to run in parallel would be far too complex to be practical. The Itanium idea takes unrelated statements, where the output of one is not used as input for others, and runs them in parallel. That's far cheaper in terms of transistors and synchronization.

So for example, say you have some high-level code like:

A = (B + C) * D
W = (X + Y) * Z

which isn't completely impossible. Now, in your idea (if I understand it correctly) you'd end up using the result of adding B and C to multiply it by D at the same time. On the Itanium, the compiler would reorder the assembly such that you can add B and C together and X and Y together at the same time, then the multiplications could also be done at the same time. Because all the results are unrelated, there's no synchronization needed, and the circuitry's all rather simple.

On the other hand, Intel's idea puts a lot more emphasis on smart compilers (and they are getting smarter) so you do need to have a good compiler to make the most of it.

A fundamental principle of any hardware design is that smaller equals faster. The more busses, wires, gates, register files, caches, ROMs, etc., you add to the processor the slower it's going to be by virtue of propagation delay. Remember that your clock cycle has to long enough to handle the slowest single-cycle operation your processor performs. The concept you're thinking of, where results from one instruction are routed to another instruction without using the primary source (memory/register file) is similar to bypassing in a pipelined processor design. However, I think what your suggesting is an extremely complex bypassing/forwarding scheme. I'm not really clear on your design, but it sounds like you'd run into some major synchronization and racing issues, or it would just have some tremendously complex control logic and run slowly.

Do you know anything about parallel computation at all? Everything you've posted assumes a perfectly linear speed-up, which does not occur because of dependencies. You're throwing out buzzwords in butchered english and claiming that somehow you're going to create a processor in your spare time that's somehow going to be lightyears faster and cheaper than the best piece of hardware Intel, IBM, Apple and AMD have out. You've given no answer to how you're going to synchronize this thing to prevent race conditions and you also haven't taken into account the heat that would be produced if your linear speed-up were possible. I hate to crush your dreams, but you have a ton of research to do before you can even talk about processor design seriously. If you don't want to be taken as a joke, I suggest you start doing some lit review. And Asimov does not count as a lit review.

Again, the central idea behind what you're proposing is already known as forwarding (in the context of a pipeline but same notion here). However I don't think you've actually considered the amount of circuitry and control required to manipulate and synchronize thousands of banks. You seem to be just waving your hands and saying it won't be a problem, but have you actually considered the number of components and gate delays required to implement this processor? Second, you're also overlooking all the possible structural and data hazards that could occur due to parallel processing, i.e. two parallel instructions finish at the same time but write to the same register. And what about multi-cycle operations? If you plan on turning these into single-cycle instructions by "unrolling" the cycles, then you further increase the amount of circuitry and propogation time. And what about fetching all these instructions from memory? Or the time required to write and read from the register file? And non-ALU instructions such as load, stores, and branches need to be taken into consideration too. If you accidentally start processing thousands of mispredicated instructions, things could turn ugly.

While I think you're on the right track by considering ways to increase thruput, hundreds or thousands of banks with all the extra control will make your processor bigger and slower. You can't just wave around imaginary numbers and say that's how fast things will be. Maybe, theoretically, you could get away with somehow paralizing thousands of instructions per cycle (if you're lucky), but the synchrozation combined with control and delay would kill your clock.

You can't just have multiple instructions running through several of these banks in a single cycle and then not worry about synchronization, because this is an ideal racing condition scenario. The problem is that circuits have no notion of timing. They'll just operate as fast as they can, close to the speed of light (not exactly because a transistor state switch change takes a bit of time). However this behavior can be unpredictable and unreliable, which is why you introduce another more reliable timing mechanism - the clock. Another problem is that circuits have no notion of doing "work". Transistors will respond to changes in voltage with altered current flow, but that's it. So if you have something like a ripple-carry adder or carry-lookahead adder that takes a certain amount of time to propagate before you have a meaningful result, you need the clock to "know" how long it takes for this to happen. But once you start introducing multiple concurrent instructions, none of the individual instructions know they're running in parallel with any other instructions because this is part of the notion of increasing throughput, which is directly related to increasing work done per unit time and transistors have no notion of meaningful work or computation.

I guess my point is that you can't just leave these things up to their own devices. You need the extra synchronization, and when concurrent processing is involved in a single processor or datapath you need to add the extra cycles so that you can increase your throughput without falling victim to unwanted hazards. Essentially these basic electrical components have no idea what kind of grander scheme they're involved in.

This all comes back to how pipelined processors managed to increase throughput. If you want to do this on the instruction level, then you need to split up an instruction into atomic stages. This is what allows multiple instructions to be executed at once, because while one instruction is on a later stage a new instruction can start at an earlier stage, and since the two sections of circuitry are independent they can be done in parallel. Pipelining your processor has the effect of increasing CPI and CPS, which about cancel each other out. However you have that raw increase in throughput which allows you do get more work done in a fixed period of time. Now your worst case scenario is that only one instruction is in the datapath at once (i.e. one stage is an active instruction and the rest are nops), and the best case scenario is you're able to have as many concurrent instructions being processed as there are stages.

[Edited by - Zipster on March 13, 2005 3:00:06 PM]

Quote:

Original post by Nice Coder But i'm relying on smart compilers/coders!.

That's one of many reasons your processor is a bad idea.

Quote:

Also, how would i do lit review? (litterary review?)

A literature review is what real researchers and engineers do. They read the recent literature in a field so that they actually know what they're talking about (gasp). You do a lit review by reading journals, conference proceedings and textbooks.

Quote:

And please don't insult my spelling/grammer. Its hard to write clearly when your thinking....

It's hard to write clearly when my thinking? What does that mean? And a contraction of "it is" to "it's" has an apostrophe. Seriously, though, if you can't communicate an idea then nobody will be able to understand you. Your posts look like crap posts when you don't take the time to proofread your posts and/or use appropriate style to convey an idea. Other posters don't seem to have difficulty conveying their ideas in writing. This is not the only thread where I have seen your inability to wield the english language cause you to crap post. I would be sympathetic and understanding if you were from a country where english was not the standard language, but you are from Australia.

Quote:

how am i throwing out buzzwords?

When other posters who understand hardware design have posted valid reasons why your processor will not work, you throw out buzzwords and start waving your hands to answer them. For example, many people have posted replies talking about the need for synchronization. Most of these replies have noted that synchronization is hard and often requires a great deal of extra circuitry. You respond to these posters by tossing out buzzwords like "bus" and "barrel shifter" and say that synchronization won't be needed. Nobody is going to think that you know more about hardware design because you googled for barrel shifter. The fact that you know very little about actual hardware design is quite transparent.

First of all, parallelising a problem is REALLY HARD in the general case. And when you do succeed you tend to require lots of communication. Look up Amdahl's law.

And I hate to be blunt but you don't know jack shit about processor design. Read the book "Computer architechture: a quantitative approach" by Hennessy, Goldberg and Patterson ( http://www.amazon.com/exec/obidos/ASIN/1558603298/102-9711485-7224123 ) You'll learn LOTS, I promise.

I'm moving the thread to "General Programming" since the thread is not so much about math & physics.

another thing would be multipiped processors

the compiler examines the code you have written and looks if within a certain range of your code there are a few operations that don t influence the result of others and process those parallel to the rest of the cpu work thus maximizing the throughput of the processor

e.g. doing vector additions ...

does SSE or 3d now do this already?

Get yourself an inexpensive FPGA (Spartan-3 is good) or use the one at school if you go to school and they have some, and try your design out. You'll quickly realize will work and what wont. http://www.opencores.org/ has soft CPU cores for reference.