Submitted by I asked for more of this, and I got it. “There has been much interest in assembly lately (whether the real 6502, or the fictional DCPU-16; I even created my own virtual 8-bit CPU called i808 in 2007), but none of this attention focuses on the architecture that is most popular in today’s computers. If you are reading this on a desktop, laptop, or server then your computer is most likely using x86-64 (or x86). x86-64 is the 64-bit superset of the 32-bit x86 architecture and any modern CPU from AMD or Intel supports it. This document will focus on the most used parts of x86-64.”
The nice thing about x64 is that in that somewhere deep down floating among all the x86 compatibility sewage there is a really nice subset of a good ISA.
I disagree, have you looked at the document?
x86-64 is “less ugly” than x86 (16 registers!) but a good ISA??
Have a look at the MIPS ISA, this is a good ISA, x86 isn’t.
Granted, it’s been many many years since I’ve looked at x86, but this looks really nice compared to back then.
16 general purpose 64-bit registers? Sign me up!
If only I had a reason to use it…
Why settle for less? PPC64 has 32 of them.
Nice that he has chosen the Intel syntax.
Since I used the PC since MS-DOS 3.3 days, the AT&T syntax always makes me wonder what I am looking at.
Oh, those young days spent coding demos in Assembly , naively thinking nothing else would be needed.
Started out with a freeware assembler, then moved to TASM and later on MASM. Eventually it was time to move to Turbo Pascal and use the inline assembler just for the hotspots.
I have quite a few books about PC low level architecture, as on those days that was the only way for me to get information.
My first book was from Peter Norton, “Assembly Language Book for the IBM PC”.
For those planning to learn Assembly, the Zen books from Michael Abrash were great with all the low level hints.
Nowadays the processors have become too complex to be mastered by humans, still I am planning to learn some ARM.
Heh, I was coding all sorts of VGA-tricks and messing around with DOS internals, thinking I was an assembly guru. I did try to make an OS of my own, too, but I was way out of my depth. Then again, I was only 13 at the time and had quite poor access to any programming material.
These days I just don’t use assembly anymore, there’s no need for that on most applications as atleast GCC already produces better code than most people can do by hand.
Edited 2012-08-07 07:04 UTC
With modern processors it is also very hard to write Assembly code by hand that is able to match what compilers can achieve due to architectures with out-of-order execution, branch prediction, multiple cache levels, NUMA.
Plus many of the compiler code generation algorithms which were not possible to use in the old days due to memory restrictions, are nowadays part of most compilers.
Unless you’re writing Assembly for embedded systems, with simpler architectures, there are too many factors for code optimization that a human being is able to track.
“This document will focus on the most used parts of x86-64”, really? All the opcodes in that “document” are standard ones that’ve been around since 8088, the only x86-64 – specific thing about it is the registers the author is using. As such the title is terribly misleading, it’s more like a very low-key introduction to x86 assembly.
I was disappointed, actually, I was expecting the article to demonstrate some real x86-64 – specific things. Note that I am not berating the article itself as it was clear and concise, it’s just that it shouldn’t be called x86-64 assembly when it really isn’t that.
I would agree. This seems to be nothing but a (far too rough) overview.
Having said that, are there good real world examples for x64-64-assembly programming? As in: something one can use as a starting point for writing apps?
And the next question: Apart from learning more about the internals of the CPU, is there a good reason to learn assembly language at all these days if one just wants to develop regular apps/utilities? In my case for Linux/Ubuntu/Gnome…
For regular apps and utilities, probably not. Nowadays, I’d say that Assembly snippets only makes sense for low-level code (like OS kernels and drivers), down and dirty security exploits, and software where one really wants to get the most performance out of hardware at all costs (like video codecs).
As an everyday programming language, it just makes it too hard for developers to organize themselves well.
Edited 2012-08-07 09:06 UTC
Doesn’t sound like something I’d like to dive in. Though I’d find microprocessor programming intriguing, which I did shortly in some school.
I think learning a little Assembly is a good idea. Not because you’re likely to use it, but because it gets you thinking about how the machine works, what it is good at and what takes a long time. Once you’ve coded a few things in Assembly you get a better appreciation for what your (higher level) code is doing. I certainly found learning Assembly got me into a better mindset for writing in other languages, especially C/C++.
Quite often developers, especially high level language developers, will just throw complex or repetitive code at a problem without thinking about how it works, why it will be slow or how it might be improved. Learning Assembly and how it works can help you develop better approaches to your coding elsewhere.
I have learned a bit of assembly programming many years back in a school (for some kind of primitive microprocessor) and kind of liked assembly language. And I’ve owned computers long enough to know a bit about the internals (C64 was my first), so there is probably no good reason to re-learn assembler programming if there’s no real advantage over using regular programming languages.
If you even plan to develop:
– drivers;
– operating systems utilities;
– games;
– compilers (either ahead-of-time or JIT based);
– audio or video codecs;
– develop applications that need to run in embedded systems
– numeric code for statistics like FFT
– optimization of code compreension
Than knowing Assembly is really a must.
If you spend you time developing code in languages with native code generation (C, C++, FreePascal, D, Go), or using V8, compatible JVM or CLR then Assembly is important to understand how the high-level algorithms influences the generated Assembly.
Because you can ask to see the generated Assembly and then compare it with the algorithm.
Knowing Assembly makes it also easy to know how to manipulate JVM bytecode or MSIL, and with it perform low level meta-programming. This is how Aspects work, for example.
Another example is how Qt 5 will make use of SIMD instructions to do perform encoding conversions,
http://woboq.com/blog/utf-8-processing-using-simd.html
While being well-versed in asm can have advantages, saying it’s a must for at least half the things you’ve listed is absolutely untrue.
Please elaborate how it is untrue.
Quite simply the fact that asm isn’t a must. We’ll take the first item on your list as an example — drivers. I invite you to join any of the numerous mailing lists used for Linux driver development. Ask people who actually write drivers if they agree that asm is a must and you will get a resounding no. For that matter, many of the guys writing drivers have zero asm experience. I have a friend who has worked for a handful of major chip makers and the only requirement placed on him, ever, was his willingness to sign NDA’s. He also has no asm experience.
Since you made the claim, perhaps you should explain why you think it is, despite the fact we already know it isn’t.
Well, back on my long gone university days. Every CS student had to do driver projects in multiple operating systems. So I guess I do have some experience with drivers. On those days Linux was still being brewed.
Linux is not the only kernel in town, and not all provide C API abstractions to access the hardware.
There three ways to access hardware:
– Memory mapped I/O
– Processor instructions to talk via I/O ports
– Processor instructions to talk via traps (not so common)
Specific hardware sometimes requires initialization steps not covered by the way the kernel abstracts the above forms of I/O communication.
Sure, it may be that he never needed, but if he is writing drivers, for sure he will eventually need to get either touch Assembly or have someone else do it.
Linux kernel version 3.4.7 driver tree has
– 8 Assembly files;
– 58 C files making use of inline Assembly;
If you care, I can also list use cases for every single point I’ve listed on my previous comment.
No, of course not. I used only one example.
He’s been paid to write drivers for over 10 years (probably closer to 15) and that has not been true yet.
So in other words, only a small minority of drivers in the Linux kernel are using asm, which makes my point again that asm is not always a must.
It’s not very hard to cite real situations, or dream ones one that asm would be needed. The point is that you said asm is a must — you did not say it’s a must just in certain situations. When I say it’s untrue that asm is a must for at least half the things on your list, I am not wrong. You even support this fact yourself (see above).
I never said asm is never needed, but you did say it always is and that is incorrect.
Are you native English speaker?
I am not.
For me
Means that it is something you should learn as it will make your life easier in many situations.
I’m a native English speaker, yes. It seems we actually agree more than disagree, and just stumbled over a misunderstanding. “Must” is used to note a requirement, not a recommendation. No harm, no foul.
Let’s notice that it was already said, in that case by you, that “While being well-versed in asm can have advantages, saying it’s a must for at least half the things you’ve listed is absolutely untrue” in http://www.osnews.com/thread?530166
What are you trying to point out exactly?
More exactly, I meant:
You made clear that being well-versed in asm was good and optional, not mandatory, in http://www.osnews.com/thread?530166 :
“While being well-versed in asm can have advantages, saying it’s a must […] is absolutely untrue”
in that sentence, it’s seen that the meaning of “it’s a must” is opposed to what you just said before. The text you wrote was clear.
Edited 2012-08-09 07:18 UTC
Depends on the OS and what hardware you develop the driver for.
I’m not sure exactly what you qualify as os utilities and why they would require assembler.
Depends on what kind of game. If it’s a demanding FPS or something, yes. If not then probably no. No asm needed for using, say, PyGame, some other tookit or iPhone/Android games.
I doubt assembler is a hard requirement for this.
[/q]
Feel free to develop for these processors with anything other than Assembly
http://www.microchip.com/pagehandler/en-us/family/8bit/home.html
http://www.microchip.com/pagehandler/en-us/family/16bit/
http://www.ti.com/product/tms320vc549#feature
Sure you can try to use C, but depending on the application you’ll most likely end up using Assembly to take full advantage of the scarce space or strange addressing modes not available to higher level languages.
These two statements are not necessarily mutually exclusive I fear
Edited 2012-08-07 13:07 UTC
I DO miss coding in x86. Taught myself back in the early 90’s. Wasn’t a great coder but I dug how low-level it was.
int 20h ;bye!
EDIT:
Forgot to mention I still code. But I’m stuck in ColdFusion/Oracle SQL land right now. I get very little chance to do any .Net, be it C# or what not.
Edited 2012-08-07 14:39 UTC