World's Thickest Book

Intel should publish all of their documentation, including

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html
and
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

in one book.

As in ELEPHANT DICK LARGE.
As in less than 10% of the total size? So if they threw out say half of the instruction set (being extremely generous here), the chip will be 5% cheaper and more energy efficient?

It's only gotten worse with additional shit added on since then.
I thought your problem was not with new useful shit but with useless legacy shit, the proportion of which decreased as more shit was added?

Also, original P5 had 3 million transistors, Sandy Bridge has about 250 millions per core, what does that say about the proportion of transistors wasted on legacy shit and the possibility for improvement by cutting it off?

I'm getting a feeling that you're a humanities major and a goy, to be honest. Your inability to intuitively grasp basic mathematical properties of the situation and the implications for possible efficiency and profit gains is hard to explain otherwise.

>>81
Profit yes, efficiency no.

>>73
If hitting the stack frame was really so fast, all Intel's optimization guides wouldn't pointedly tell you to avoid it.

>>80,81
The power penalty to run that decoder is no more than 5% these days. Area cost is even smaller, and will continue to shrink.

Modern Intel CPUs will burn through a task and return to sleep faster than a similar ARM will, so the overall impact of the decoder is really, really insignificant. Intel knows its hardware to the exclusion of all else so they can easily justify keeping it this way.

Intel's real problems with low power are more diverse than the instruction set. For the longest time, they simply didn't want to compete in the market because the margins there are too low for them to sustain themselves. You don't get to keep running big expensive cutting-edge fab by selling cheap chips for mobile and embedded devices. Sour grapes, really.

Now Intel has no choice but to admit that ARM is cannibalizing their market from below, but they just don't have the expertise needed to integrate devices that anyone will buy. Their ODM partners are clueless and the market leaders have no interest in reaching out to them. Instead, they keep chasing process leads while all the designs that they need to get their foot in the door are still trending out 12-18 months...

>>79,81
Good to see someone else here with knowledge of how hardware works...

80386 1.5um process die. 275,000 transistors in 104mm². Density of approximately 2.6K transistors/mm².

8-core Xeon E5 (Sandy Bridge) 32nm process die. 2,270,000,000 transistors in 434mm². Density of approximately 5.23M transistors/mm².

The amount of chip area needed for an entire 386 in the 32nm process would be 0.05mm², or about 0.23mm on a side. The Xeon E5 die is around 21mm on a side. That's an entire working 386, complete with all the "legacy" instructions and everything, and it takes only 0.01% of the die space in a modern processor, or around the same size as 4 bond pads.

Here's a picture to put things into perspective:
http://img89.imageshack.us/img89/3897/compareqvu.jpg

That tiny square, a miniscule bit compared to the entire die which looks enormous in comparison; until you realise the die itself is only ~21mm square.

Would they remove that just for the sake of academic "elegance", at the HUGE cost of losing backwards compatibility?

Now Intel has no choice but to admit that ARM is cannibalizing their market from below
Intel actually has an ARM license. They don't intend to use it.

Medfield looks pretty good for a first try. Intel never cared much about low power, they were after performance first. But now that they're trying, it'll be interesting to see what happens. Having an entire PC-compatible smartphone would be awesome. ARM is only compatible at the ISA level, everything else is different (and difficult to find info on) between the SoCs.

Stop! Cudder time!

>>81, this is 80.
I believe I have learned something here, and was really just being silly.  I do apologize.

Cudder-sama, are you an electrical/electronic engineer? why do you know so much about hardware? ;_;

>>87
Ever heard of those scary viruses and malwares made by evil russians? Well, that's Cudder.

