+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: Off-Topic (https://forum.openredstone.org/forum-4.html)
+--- Forum: General computing and engineering (https://forum.openredstone.org/forum-66.html)
+--- Thread: Reasons x86 is bad. (/thread-4186.html)
Reasons x86 is bad. - Cutlassw30 - 07-28-2014
X86 IS NOT BAD BECAUSE X86 IS CISC. X86 IS BAD BECAUSE ITS X86
After a recent argument It seems that many people have no clue as to why x86 is a shitty architecture and blame it on it being CISC. The CISC features of x86 however is not what makes it bad but its all in the memory management. You see even back in the 16 bit i8086 days (original x86) and to the 64 bit super scalar out of order gigahertz beasts of today x86 has always had terrible memory accessing schemes. I will first start off with the 8086 (no virtual memory aka "real mode"):
On the 8086 or on modern x86 processors in real mode accessing memory is a pain in the ass. Why is that? well because of all the bullshit that needs to happen for it. You see real mode x86 has 13 registers in 16 bit mode, these are: AX, BX, CX, DX, SI, DI, BP, SP, CS, DS, ES, SS, IP, FL
AX, BX, CX, DX, SI, and DI: Are for sake of argument general purpose registers (They all have special uses but are used generally in programs)
BP and SP: Are for manipulating the stack
IP: Is the instruction pointer (or program counter)
FL: Is the flags register which holds what state the processor is currently in.
CS, DS, ES, SS: Are 20 bit segment registers... yes thats right 20 bit registers on a 16 bit CPU. These are used in, you guessed it memory access. CS stands for code segment, DS stands for data segment, ES stands for extra segment, SS stands for stack segment. When you are loading an instruction the code segment is used, when you are using data from RAM data,extra,and stack segments can be used. So what do these do? well for example in the instruction:
ADD AX,[BX+12]
On a normal processor this would take the value of BX add 12 to it and access memory at that location (BX+12) and then use that to add with AX. This is how most processors of that time worked (and thats what separates RISC processors from CISC is that RISC works off internal registers and CISC can do operations directly on main memory aka RAM).
But in x86 they thought they where all fancy and the instruction:
ADD AX,[BX+12]
Actually means
ADD AX,[DS<<4+(BX+12)]
Thats right in x86 you first add BX+12 then add that to the data segment shifted left 4 times to get your memory address then do the final addition. Not only is it a pain in the ass to program but it also takes 4 different operations just to add two numbers together! You have to:
ADD BX+12
SHIFT DS<<4
ADD result of DS<<4 + result of BX+12
ADD the two numbers the programmer wanted to.
As you can see this is really fucking slow and frankly a pain to program. The reason x86 did this was to allow 1 megabyte of RAM instead of 64k which really wasn't worth it because to access that upper 640k of RAM you had to use some werid shifted 20 bit register which made it a bitch to program.
But wait there's more! Some overpaid engineer had the bright idea to figure out that sometimes the 3rd add would have a carry out. And guess what they made it so that the carry out could be used as another address line getting around 2 megs of RAM that was even harder to access! Now an entire 1 meg of RAM would only be used during a COUT of the 3rd addition, great.
But wait even more! Guess where they decided to put the AND gate to enable this "feature". Nope not in the CPU, Not in the RAM controller, THEY PUT IT IN THE FUCKING KEYBOARD CONTROLLER. Yes to access more RAM you must interact with the PC keyboard PS/2 controller first. No lie this is called the "A20 gate" which is a reference to the AND gate on address 20 line.
http://en.wikipedia.org/wiki/A20_line
"It was originally a hack put on the IBM PC keyboard controller"
*FACEDESK*This my dear is why x86 "real mode" is a big lump of shit.
Why is x86-64 a lump of shit? Well to access memory with the virtual memory scheme (which implements segmentation bounds and 2 level paging) can best be summed up with this diagram. Each of the tables is a place in RAM that must be accessed before the data from RAM can be accessed (Note this is outside of the instruction!)
So for example:
ADD AX,[BX+12]
The operations we must do are:
ADD BX+12
Load this shit from RAM using the above addition as the "logical address":
![[Image: rfwkofy.png]](http://i.imgur.com/rfwkofy.png)
ADD the two numbers
/thread
RE: Reasons x86 is bad. - greatgamer34 - 07-28-2014
this is hilarious and full of knowledge, i suggest you edit Wikipedia with this thread.
RE: Reasons x86 is bad. - AFtExploision - 07-28-2014
You told me that x86 was pretty good for the time when I asked you about it ;_;
RE: Reasons x86 is bad. - jxu - 07-28-2014
Great stop trying to destroy humanity's knowledge
most of cut's post tl;dr: x86 has funny addressing
I'd like to add that CISC is not an issue because the instructions are translated into RISC-like ones anyway
want to point out that in the late 70s having 1 MB of ram was pretty good
x64 did solve some weird addressing issues but not all of them
cut's post focuses on specific examples rather than general issues: it's old, it has to be backwards compatible, it has small number of registers (fixed by x64), variable length opcodes
but if you think about it these issues don't really matter to most people, because x86 is dominant in the pc market, performance is fine, and will stay that way in the forseeable future
RE: Reasons x86 is bad. - Cutlassw30 - 07-29-2014
(07-28-2014, 07:17 PM)͝ ͟ ͜ Wrote: Great stop trying to destroy humanity's knowledge
most of cut's post tl;dr: x86 has funny addressing
I'd like to add that CISC is not an issue because the instructions are translated into RISC-like ones anyway
want to point out that in the late 70s having 1 MB of ram was pretty good
x64 did solve some weird addressing issues but not all of them
cut's post focuses on specific examples rather than general issues: it's old, it has to be backwards compatible, it has small number of registers (fixed by x64), variable length opcodes
but if you think about it these issues don't really matter to most people, because x86 is dominant in the pc market, performance is fine, and will stay that way in the forseeable future
1mb of RAM is really good yeah true, too bad 640k of it you have to use some weird segments that where a pain to program and never fully used. Also x64 made the issues worse (look at last part of post) with the segmented and paged virtual memory. Look at the picture it shows the complexity of the system.
CISC is an issue because that translation process takes up space in hardware which could have otherwise been used as cache or function units or generally more important stuff.
(07-28-2014, 07:08 PM)AFtExploision Wrote: You told me that x86 was pretty good for the time when I asked you about it ;_;
I said that x86 is good because intel has the money to throw at issues.
RE: Reasons x86 is bad. - redstonewarrior - 07-29-2014
#segmentedAddressing4evah
RE: Reasons x86 is bad. - Cutlassw30 - 07-29-2014
(07-29-2014, 01:27 AM)redstonewarrior Wrote: #segmentedAddressing4evah
Burn in the pits of hell
RE: Reasons x86 is bad. - tyler569 - 07-29-2014
Am I misunderstanding or is there a better way to ensure memory access security without segmentation?
RE: Reasons x86 is bad. - Cutlassw30 - 07-29-2014
(07-29-2014, 01:49 AM)tyler569 Wrote: Am I misunderstanding or is there a better way to ensure memory access security without segmentation?
Most RISC processors (such as ARM) use only multi level paging instead of paging and segmentation. Segmentation doesn't provide any more protection (and infact its arguable less protectable due to segments being bigger than pages). The way x86 does it there needs to be 4 look ups to main memory to access one piece of data. This is because it needs to:
1: Use upper bits of virtual address to look up global/local descriptor table.
2: Add base to lower bits of virtual address and the data from the descriptor table to look up a linear address table with protection bits checked and bounds checking
3: Use the upper bits of that linear address table to look up a page directory (first page table)
4: Use the data from that page directory added to the middle bits of the linear address table data to look up a page table (second page table)
5: Use the data from that page table shifted over then added to the lower bits of the linear address table data to get a final real address to RAM.
On the processor this takes 4 loads from memory.
A RISC processor on the other hand would do something along the lines of this(using my CPU as an example):
1: Use upper bits of virtual address to look up a page directory(first page table) which has dynamic size (can be paged to HDD) and has protection bits such as read only, never execute, valid, reference, I/O
2: Use data from that page directory added to the middle bits of the virtual address to look up a page table which also has the same protection bits as above(second page table)
3: Use data from that page table as upper bits in the real address and the lower bits of the virtual address are the lower bits of the real address.
This only takes 2 loads from RAM and yet has about the same size and has better protection mechanisms than x86 because I can mark an entire page table as I/O instead of having to write to each page table entry and mark them as I/O which is slower. Secondly its extremely easy to set up shared pages (know as bidirectional queues or "pipes") to form inter process communication and require less system calls to the kernel which also speeds up the system.
RE: Reasons x86 is bad. - mort96 - 07-29-2014
It's from 2003, so it could be outdated, but Linus seems to disagree.
RE: Reasons x86 is bad. - jxu - 07-29-2014
Wow trying to compare PowerPC and x86
RE: Reasons x86 is bad. - Aerodynamic Brick - 06-28-2017
It may be years later but this post is making a big impact on my design decisions.
RE: Reasons x86 is bad. - Noorquacker - 06-28-2017
My money's on that ARM is eventually going to become supreme one day.
That day is not today.
RE: Reasons x86 is bad. - LambdaPI - 06-29-2017
3 operand machines are the shit.
RE: Reasons x86 is bad. - jxu - 07-05-2017
(06-28-2017, 09:43 PM)Noorquacker Wrote: My money's on that ARM is eventually going to become supreme one day.ARM already dominates the mobile market (95+% share), if that counts.
That day is not today.
(06-29-2017, 03:34 AM)LambdaPI Wrote: 3 operand machines are the shit.I agree. Writing MIPS is so nice because 3 operands and plenty of registers to play with, without the weird x86 register quirks.
RE: Reasons x86 is bad. - Noorquacker - 07-15-2017
(07-05-2017, 06:54 AM)͝ ͟ ͜ Wrote:(06-28-2017, 09:43 PM)Noorquacker Wrote: My money's on that ARM is eventually going to become supreme one day.ARM already dominates the mobile market (95+% share), if that counts.
That day is not today.
(06-29-2017, 03:34 AM)LambdaPI Wrote: 3 operand machines are the shit.I agree. Writing MIPS is so nice because 3 operands and plenty of registers to play with, without the weird x86 register quirks.
ARM does almost own the mobile market, especially since it's mainstream, but I think that in the far future x86 will be slowly phased out in favor of ARM-based desktops. They'll be more complex, for sure, but they'll probably become much more efficient than x86. Who knows, maybe ARM will join with quantum computers.
RE: Reasons x86 is bad. - jxu - 07-31-2017
x86 has been around for almost 40 years. Even Intel tried to kill it (with Itanium which had some interesting ideas) but it refuses to die. I don't think it's going anywhere any time soon.
RE: Reasons x86 is bad. - Nickster258 - 09-07-2017
Thought this was applicable:
[video=youtube]https://youtu.be/KrksBdWcZgQ[/video]
RE: Reasons x86 is bad. - VoltzLive - 09-08-2017
(09-07-2017, 03:20 AM)Nickster258 Wrote: Thought this was applicable:
--snip--
watched this the other day, I fucking love how he finds the length of an instruction with the page bounderies
truely impressive
RE: Reasons x86 is bad. - greatgamer34 - 09-25-2018
just wanna bump because RIP cut