Architecture Comparison,questions. ..

[Magazorb]

@LD:
I don't need the intel manuals, because I'm looking at them right now, as I have been for weeks. I'm going to say again, they all total to at least 6000 pages, and the x86 manual is almost 4000 of those.

Also, x86 processors all use microcoding for nearly all operations. It is also used to manage things like security permissions and operating system interface.

2.2.1 Intel® Microarchitecture Code Name Sandy Bridge Pipeline Overview

Figure 2-4 depicts the pipeline and major components of a processor core that’s based on Intel microarchitecture code name Sandy Bridge. The pipeline consists of

• An in-order issue front end that fetches instructions and decodes them into micro-ops (micro-operations). The front end feeds the next pipeline stages with a continuous stream of micro-ops from the most likely path that the program will execute.

• An out-of-order, superscalar execution engine that dispatches up to six micro-ops to execution, per cycle. The allocate/rename block reorders micro-ops to "dataflow" order so they can execute as soon as their sources are ready and execution resources are available.

• An in-order retirement unit that ensures that the results of execution of the micro-ops, including any exceptions they may have encountered, are visible according to the original program order.

The flow of an instruction in the pipeline can be summarized in the following progression:

1. The Branch Prediction Unit chooses the next block of code to execute from the program. The processor searches for the code in the following resources, in this order:

a. Decoded ICache

b. Instruction Cache, via activating the legacy decode pipeline

c. L2 cache, last level cache (LLC) and memory, as necessary


2. The micro-ops corresponding to this code are sent to the Rename/retirement block. They enter into the scheduler in program order, but execute and are de-allocated from the scheduler according to data-flow order. For simultaneously ready micro-ops, FIFO ordering is nearly always maintained.

Micro-op execution is executed using execution resources arranged in three stacks. The execution units in each stack are associated with the data type of the instruction.

Branch mispredictions are signaled at branch execution. It re-steers the front end which delivers micro-ops from the correct path. The processor can overlap work preceding the branch misprediction with work from the following corrected path.

3. Memory operations are managed and reordered to achieve parallelism and maximum performance. Misses to the L1 data cache go to the L2 cache. The data cache is non-blocking and can handle multiple simultaneous misses.

4. Exceptions (Faults, Traps) are signaled at retirement (or attempted retirement) of the faulting instruction.

Each processor core based on Intel microarchitecture code name Sandy Bridge can support two logical processor if Intel HyperThreading Technology is enabled.

2.1 THE HASWELL MICROARCHITECTURE

The Haswell microarchitecture builds on the successes of the Sandy Bridge and Ivy Bridge microarchitectures. The basic pipeline functionality of the Haswell microarchitecture is depicted in Figure 2-1. In general, Most of the features described in Section 2.1.1 - Section 2.1.4 also apply to the Broadwell microarchitecture. Enhancements of the Broadwell microarchitecture is summarized in Section 2.1.6.

The Haswell microarchitecture offers the following innovative features:


• Support for Intel® Advanced Vector Extensions 2 (AVX2), FMA
• Support for general-purpose, new instructions to accelerate integer numeric, encryption.
• Support for Intel Transactional Synchronization Extensions (TSX)
• Each core can dispatch up to 8 micro-ops per cycle
• 256-bit data path for memory operation, FMA, AVX floating-point and AVX2 integer execution units
• Improved L1D and L2 cache bandwidth
• Two FMA execution pipelines
• Four arithmetic logical units (ALUs)
• Three store address ports
• Two branch execution units
• Advanced power management features for IA processor core and uncore sub-systems
• Support for optional fourth level cache

The microarchitecture supports flexible integration of multiple processor cores with a shared uncore subsystem consisting of a number of components including a ring interconnect to multiple slices of L3 (an off-die L4 is optional), processor graphics, integrated memory controller, interconnect fabrics, etc. An example of the system integration view of four CPU cores with uncore components is illustrated in Figure 2-2.

2.1.1 The Front End

The front end of Intel microarchitecture code name Haswell builds on that of Intel microarchitecture code name Sandy Bridge and Intel microarchitecture code name Ivy Bridge, see Section 2.2.2 and Section 2.2.7. Additional enhancement in the front end include:

• The uop cache (or decoded ICache) is partitioned equally between two logical processors,
• The instruction decoders will alternate between each active logical processor. If one sibling logical processor is idle, the active logical processor will use the decoders continuously.
• The LSD/micro-op queue can detect small loops up to 56 micro-ops. The 56-entry micro-op queue is shared by two logical processors if Hyper-Threading Technology is active (Intel microarchitecture Sandy Bridge provides duplicated 28-entry micro-op queue in each core).

2.1.2 The Out-of-Order Engine

The key components and significant improvements to the out-of-order engine are summarized below:

Renamer: The Renamer moves micro-ops from the micro-op queue to bind to the dispatch ports in the Scheduler with execution resources. Zero-idiom, one-idiom and zero-latency register move operations are performed by the Renamer to free up the Scheduler and execution core for improved performance.

Scheduler: The Scheduler controls the dispatch of micro-ops onto the dispatch ports. There are eight dispatch ports to support the out-of-order execution core. Four of the eight ports provided execution resources for computational operations. The other 4 ports support memory operations of up to two 256-bit load and one 256-bit store operation in a cycle.

