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.

You would probably have to cut down the rainforest for the first half, wait until it grows back, then cut it down again.

Itanium is shit.

The OOXML standard has over 6000 pages. Microsoft and Intel both design horrible interfaces filled with backwards compatibility kludes but as Ballmer told Otellini: "mine's bigger."

>>3
Itanium and x86 are both shit.
FTFY

>>1
Only $180. Not bad.

http://www.lulu.com/spotlight/IntelSDM

>>1
I'm still waiting for them to document their memory chipset init sequence.

Your move, Cudder.

It's not uncommon to have tens of thousands of pages of documentation for really large, really old crap. Especially if you are doing something dangerous like running the security systems that keep the Roswell UFO from returning to the mothership or something.

>>7
Believe me, it's documented.

http://img197.imageshack.us/img197/3439/bwg.png

Whether you have access to it is a different issue. ;)

>>9
Do you have to be fully Jewish to get access, or being circumcised is enough?

By the way, wtf with Wikipedia saying that "nehalem" refers to some indian tribe or something and censoring all mentions of the Hebrew meaning of the word?

>>9
Nehalem
Fucking Shalololololom, KIKE KIKE KIKE.
>>10
You have to be fully jewish and participated in at least 5 kidnap-rape-murders of European goy girls ages 5 and unger. With video documentation of each of course.

>>10
You just have to contact your nearest Intel sales representative.

>>9
And that is why Intel's market penetration outside PCs is terrible. Anybody can write firmware for ARM, but to get into the Intel game you need to either pay an IBV for every unit shipped or be a high tiered customer and get an RSNDA for every employee and their dog.

>>13
Or you could just pay a coreboot neckbeard 10000$ to reverse engineer an existing BIOS.

>>14
If the neckbeards could, they would have already. There's a reason why the only Intel chipsets with support from the coreboot "community" are ancient.

>>13
http://www.intel.com/content/www/us/en/intelligent-systems/intel-boot-loader-development-kit/sandy-bridge-family-bwg.html

You're welcome. Just don't ask. :)

>>16
My fuck, just enabling cache-as-RAM is a 17 step process. Never change, Intel.

>>17
Some of those steps are just "make sure X" which doesn't count as real code.

And the processor has 3 levels of caches each separately configurable, what did you expect?

Marry me, Cudder!

>>15
What reason would that be? My guess is that the coreboot community have chosen to invest their time on other chipsets. I bet there're plenty of EE gradutates who would accept thousands for the job of reversing newer chipsets and porting coreboot to them..

>>13
Nobody would use the x86 instruction set if it wasn't for PCs either. Intel spends time and money on 16-bit modes that address less than a thousandth of the RAM and ``conventional'' memory holes to mimic a 70's CPU in case someone wants to run DOS at 3 GHz, not to mention the instructions and segmentation mechanisms that nobody ever uses.

>>19
cudder is a jew

>>22
that's why i love jews

>>23
Shalom!

>>21
Backwards compatibility is very important, and is one of the main reasons to choose x86. The older addressing modes are well known and no more "time and money" needs to be spent on them anyway, since they essentially copy+paste much of the design from the previous generation for their base.

They're probably still mad at AMD for making a horrible mess of what they wanted the 64-bit mode to look like. There are so many empty spaces in the opcode map that could've been used for 64-bit extension prefices, and segment descriptors have additional empty bits that could've easily accommodated 16, 32, and 64-bit coexistence, letting you use 64-bit operations in real mode just like it was possible with 32-bit, but they decided to overwrite an entire row of register inc/decs and introduce entirely incompatible operation modes.

But pissing off Intel by trying to make them start over with the architecture was probably a bad idea. And they had to put back some of the stuff they stupidly "left out" but was always there, since the circuitry is still present on die!

>>25
Intel didn't want 64-bit x86 to look like anything. You know you're in trouble with an ISA when even the company that created it doesn't want to deal with it anymore.

הקונבולוציה שהיא x86 היא למעשה שום פיתול, אבל עליונות. בחייך, אתה יודע שאתה כמו מצב של 16-bit מפולח פונה. אתם כמהים לאותם ימים.

>>25
Backwards compatibility is very important, and is one of the main reasons to choose x86.
Yeah. That is the reason for their filthy Jewish monopoly. Fuck, I hate Jews so much: first they did Christfaggotry, nuclear bomb, now x86. Every single evil thing comes Jews.

>>26
They still have the ugly one-operand divide instruction that can't take immediates, the parity bit which is hardly ever used because it's untestable by portable languages, the stack-based x87 that makes things harder for compilers, a Z80-compatible flags register, no absolute CALL, booting in real mode (which has less address space than the cache of some new CPUs), and all of those other warts in the instruction set.

>>28
Buy le nmote.

>>30
I would when they make a laptop with Loongson 3.

>>31
They did, and it has a AMD binary blob.

