7 ms·
Well, and for 25-30 years, everyone’s been crowing about how they were doomed to fail because of x86 as a CISC design. Intel killed off most RISC competitors as
by jonstewart 7y ago
Well, and for 25-30 years, everyone’s been crowing about how they were doomed to fail because of x86 as a CISC design. Intel killed off most RISC competitors as Moore’s Law held in the 90 and they could just add more transistors to turn x86 into a facade. But that increase in transistors and doing whatever possible to keep x86 performant meant they were doomed to lose the power/performance war that came with mobile processors. ARM held on just long enough in the low margin embedded world to then conquer mobile. Intel was able to win price/performance through superior fabrication and economies of scale, but power/performance really does require a superior design.
If Intel recovers, it may need to jettison x86, or offload x86 interpretation to a secondary unit for desktop processor with it gone from server procs.
This would make me happy because it’s been crushing to think I might go my entire career/lifetime with little endian processors being the mainstream. :-/
- dman 7y agoThis space will be interesting to watch! We live in extremely interesting times hardware wise.
- atq2119 7y agoLittle endian has nothing to do with CISC vs RISC or x86 though. Everybody is little endian today. x86 helped with that historically, certainly, but fundamentally endianness just doesn't matter most of the time, and when it does, little endian makes more sense from first principles.
- api 7y agoIf anyone wants to see why little endian is better try implementing a sigint. Big endian makes everything backwards in terms of iteration order.
- takeda 7y agoYou are presenting argument in favor of little endian, yet you're provide enough information that is only useful for someone who already knows the answer.
- tedunangst 7y agoThe answer is also only useful to those who know it? I mean, nerds love to shout about the superiority of this or that, but they're mostly just parroting their tribe motto. If you have reason to really care about endian order, I would encourage you to do more research than you'll find in an HN comment. Perhaps there's even more than one right answer depending on circumstance.
- takeda 7y agoI don't have too much knowledge in that area, but my understanding is as follows: for a software engineer big endian simpler to use, for hardware engineer little endian is simpler to implement. I think it's similar to scientific calculator vs RPN calculator.
- atq2119 7y agoI don't think big vs little endian makes a difference in terms of hardware implementation. It's just a simple swap of wires.
- takeda 7y agoit's more optimal when you're doing pipelining, for example adding two numbers to do the operation you start from the lowest byte and add them together and move up. With little endian bytes are already positioned in the order you want. x86 architecture also was big on backward compatibility. You have registers that can be accessed as 8bit, 16bit, 32bit (and I believe 64bit) adding the extra bytes after similarly makes it easier, because the little significant bits are always in the same place. Again, I don't have extensive understanding of hardware side, so I might be wrong.
- xxpor 7y agoExcept MIPS and the network.
- wmf 7y agoMIPS processors have mostly been replaced by ARM already.
- amluto 7y agoI think big endian is better: with little endian, treating a pointer to one size integer as a pointer to a different size integer has a decent chance of working, which allows bugs and sloppiness to fester. With big endian, screwing up your pointer type is very unlikely to work, which is IMO a good thing.
- jonstewart 7y agoI know endianness is separate from CISC vs RISC, and mostly a pointless and useless debate.
- Reelin 7y ago> Everybody is little endian today. ACKCHYUALLY, PowerPC (POWER9 included) supports both big and little endian. Software wise, last I checked the Linux kernel, Debian (PPC port), Gentoo, FreeBSD, and several other major projects supported both. I believe KVM also supports flipping VM endianness versus the hypervisor. Acknowledged, of course, that the spirit of what you said is indeed correct - the majority of systems in active use are little endian.
- my123 7y agoARM too. https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads https://developer.arm.com/tools-and-software/open-source-sof... See: > AArch64 GNU/Linux big-endian target (aarch64_be-linux-gnu)
- ksec 7y ago>and when it does, little endian makes more sense from first principles Could you explain why little endian would make more sense? While I dont take side in this debate, I have always thought Big Endian would make more sense from First principles.
- atq2119 7y agoThere are two main applications where I find little endian is more logical: big integer implementations, and bit stream encoding. With big integers, the logic is simple: if you use little endian, you can operate on the same memory representation of the bigints quite easily with machine integers of different sizes. A similar phenomenon happens with bit encoding. Let's say you want to encode a sequence of 25-bit integers tightly packed in memory. How do you do that? With little endian, you get a somewhat more natural representation especially for seeking into the bitstream (especially for architectures that allow unaligned memory accesses).
- BeeOnRope 7y ago> With big integers, the logic is simple: if you use little endian, you can operate on the same memory representation of the bigints quite easily with machine integers of different sizes. That's true with big endian too, but you just have to store your integers in the opposite way as you would on little endian: with the MSB at the lowest address (which of course is the same as the distinction between little and big endian in the first place). Basically the bigint layout has to be compatible with the the endianess. I don't know what bignum implementations do in practice on big endian systems though.
- dogma1138 7y agoAll modern x86 CPUs are essentially “RISC” CPUs that translate x86 instructions into uOPS so they already do what you want to do. I’m not seeing why the higher level x86 instruction set needs to be jettisoned or killed off...
- pepemon 7y ago> All modern x86 CPUs are essentially “RISC” CPUs Where can I read more about that?
- grantisu 7y agoIf you can work around the formatting issues, there's some classic articles on Ars Technica, e.g. http://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html http://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
- pjscott 7y agoAnd ARM processors these days tend to do the same, translating from the Thumb-2 variable-width instruction encoding into whatever each processor uses internally.
- floatboth 7y agoThumb-2 is for microcontrollers (and not all of them even). Anything unix-capable (Cortex-A series and custom cores) reads fixed width AArch64 instructions.
- goosehonk 7y agoARM has never enjoyed a Op/J advantage over x86. They have low-power designs, yes, but they don’t do more work for a given amount of energy. x86 won fair and square. The risc people failed to foresee that instruction density would be extremely important to performance. Intel didn’t beat them with physics. CISC is just fundamentally better.
- spamizbad 7y agoThe writing was on the wall in the early 90s. The SuperH ISA basically gave you the best of both world's: Fixed-width, relatively easy to decode instructions that were 16-bit, rather than 32 bits of many RISC ISAs.
- etaioinshrdlu 7y agoI had assumed the opposite, that ARM was better in terms of Op/J. Can you provide a reference to make it certain? Also, I wonder if the low density of RISC could be countered by introducing execution of compressed/zipped machine code. Some compressors like brotli are highly tuned to the expected type of data to be compressed and are very compact. All entry points to basic blocks in the code are generally known at compile time, so it can be ensured that the jump destinations are decompressible without any context, avoiding the slow process of needing to scan backwards to start decompressing...
- kevin_thibedeau 7y agoArm Thumb is a compressed ISA. Intel has been decompressing x86 instructions into an internal RISC machine since the Pentium Pro. The benefit is getting more instructions through the chokepoint from DRAM to L1 cache.
- StillBored 7y ago<i>ARM has never enjoyed a Op/J advantage over x86.</i> I'm not sure that exactly accurate, its more accurate to say, that there was a lack of market crossover that allowed similar power or perf envelopes. That is because ARM did/does make much more efficient CPU's, they just aren't anywhere close to the perf of common x86 cores. AKA a low clocked in order ARM with small caches, etc is more efficient per op but it can't touch even a medium size x86. Intel sort of was in that market for a bit and their cores were efficient too, but the main selling point for an architecture is the software around it, and a 50 mhz in-order x86 can't exactly run modern windows in a reasonable way. Now that ARM & friends are building higher perf parts, the power efficiency keeps getting worse. When someone makes a 5Ghz ARM core it will likely consume more than a couple mW. The perf/power ratios have more to do with culture and market than ISA.
- scarface74 7y agoIntel “won” because they had the money to invest in processors from owning the PC market. Now, Apple ships more ARM devices by itself than all personal computer sells combined (not counting the servers - it’s hard to find numbers on servers). Apple by itself can afford to pour money into ARM designs. Now we see that Amazon makes enough money and has enough volume to invest in server processors.