>>88
ヽ(#`Д´)ﾉ

>>86
If you learned the real lesson there, which is that jews are the most racist people at any given time, then you wouldn't be apologizing.

　┏━┓
━━━━━━
ﾐΘc_Θ-ﾐ

>>84
Intel actually has an ARM license. They don't intend to use it.

That license is also old - they might have to shell out more money to get access to the newer stuff. Intel has plenty of money for that, of course, if they want it.

Medfield looks pretty good for a first try. Intel never cared much about low power, they were after performance first. But now that they're trying, it'll be interesting to see what happens. Having an entire PC-compatible smartphone would be awesome.

The Windows 8 boondoggle makes it pretty clear that the consumer mass market couldn't care less about Intel's cherished PC compatibility (and Medfield isn't PC compatible, anyway). The commercial embedded market, where such things have more weight, is already deeply distrustful of Intel and won't chase their offerings unless and until they demonstrate a clear price advantage. The continued investment in fab instead of buying their way back into the LTE market demonstrates to me that Intel would rather die than live on the ARM vendors' margins.

>>87
I usually do the opposite of engineering...

>>92
Medfield isn't PC compatible, anyway
Not fully (obviously it's going to lack things like an 8042 because the smartphone doesn't even have a keyboard, and other devices where the associated peripheral isn't present, and the BIOS is similarly cut down --- although AFAIK it still boots in realmode), but it's compatible enough for e.g. standard Windows EXEs to run in userspace.

and won't chase their offerings unless and until they demonstrate a clear price advantage
Intel is not trying to compete in the value segment; they're aiming for performance, which is what x86 has always been good at. Just as most of the low-end market is dominated by AMD, Intel wants to take the high end and leave the low end to ARM, MIPS, and the rest.

>>93
The shortsightedness in this is that, if Intel keeps doing what they're doing, the whole consumer market will end up inside that segment. Funnily enough the company that helped create the ``killer micros'' keeps looking more and more like DEC did in its final days.

>>93
performance, which is what x86 has always been good at.
wat.

>>93
performance, which is what x86 has always been good at.
RISCs were much faster than x86 until Intel and AMD implemented micro-ops. ALPHA still beat x86 until the day it died.

cudder = intel kike

>>95,96
While not an Intel faggot: [citation needed]
SPEC benchmarks recommended.

>>97
i'm in love with her, even if she's a kike

>>99
"Her"...? Cudder is at least 6 different people, most (but importantly not all) of them girls.

>>100
^{[citation needed]}

>>100
And all 6 are Jewish.

>>101
Cudder is a shared pseudonym used by Israeli Jews for pro-Intel astroturfing.
*puts on tinfoil hat*

>>100-103
Cudder is probably one person. I can't believe that many BIOS developers ride the /prog/; it's just uncharacteristic.

Pretty interesting, >>104

>>100
"girls"
cough

Pretty interesting, >>106

>>95,96
I'm saying x86 has a lot of performance potential. They might not've been fast before but they can certainly take advantage of it going forward.

>>98
http://www.spec.org/cgi-bin/osgresults?conf=cpu2006;op=dump;format=csvdump
CINT2006rate:
POWER POWER7@4.0GHz, 1024 threads (256 cores * 4 threads/core) => 11300 -> 11.035 result/thread, 2.76 result/thread/GHz
X86 Xeon X7542@2.67GHz, 384 threads (384 cores * 1 thread/core) => 8190 -> 21.328 result/thread, 8.018 result/thread/GHz
ITANIUM Itanium2-9040@1.6GHz, 256 threads (256 cors * 1 threads/core) => 3520 -> 13.75 result/thread, 8.594 result/thread/GHz
SPARC64 Sparc64 VII+@3.0GHz, 512 threads (256 cores * 2 threads/core) => 3150 -> 6.152 result/thread, 2.051 result/thread/GHz
And just for the lulz...
X86 Celeron G550@2.6GHz, 2 threads (2 cores * 1 threads/core) => 58.5 -> 29.25 result/thread, 11.25 result/thread/GHz

So we see x86 and Itanium beating the shit out of POWER and SPARC.

CFP2006rate:
POWER POWER7@4.0GHz, 1024 threads (256 cores * 4 threads/core) => 10500 -> 10.25 result/thread, 2.56 result/thread/GHz
X86 Xeon X7542@2.67GHz, 384 threads (384 cores * 1 thread/core) => 6600 -> 17.19 result/thread, 6.44 result/thread/GHz
ITANIUM Itanium2-9040@1.6GHz, 256 threads (256 cors * 1 threads/core) => 3510 -> 13.71 result/thread, 8.569 result/thread/GHz
SPARC64 Sparc64 VII+@3.0GHz, 512 threads (256 cores * 2 threads/core) => 2550 -> 4.98 result/thread, 1.66 result/thread/GHz
And again, the low-end x86...
X86 Celeron G550@2.6GHz, 2 threads (2 cores * 1 threads/core) => 57.2 -> 28.6 result/thread, 11.0 result/thread/GHz

Total x86 domination.

No MIPSes, Alphas, nor ARMs found in the results, so can't compare there. Maybe back in the early 90s RISC would've enabled higher clockspeeds since that was how they played the performance tradeoff, but post-Netburst we all know that other things come into play and you can't raise the clockspeed infinitely high no matter how "simple" you make the design.

Cudder is by far the worst shitposter.

>>109
Back to /jp/ with you.

>>109
He really is and it's amazing that he can beat even me at it, guess the jews really are better at everything.

>>111
He? Cudder is not Derpina?

>>112
Cudder's a tranny bro. Your derpina has a derpenis.

I'm just wondering: have you guys ever craved cock so badly that you found yourself running around outside, howling at the moon for it? Literally ROARING at the top of your lungs, wanting nothing less than a dick's head churning against your glottal stop?

Tell me I'm not alone.

No, I mena, Cudder is one of many [female] pseudonyms for a guy, not that many people are posting under that one pseudonym.

>>108
Thanks for proving my point. Although those are from 2006.

I am still waiting on >>74,75,95,96 to show me proof otherwise.

>>116
Although those are from 2006
CPU2006 is the newest version. Those results are not from 2006.