Execution Core: The scheduler can dispatch up to eight micro-ops every cycle, one on each port. Of the four ports providing computational resources, each provides an ALU, two of these execution pipes provided dedicated FMA units. With the exception of division/square-root, STTNI/AESNI units, most floating-point and integer SIMD execution units are 256-bit wide. The four dispatch ports servicing memory operations consist with two dual-use ports for load and store-address operation. Plus a dedicated 3rd store-address port and one dedicated store-data port. All memory ports can handle 256-bit memory micro-ops. Peak floating-point throughput, at 32 single-precision operations per cycle and 16 double-precision operations per cycle using FMA, is twice that of Intel microarchitecture code name Sandy Bridge.

The out-of-order engine can handle 192 uops in flight compared to 168 in Intel icroarchitecture code name Sandy Bridge.

2.1.3 Execution Engine
The following table summarizes which operations can be dispatched on which port.
The reservation station (RS) is expanded to 60 entries deep (compared to 54 entries in Intel microarchitecture code name Sandy Bridge). It can dispatch up to eight micro-ops in one cycle if the micro-ops are ready to execute. The RS dispatch a micro-op through an issue port to a specific execution cluster, arranged in several stacks to handle specific data types or granularity of data.

When a source of a micro-op executed in one stack comes from a micro-op executed in another stack, a delay can occur. The delay occurs also for transitions between Intel SSE integer and Intel SSE floating-point operations. In some of the cases the data transition is done using a micro-op that is added to the instruction flow. Table 2-23 describes how data, written back after execution, can bypass to micro-op execution in the following cycles.

That comparison is not unfair. At some point in the late 70's, programmers began to realize that all this microcoding was equivalent to a runtime compiler interfacing to a much simpler processor than what the microcoding modeled. RISC was born from the idea that there is a loss in processor power when it is forced to spend some of it's time going through microcode and figuring out what the hell you just asked it to do and then finally decoding into what was often an entirely different instruction set to finish. The RISC model is to place all of the operations' coding on the programmer and then have only that basic core processor that took the micro-ops that the CISC micro-code gave. In essence, you wrote the compiled output of the microcode yourself instead of having the CPU do it for you. (Also, I though ARM was a lot older, but it doesn't matter because I know for a fact that some of Sun Microsystems' RISC possessors are damn near as old as x86.)

@maga:
The memory system is about 100 (very important) pages and just explains the instruction fetch delay depending upon witch cache level you are accessing as well as data types, all the registers, the memory limitations based upon the execution mode, and much much more.

Yorn, man your just a suborn fan-boy of the x86, fact most IPs use 90% of the things x86 use and then add a ton of features more, most documentation for architectures use references to x86 that would be several hundred pages long for all the nitty gritty and then explain the difference, saving them many pages, goes back to the old programming saying "Don't repeat your self" stop following your father blindly, he says things about modern programmer and how they "have the speed to not have to program efficiently" THAT IS WRONG!, coders don't program, don't ever confuse a coder and a programer, a coder is a retard and a programmer is a engineer, the fact you concistantly blindly against us as if you're god is becoming annoying, you're statments majority of times are incorrect and you treat them like law.

Do your research please, x86 isn't a big architecture, hence why other architectures incorpate it, their are some architectures that are so big that adding x86 to it would be a pain, guess what ARM is one of those, they arent a architecture there a IP, a company with many architectures and some of them really are good and much more advanced then x86, Haswell is so heavily expanded on x86 to give nothing but serial computations (infact back in earily 2000's intel made a 7GHz processor prototype as a attempty to get even more serial computation out of their cores, they failed measable with requiring so much power and gained so little performance) that they just contiune adding as much as they can to get as many instructions about what's going to happen and start speculating, this wasn't defined in x86 orginaly, but i'll contiune saying that x86 is as what intell wants to call it (although they did a dirty move to call it theirs ages ago when it was some other guys and then got law suits made so that AMD couldn't use it but that resulted as having all the different names for what's still x86 but with extensions, yes intel had done some bad stuff but they seem mostly nice these days)

If you really insist for me to give you a nice example of what destroys x86? CBEA is one (this actual dominated the computational market in the 2000's, no x86 machine could keep up, even today the aging arch with no update still can outperform modern x86 in computation), PCP is another, Mill is also a 3rd.

now to go back to microcode, did you know most code is focused on intels "x86" so they run signicantly better on intel hardware then AMD? no probably not, and code that's focused on AMD tends to run not so well on intels chips, this is a fact and people do still do this, just because your too ignorant to open your eyes to realise it's still being done (infact more now then ever before and this will only ever continue to expand with many alternative archs getting funding to become competitive, heck AMD has released statements saying they will support other archs as well as x86 and have proccessors that will just happen to run code of the other)

you're arguments come from where? where's your evidence, where's your references? like you just make points over and over that we can't find anything to support them, we do our research a lot, as of late lord more so then me, but we tend to have a idea what we're talking about and then you just seem to arguagainst what we say pointlessly, then you seem to think your right, then you seem to stray from what you orginaly said and pretend that's what you said in the begining when it agrees with what we was saying the whole time and then pretend you was right... but if we ever make open suggestions or point it out that's what we said at the start but you said no you don't respond.

It's unlike me to question other peoples research as it's not often can i say I've researched what they have, but now i have to question, where on earth is your research coming from? my assumption is your dad as it's very x86 and that would have been the arch of the time, but you seem unacknowledged of any other archs... and you seem suborn that other archs aren't competitive, i can't comprehend where on earth this seems to be comming from...

I'm sorry if this seems like a forward attack but i really need to rant about this about you because it's bugging me and being as much as i like to learn new things question people seems to very good for learning

So please do share with us where your knowledge has came from.