Instruction sets and their implementation

[Namira Fang]

How exactly are instruction sets built into the CPU package? Obviously has to be done with hardware otherwise they could just use a driver to implement them.

Also, I know AMD is constantly playing catchup to Intel in every regard but with Kabini still as far away as it is could they implement AVX2? I know AMD wants to go the route of HSA but why wouldn't they go AVX2 if they had the option. Is AVX2 even in AMD's plans for the future?

 

[Olikan]

How exactly are instruction sets built into the CPU package? Obviously has to be done with hardware otherwise they could just use a driver to implement them.

Also, I know AMD is constantly playing catchup to Intel in every regard but with Kabini still as far away as it is could they implement AVX2? I know AMD wants to go the route of HSA but why wouldn't they go AVX2 if they had the option. Is AVX2 even in AMD's plans for the future?

nop, they can't implant in kabini...
AMD probably will go for AVX2 when they can, XOP instructions, found in bulldozer is basicly a baby step for AVX2....so it might not take that long

HSA is a way to make the use for GPU computing, avx2 and hsa aren't really enemy's...but they do share many benefits

IMO, i think avx2 is better for us, in desktops and laptops, simple because of the easy to write in softwares...
HSA, will help more in consoles, tablets, phones and supercomputers... where programing close to metal, or make use of that "useless gpu" helps more

 

[ThePeasant]

Microarchitectures have fixed (probably) internal 'instruction sets' which are essentially architecture specific languages that expose all the functionality of the hardware as they were designed. So if you designed an ALU that can add two registers you would have some internal instruction to instruct that ALU to add two registers as well as everything else in the CPU to facilitate that happening.

One reason this is done is to provide abstraction; programs can target a stable ISA (hopefully) while architectures are free to change implementation as long as they adhere to the interface defined by the ISA. Decoders are responsible for translating (not always one to one) the instructions as specified by the ISA to this internal format.

It is possible to emulate instructions from an ISA that were perhaps not originally part of the specification of a design using microcode (depends on the architectural limitations and the instruction) and CPUs have been known to have unexposed functionality. As for Kabini, I can say that in its current form I really doubt it will have AVX2 (especially considering Intel has yet to implement its own extension). Whether it has the ability to do AVX2 (at least partially) I can't say unless I had access to kabini's design and the ability to understand it.

As for whether AMD will implement AVX2, I think they will eventually (they will at the very least build the capability to do it). Because adoption tends to ramp slowly at first I view the typical lag as an advantage honestly, they trade the ability to dictate where the ISA goes for differed costs and complexities.

 

[Phynaz]

Instructions are built into the processor using a combination of hardware and microcode (think firmware).

Today's x86 processors don't actually run x86. The processors convert the x86 code into their own internal code. From there simple instructions are executed directly on the hardware. More complicated instructions are either broken down further or make a microcode call which contains the CPU instructions for the x86 instruction.

Arstechnica has a series of articles on cpu architecture that are very, very good.

Drivers are used to provide a software interface to hardware controllers. Every single piece of hardware in your computer has a controller and a driver to access that controller.

Trivia question - did you know your computer has a keyboard controller? Do you know where it's at?

 

[VirtualLarry]

Trivia question - did you know your computer has a keyboard controller? Do you know where it's at?

Did you know that there are actually two keyboard controllers, for a PS/2 keyboard? One in the keyboard, and one in the system chipset.

Back in the AT days, the keyboard contained a discrete uController, and so did the system board. 8154 or something like that. (Edit: 8042)

http://www.computer-engineering.org/ps2keyboard/

 

[john3850]

What is the name of the old intel x87 instruction that limits amd in Super Pi.
Why cant the super pi code just be changed to help amd.

 

[Namira Fang]

I would think that will all the hub bub over AVX2 by Intel and the like that AMD would be all to eager to adopt it as quickly as possible.

Is Intel the one coming up with these instruction sets(least most of them) and if so does AMD have to pay a royalty or some sort of fee to use said instruction set in one of their CPU's? Can't imagine Intel would just happily part with that technology or info. And not sure if you could reverse engineer something like an instruction set...

 

[Mark R]

Is Intel the one coming up with these instruction sets(least most of them) and if so does AMD have to pay a royalty or some sort of fee to use said instruction set in one of their CPU's? Can't imagine Intel would just happily part with that technology or info. And not sure if you could reverse engineer something like an instruction set...

Both companies have come up with instruction sets and extensions. Intel came up with MMX, SSE, AVX, etc. AMD came up with 3DNow, etc. which are effectively equivalent, but have different codes and slightly different operations.

AMD also invented x86-64 (which all Intel desktop/mobile CPUs now use for 64 bit mode).

AMD and Intel have quite wide-ranging license agreements for the various extensions and instruction sets.