>>29
If you're using a lot of integer division, you're doing it wrong. You can compute parity & popcount using the traditional BSR and BSF instructions (most C/C++ compilers provide intrinsics for these) or the new POPCNT and LZCNT instructions on SSE 4.2 enabled CPUs. x87 is deprecated. Everyone uses SSE/AVX on x86/x86-64 these days. The MSVC, ICC, GCC, Clang etc. don't even touch the x87 opcodes when generating code for x86-64, unless you explicitly force it too. GCC only generates x87 for long double, other compilers have sizeof(long double) == sizeof(double). The ISA is largely divorced from the actual microcode execution engine which is very RISC like. The other stuff is just pedantic crap that only faggots like you care about.

>>26
I'm pretty sure Intel were designing 64-bit x86, AMD just got to the market first.

They still have the ugly one-operand divide instruction that can't take immediates
As if MIPS' completely separate result registers and arcane timing requirements are any better? And ARM didn't even have a divide instruction until very recently...

parity bit which is hardly ever used because it's untestable by portable languages
So what? If the language doesn't let you use the full functionality of the CPU then it's the language's fault.

stack-based x87 that makes things harder for compilers
Again, it's the compiler writers that need to get smarter. And if anything, stack-based ISAs are far easier to generate code for than register-based.

a Z80-compatible flags register
So what?

no absolute CALL
Because relative calls have advantages over absolutes and can't be easily simulated by absolutes (relocation etc.), but the opposite is not true.

booting in real mode
So what? You get backwards compatibility for free, and can switch into protected mode if needed; it's only 4 instructions or so, and you get to decide what the GDT should be. Intel did try making a CPU that booted in protected mode, the 80376, and it failed miserably: you still needed to setup the protected mode stuff, and lost the ability to run existing code, so there was absolutely no advantage.

which has less address space than the cache of some new CPUs
Ever tried DOS benchmarks on a late-model i7? No L3 cache misses at all, so it's bloody fast. Fun.

parity [...] BSR and BSF
You don't know what parity is, do you? POPCNT is halfway there, but you need a few more instructions. (Aside: When I last tried, common compilers still don't know how to use the sign flag correctly; try if((a + b) < 0), the expected result should be add followed by js/jns).

Everyone uses SSE/AVX
No, they shouldn't be except for the special purposes those instructions were designed for, i.e. applications that require lots of parallel operations on data. Video and image processing, mostly.

microcode execution engine which is very RISC like
It's not. This is marketing myth.

Cudder-san is so smart and makes my panties wet.

>>35
she's hot

>>34
As if MIPS' completely separate result registers and arcane timing requirements are any better? And ARM didn't even have a divide instruction until very recently...
Neither did the Z80, which is why x86's divide is such a kludge. They kept the ugly divide which almost always needs a stack operation or register spill because of its unusual requirements. With register renaming there is no special accumulator, but people have to pretend it exists and make unnecessary memory writes.
So what? If the language doesn't let you use the full functionality of the CPU then it's the language's fault.
It's computed with every single arithmetic instruction just to be thrown away. Why not add things to the CPU to help with languages instead of the other way around?
Again, it's the compiler writers that need to get smarter. And if anything, stack-based ISAs are far easier to generate code for than register-based.
Automatic stacks are easier, not a fixed 8-item stack with manual management. Look at source for GCC, the JVM, or any other portable compiler. They have to add kludges for x87 compared to all other supported targets.
So what?
Partial flags register updates, ADD and INC are different, SUB and DEC are different, and all of those other quirks, just because that's how the 8008/8080/Z80 did it. You get compilers that do add eax, 1 instead of inc eax to avoid a partial flags stall.
So what? You get backwards compatibility for free, and can switch into protected mode if needed; it's only 4 instructions or so, and you get to decide what the GDT should be. Intel did try making a CPU that booted in protected mode, the 80376, and it failed miserably: you still needed to setup the protected mode stuff, and lost the ability to run existing code, so there was absolutely no advantage.
Intel/AMD dropped most of segmentation to phase out the "legacy" modes. If it still boots in real mode, they'll have to keep that stuff forever.
Ever tried DOS benchmarks on a late-model i7? No L3 cache misses at all, so it's bloody fast. Fun.
It's fast, but you're only using 1/1000 of your RAM and have no hardware support (floppy disk and ISA cards are gone).

>>37
Don't try to seduce Cudder with your CPU bullshit, i saw her first.

BUT THE TPM USES ISA
ISA WAS JUST RENAMED LPC
ISA WILL NEVER DIE
YOU CAN TAKE MY CMOS FROM MY COLD DEAD HANDS
AS WELL AS MY NMI DISABLE PORT
FUCKER

______   _______ _________    _____   _______  _______  ______ 
(  __  \ (  ___  )\__   __/   / ___ \ / ___   )(  ____ \/ ___  \
| (  \  )| (   ) |   ) (     ( (___) )\/   )  || (    \/\/   )  )
| |   ) || (___) |   | |      \     /     /   )| (____      /  /
| |   | ||  ___  |   | |      / ___ \   _/   / (_____ \    /  / 
| |   ) || (   ) |   | |     ( (   ) ) /   _/        ) )  /  /  
| (__/  )| )   ( |   | |     ( (___) )(   (__/\/\____) ) /  /   
(______/ |/     \|   )_(      \_____/ \_______/\______/  \_/