Linked by Thom Holwerda on Fri 5th Apr 2013 16:04 UTC
General Development "For years, PC programmers used x86 assembly to write performance-critical code. However, 32-bit PCs are being replaced with 64-bit ones, and the underlying assembly code has changed. This white paper is an introduction to x64 assembly. No prior knowledge of x86 code is needed, although it makes the transition easier."
Thread beginning with comment 557789
To read all comments associated with this story, please click here.
Comment by Drumhellar
by Drumhellar on Fri 5th Apr 2013 18:53 UTC
Drumhellar
Member since:
2005-07-12

With each new processor adding a new generation extending the ISA for more capability (On it's own, a good thing), while never dropping support for older features (On it's own, a good thing), x86 is a horrible mess.

I mean apart from changing the names of registers as they went from 16- to 32- to 64-bit (Which is cool), between Intel and AMD there's x87, MMX, SSE, SSE2, SSE3, SSE4, AVX, 3D-Now! and 3D-Now!+ (unofficial name), XOP, FMA4, and CVT16, all for math. Some registers overlap between extensions and some don't.

Non-math instructions extensions PAE, AMD-V and AMD-Vi, Intel VT and Intel VT-d, VT-c, and EPT.

Note that this may not be an exhaustive list, though listing them was exhausting.

Also, poo on you, Intel, for using "x64". It's AMD64, and just because decided to do a dick move and purposely make your 64-bit extensions slightly incompatible in a few corner cases so you could call it something other than AMD64 doesn't mean you have a different 64-bit implementation. No. All it means is that you have a broken AMD64 implementation.

Reply Score: 6

RE: Comment by Drumhellar
by Neolander on Fri 5th Apr 2013 19:41 in reply to "Comment by Drumhellar"
Neolander Member since:
2010-03-08

Well, I'd say that the fix for x86 extension proliferation is easy: find that forgotten corner of the AMD64 spec where it states that the architecture mandates the presence of SSE2, NX and CPUID extensions among a few other things, then leave the rest to compilers, unless you really need a feature (like VT) or have to get the most out of a specific range of hardware for some reason.

I don't think it's a very good idea to rely on hardware-specific features which are not guaranteed to be present on future processor generations, even if it is the case in practice for now. Just look at how little of these x86 extensions Atom processors support: tomorrow, these little chips will likely be good enough for the average Joe's computing needs...

Edited 2013-04-05 19:41 UTC

Reply Parent Score: 2

RE[2]: Comment by Drumhellar
by moondevil on Fri 5th Apr 2013 19:46 in reply to "RE: Comment by Drumhellar"
moondevil Member since:
2005-07-08

This is one of the reasons why it is so hard to use Assembly nowadays by comparison with the old 8 and 16 bit CPUs.

Not only are the CPU doing lots of manipulations with your code as if they were compilers, the amount of instruction sets to remember is just too big.

Reply Parent Score: 3

RE[2]: Comment by Drumhellar
by Drumhellar on Fri 5th Apr 2013 21:09 in reply to "RE: Comment by Drumhellar"
Drumhellar Member since:
2005-07-12

Well, Atom has this problem as well. All Atoms support up to SSE3, some have support for SSSE3 (An extension to SSE3), and the newest support Intel VT-x.

Obviously, they don't support the AMD extensions (3D Now!, XOP, FMA4, and CVT16)

All this stuff adds complexity to the front end (One of the main targets for reducing power consumption for the Atom), but at least the back-end stages doesn't get significantly more complex.

Reply Parent Score: 3