Instruction sets don't need to be reverse engineered. They are a published specification, which indicates what the CPU does under specific conditions. Programmers need detailed information about the instruction set in order to program the CPU; there's nothing technical (although there may be legal protection) preventing anyone from reading those specifications and making a CPU that does the same thing in the same circumstances.

 

[ThePeasant]

I would think that will all the hub bub over AVX2 by Intel and the like that AMD would be all to eager to adopt it as quickly as possible.

As with any new instruction set, adoption is what is important. Even if processors with AVX2 sell well, they will be dwarfed by the number of pre-existing processors which do not support it and likewise software support will lag. So it will take time for AVX2 to show returns. The advantage to AMD being that they can (or are forced to) defer the costs of implementing these new extensions until they gain more traction and they avoid some of the upfront cost involved in getting developer adoption up (maturing the tools and knowledge).

Is Intel the one coming up with these instruction sets(least most of them)

AMD does come up with their own ISA extensions (the most ubiqutous being x86-64). However, their market power relative to Intel causes disproportionate adoption rates.

does AMD have to pay a royalty or some sort of fee to use said instruction set in one of their CPU's?

I don't know the details of the cross licensing agreement but I speculate that there are no royalties between them.

Can't imagine Intel would just happily part with that technology or info. And not sure if you could reverse engineer something like an instruction set..

ISAs aren't dark nebulous entities, and unless they are I wouldn't call implementing them 'reverse engineering' (implementations can be reverse engineered though). Various legal and time constraints might hinder or delay their implementation however.

 

[MisterMac]

Consider it like Algebra.

Both AMD & Intel need to understand Algebra to calculate\use it.


...however between both of them - the other might have a stronger mind capable of calculating faster.

Same goes for ISA's\Instructions.

 

[Namira Fang]

Yeah, I suppose you couldn't really keep something like ISA's a secret cause then they would be adopted by no one. Would ideally I suppose want them to be as close to common knowledge as possible.

 

[Mir96TA]

Did you know that there are actually two keyboard controllers, for a PS/2 keyboard? One in the keyboard, and one in the system chipset.

Back in the AT days, the keyboard contained a discrete uController, and so did the system board. 8154 or something like that. (Edit: 8042)

http://www.computer-engineering.org/ps2keyboard/

yea those controller require A20 Line gate controller with iRQ 9 which was cascade to iRQ 2

 

[Idontcare]

Yeah, I suppose you couldn't really keep something like ISA's a secret cause then they would be adopted by no one. Would ideally I suppose want them to be as close to common knowledge as possible.

Does anyone really need to know though beyond the compiler development level?

How intentional do you have to program for say AVX2 anticipating in advance you will compile for it?

Just make your code and press the magic compile button in the compiler, let it spit out the executable black-box style and keep me unawares as to how or why it runs faster or slower on various microprocessors (because I am then, in that hypothetical world, equally ignorant of the ISA for the various microarchitectures).

 

[TuxDave]

What is the name of the old intel x87 instruction that limits amd in Super Pi.
Why cant the super pi code just be changed to help amd.

There's always option #2. Use something else besides Super Pi to benchmark.

 

[NTMBK]

Does anyone really need to know though beyond the compiler development level?

How intentional do you have to program for say AVX2 anticipating in advance you will compile for it?

Just make your code and press the magic compile button in the compiler, let it spit out the executable black-box style and keep me unawares as to how or why it runs faster or slower on various microprocessors (because I am then, in that hypothetical world, equally ignorant of the ISA for the various microarchitectures).

Pah! Give me hands on optimization any day of the week. Screw portability, I want it fast today

 

[Namira Fang]

Does anyone really need to know though beyond the compiler development level?

How intentional do you have to program for say AVX2 anticipating in advance you will compile for it?

Just make your code and press the magic compile button in the compiler, let it spit out the executable black-box style and keep me unawares as to how or why it runs faster or slower on various microprocessors (because I am then, in that hypothetical world, equally ignorant of the ISA for the various microarchitectures).

I would have thought that in order for the programmers to take advantage of the new instruction sets they would have to incorporate it into the programs they are coding. Otherwise a number of programs already written would be able to take advantage of AVX2 and the like without ever having been written with AVX2 in mind.. Would be nice if it worked that way but I'm guessing it doesn't. Ignorance on my behalf.

 

[NTMBK]

I would have thought that in order for the programmers to take advantage of the new instruction sets they would have to incorporate it into the programs they are coding. Otherwise a number of programs already written would be able to take advantage of AVX2 and the like without ever having been written with AVX2 in mind.. Would be nice if it worked that way but I'm guessing it doesn't. Ignorance on my behalf.

