MOAR CORES

    Why do even the newest Intel CPUs *still* boot in 16-bit real mode? Why aren't we booting in, at the very least, 32-bit protected, if not 64-bit long protected mode? The way it is now makes it incredibly hard to write operating systems for x86, because you have to do shit like enabling the fucking A20 line, setting up descriptor tables and switching modes. It's 2011, folks, we shouldn't have to do this kludgy shit anymore.

Hint: on decent CPU architectures, everything works perfectly upon boot.

If you don't like backward compatibility make your own CPU from FPGAs.

>>3
What about ARM? PowerPC? Any non-x86 architecture gets this right. Why not Intel?

>>4
These are insignificant on desktop/laptop market.ARM chipmaker can ignore compatibility and make his ARM different much easier than Intel breaking off the decades of backward compatibility support, without any backlash(no one expects ARM code to be reusable in another decade, since it all phones and mobile appliance designed for planned obsolescence).

>>5
That's not an argument against the x86 kludge being bad though.

>>6
Stop listening to that idiot.

>>6
That kludge enabled older OSes and code to be usable(aka backward compatibility)

>>8
Who cares?

>>9
Intel and AMD

>>10
They matter?

>>11
They made your CPU.

>>1
ONE WORD BACKWARDS COMPATIBILITY MOTHERFUCKER THREAD OVER

ex eighty shits
lifting mah ay twenties

Why aren't we booting in, at the very least, 32-bit protected, if not 64-bit long protected mode?
Because protected mode needs to be fucking set up, retard. It doesn't "Just Work" because you need to create the IDT, GDT, pagetable, etc. first. Real mode does, because there's nothing to set up for it.

>>13
This too.

>>15
But it works fine on every other goddamned architecture. Why not on x80dicks?

>>12
[false assumption] I'm using a non-Apple PowerPC box now. I also have an ARM desktop by the side.

>>16
'cuz noone fucking cares

>>16
http://wiki.osdev.org/ARM_Overview
You still have to setup the MMU and interrupts.

On x86, the hardware vector table holds the addresses of handler routines. On ARM, the hardware vector table holds actual instructions. These instructions must fit into 4 bytes.
lol wtf

>>18
wtf lol

>>16
non-Apple PowerPC box now. I also have an ARM desktop by the side.
An AmigaOne and a BeagleBoard housed in a lego case?

MOAR COAREZ LULZ

>>18
Lots of architectures work like that, eg. 8051 on the low end and MIPS on the high end, just to give two examples. Sometimes it's about simplifying the pipeline and saving transistors, sometimes it's just bullshit ("our interrupt latency is just this many cycles.. but what we don't tell you is that every ISR includes this much additional housekeeping overhead which could have been done faster in hardware"). Sometimes later architecture revisions add vectored interrupts (MIPS again serves as an example), I've never heard of one going the other way.

>>20
ARM
slow ass shit

>>1
Due to unfortunate design decisions involving being able to run MS-DOS 1.0 on newer machines, all x86 OSes need 16-bit programs to switch to 32-bit mode, and then 32-bit programs to switch to 64-bit mode. If Intel switched to 32-bit mode on boot, people couldn't run their OSes, and even worse they couldn't run VisiCalc in MS-DOS 1.0 on bare hardware. Buggy shitware is what Intel and Microsoft do best. Bill Gates kept the VisiCalc leap-year bug in Excel for 20 years and even got it included in the OOXML standard. Think about that for a minute. Microsoft has the audacity to add competitors' bugs to their own software for compatibility purposes, and then codify these bugs in an International Standard.

VisiCalc leap-year bug in [...] the OOXML standard
That was ECMA quality!!!