What is EM64T enhanced mode?

[TuxDave]

Wouldn't it be worth removing it? It may not be for a single generation, but when you consider just how many generations have had it... even if it were something silly like a penny shaved off of every chip... that's a ton of pennies.

Let VIA or AMD take the legacy x87 dinosaurs...

If you want to talk numbers, I'm sure you can derive an equation showing:
X engineering hours = Y um^2 of die space.

However, there's still a non-trivial amount of software that ends up calling on x87 FP instructions so maybe the equation is:
X engineering hours to remove + Y engineering hours to deal with supporting all the people who care about x87 compatibility = Z um^2 of die space.

I think the lack of savings usually come from the fact that x87 hardware is purposely designed to consume space you couldn't use anyways and stay out of all frequency limiting paths. If that remains true, then it's just extra junk on the side that does no harm. That's my personal opinion.

 

[jhu]

People who purchase Xeon Phi but don't care about using the vector instruction set because they don't want to use ICC? Why would anyone bother? I don't think this scenario is credible.

It's not like Knight's Landing is getting all the SSE instruction sets Silvermont cores have so they don't have a problem removing stuff there...

It did come up every once in a while. But it looks like gcc 4.9 does have support for avx-512.

 

[NTMBK]

It's not like Knight's Landing is getting all the SSE instruction sets Silvermont cores have so they don't have a problem removing stuff there...

Are you certain about that? It's getting AVX-512 to replace the old KC extensions, to bring it into line with Skylake. I would be very surprised/disappointed if they didn't also add SSE support. Certainly as a standalone socketed CPU, the ability to run a bit of legacy SSE code to deploy tools/set up environment/whatever would be very nice, even if your kernels are obviously written in AVX-512.

 

[Exophase]

It did come up every once in a while. But it looks like gcc 4.9 does have support for avx-512.

Okay, I guess it could be viable for someone doing proof of concept work as a (probably student) research project on hardware that they probably didn't have any connection to buying. But for something involving a real attempt to get meaningful work done, I'm skeptical.

Are you certain about that? It's getting AVX-512 to replace the old KC extensions, to bring it into line with Skylake. I would be very surprised/disappointed if they didn't also add SSE support. Certainly as a standalone socketed CPU, the ability to run a bit of legacy SSE code to deploy tools/set up environment/whatever would be very nice, even if your kernels are obviously written in AVX-512.

Okay, turns out I don't have a source on this one, so no, was just a guess and possibly a mistake.

But I think this idea of compatibility with ancient x86 binaries on Xeon Phi is really funny. They clearly didn't care with SSE so far. And it's not like they just bolted LNI onto an i586 class instruction set, they did move it to x86-64 (except not including SSE2 which is normally implied)

And with Knight's Landing they don't even care about maintaining binary compatibility with previous generation MIC. You'd think that'd be more relevant, if anything really is.

 

[NTMBK]

And with Knight's Landing they don't even care about maintaining binary compatibility with previous generation MIC. You'd think that'd be more relevant, if anything really is.

Nah, getting compatibility with mainstream Xeon is more important. With Skylake having the same vector instructions, you would literally run the same vectorized kernel on either Xeon E5s or Xeon Phis. Write once and run on both- getting closer to actually fulfilling the Xeon Phi dream.

 

[Exophase]

Nah, getting compatibility with mainstream Xeon is more important. With Skylake having the same vector instructions, you would literally run the same vectorized kernel on either Xeon E5s or Xeon Phis. Write once and run on both- getting closer to actually fulfilling the Xeon Phi dream.

I can't say agree with this either. Code really should be optimized and even written differently for both platforms, to make effective use of either of them. If you have software that's scaling from a few dozen threads to a few hundred then it's probably not very efficient on one end of the spectrum or the other.

 

[NostaSeronx]

What is the possibility of a fixed function x86 unit processing x87/SSE2. While the main cores only process AVX/AVX2/AVX(x) in enhanced "AMD64"/"Intel 64" mode. The L3 would guide x87/SSE to the fixed function unit and AVX/AVX2/AVX(x) to the enhanced cores.

Enhanced Mode(Enhanced Unit) - Pseudovector architecture
Normal Mode(Fixed Unit) - Superscalar Architecture

 

[Exophase]

What is the possibility of a fixed function x86 unit processing x87/SSE2. While the main cores only process AVX/AVX2/AVX(x) in enhanced "AMD64"/"Intel 64" mode. The L3 would guide x87/SSE to the fixed function unit and AVX/AVX2/AVX(x) to the enhanced cores.

Enhanced Mode(Enhanced Unit) - Pseudovector architecture
Normal Mode(Fixed Unit) - Superscalar Architecture

This doesn't make any sense. Fixed function x86 unit? L3 cache guiding instructions? I guess you're trying to say having a CMT-like shared FPU among all the cores.

If the instructions are part of your instruction set, to the extent that the decoders have to at least recognize them as a group, then it makes little sense to not at least microcode them. And SSE instructions probably mostly map directly to the uops needed for AVX anyway, without any further work needed beyond the decoder. x87, even for operations that do map directly to the FPU still, needs support of the register stack (probably as part of the rename unit) to be executed directly. But you could still just microcode that. It'd probably be a lot better than shipping it off to a shared unit that lives far away.

 

[NTMBK]

I can't say agree with this either. Code really should be optimized and even written differently for both platforms, to make effective use of either of them. If you have software that's scaling from a few dozen threads to a few hundred then it's probably not very efficient on one end of the spectrum or the other.

Oh, there would clearly still be plenty of optimization to do. But the initial 'just get the damn thing running' hurdle would be removed entirely.

 

[bronxzv]

x87, MMX, SSE, SSE2-SSE4.2 are all not supported by this new x86-64. While all these instructions have equivilents in XOP to XOP2 and AVX to AVX3.2.

Other than that the only other change is 2-operand/3-operand destructive instructions in the generic cores are gone. Instead, replaced by 3-operand and 4-operand non-destructive. With plans for >5-operand non-destructive improvements.

The codename for this initiative is "Standard 64".

do you have a link to provide for this "initiative", or are you just making things up ?