Generally speaking, the compiler is where that stuff comes in. The coder writes code that does a loop of something 8 times, then the compiler converts that all into a single, fat, AVX2 instruction. Of course in theory, JIT compiled code (like Java or .NET) could take advantage of it just from an updated runtime.

 

[Namira Fang]

So then really the "optimizations" for AVX2 falls on those that are making the compiler and not those that are actually writing the programs. This would certainly simplify things and I would think(maybe hope) speed up the adoption of new ISA's.

 

[bononos]

I would have thought that in order for the programmers to take advantage of the new instruction sets they would have to incorporate it into the programs they are coding. Otherwise a number of programs already written would be able to take advantage of AVX2 and the like without ever having been written with AVX2 in mind.. Would be nice if it worked that way but I'm guessing it doesn't. Ignorance on my behalf.

Like the poster above said, the details can be left to the compiler. All a developer has to do is pick up a box which says AVX2 supported in bold bright colors and click compile. No reason for a programmer to delve into assembly unless there really was some pressing need to.

 

[NTMBK]

So then really the "optimizations" for AVX2 falls on those that are making the compiler and not those that are actually writing the programs. This would certainly simplify things and I would think(maybe hope) speed up the adoption of new ISA's.

Generally speaking, yes. However, sometimes in order to squeeze maximum performance out of a program, we'll delve into the dark voodoo of inline assembly and intrinsics- where the code we write (generally) maps directly to specific processor instructions. In this case, moving to new ISAs (like AVX2, or Xeon Phi instructions) will require a hefty rewrite of the code. These cases are fairly limited, but they usually also tend to be the cases most sensitive to performance (the ones which most need performance are the ones which get the most intensive optimization).

 

[Idontcare]

There's always option #2. Use something else besides Super Pi to benchmark.

And option #3 - if AMD wanted to make their customer's experience with x87 applications be comparable to what Intel's customers experience then AMD could prioritize it and make it so.

When the road is bumpy and Ford makes it a smooth ride by equipping their cars with superior, and more expensive, shock absorbers it would be kinda backwards for Dodge car owners to expect the city to make the roads smoother just for them so they can experience what Ford owners experience already.

Dodge should equip their cars with shock absorbers too, if they wanted their customers to have a smoother ride that is. But if they don't, well then Dodge's customers are kinda getting exactly what they paid for and deserve at that point, right?

 

[Namira Fang]

Like the poster above said, the details can be left to the compiler. All a developer has to do is pick up a box which says AVX2 supported in bold bright colors and click compile. No reason for a programmer to delve into assembly unless there really was some pressing need to.

Lol.. Nice to see compilers are sold like cars are. 40mpg!! Sunroof!! 0-60 in half a second!! AVX2 support!!

Are OS's and programs built in much the same way then? Would Win7 benefit from those ISA's(I'm guessing any and all software could) and could they be implemented through an update?

 

[inf64]

x87 is becoming ever so irrelevant so no wonder AMD is not putting effort into improving that aspect of their x86 cores. They are working hard on SIMD performance and HSA offloading ,which is the next big thing in computing.

 

[Idontcare]

So then really the "optimizations" for AVX2 falls on those that are making the compiler and not those that are actually writing the programs. This would certainly simplify things and I would think(maybe hope) speed up the adoption of new ISA's.

That was the point of creating programming languages in the first place.

The idea was that it would be easier for programmers to construct code in a generalized language, say Fortran or C+, and then a compiler would exist (made by people who were paid to deal with the nuances of assembly code and performance optimizations for specific microarchitectures and ISAs) that would compile the code in a black-box manner into the requisite assembly code for the targeted machine types (386, 486, etc).

But, as is true with all things, depending on the qualities of the programmer and the necessity of performance from the finalized product there is always opportunity for the programmer to upstate the compiler and create an optimized code/compiler pairing that delivers unparalleled performance.

The compilers are themselves after created by humans and will only be as capable in generating optimized code as the compiler was optimized to do.

Think of it like a compression algorithm. Why didn't we have MPEG4 compression algo's in the 1980's? Because the humans in the 1980's who made a living making those algorithms were at best capable of creating compression techniques the likes of JPEG. MPEG2 and more advanced algo's simply weren't conceivable at that time.

Compilers are like that too, their utility is limited by the genius of their makers. So compilers are always improving, as are the people who make them, but in the meantime that means they can also be upstaged or improved upon (have their nuances taken into account and optimized) by truly talented programmers as well.

So those guys aren't going to want black-box compiling, nor would the compiler teams want to limit those programmers to mere black-box capabilities. So in reality programmers are made aware of the ISA and its nuances.

 

[Namira Fang]

Yeah, the ignorance for me was actually thinking that the ISA's were actually more akin to an actual programming language than assembly code. Seeing things like AVX2 defined in that other thread was what had kinda led me to believe it was more the former than the later.