Linked by Thom Holwerda on Mon 6th Aug 2012 21:50 UTC, submitted by iseyler
General Development 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."
Order by: Score:
X64
by Carewolf on Mon 6th Aug 2012 22:43 UTC
Carewolf
Member since:
2005-09-08

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.

Reply Score: 5

RE: X64
by renox on Tue 7th Aug 2012 08:26 UTC in reply to "X64"
renox Member since:
2005-07-06

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.

Reply Score: 9

It looks so ... sensible
by Dr.Mabuse on Tue 7th Aug 2012 00:44 UTC
Dr.Mabuse
Member since:
2009-05-19

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... :-)

Reply Score: 2

RE: It looks so ... sensible
by nutt on Tue 7th Aug 2012 10:44 UTC in reply to "It looks so ... sensible"
nutt Member since:
2011-06-22

16 general purpose 64-bit registers? Sign me up!

Why settle for less? PPC64 has 32 of them.

Reply Score: 2

Intel Syntax!
by moondevil on Tue 7th Aug 2012 06:51 UTC
moondevil
Member since:
2005-07-08

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. ;)

Reply Score: 6

RE: Intel Syntax!
by WereCatf on Tue 7th Aug 2012 07:03 UTC in reply to "Intel Syntax!"
WereCatf Member since:
2006-02-15

Oh, those young days spent coding demos in Assembly , naively thinking nothing else would be needed. ;)


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

Reply Score: 6

RE[2]: Intel Syntax!
by moondevil on Tue 7th Aug 2012 08:28 UTC in reply to "RE: Intel Syntax!"
moondevil Member since:
2005-07-08

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.


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.

Reply Score: 5

Uh?
by WereCatf on Tue 7th Aug 2012 06:54 UTC
WereCatf
Member since:
2006-02-15

"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.

Reply Score: 7

RE: Uh?
by Mrokii on Tue 7th Aug 2012 08:40 UTC in reply to "Uh?"
Mrokii Member since:
2011-01-04

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...

Reply Score: 1

RE[2]: Uh?
by Neolander on Tue 7th Aug 2012 09:04 UTC in reply to "RE: Uh?"
Neolander Member since:
2010-03-08

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

Reply Score: 3

RE[3]: Uh?
by Mrokii on Tue 7th Aug 2012 15:33 UTC in reply to "RE[2]: Uh?"
Mrokii Member since:
2011-01-04

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.

Reply Score: 1

RE[2]: Uh?
by jessesmith on Tue 7th Aug 2012 13:38 UTC in reply to "RE: Uh?"
jessesmith Member since:
2010-03-11

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.

Reply Score: 3

RE[3]: Uh?
by Mrokii on Tue 7th Aug 2012 15:37 UTC in reply to "RE[2]: Uh?"
Mrokii Member since:
2011-01-04

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.

Reply Score: 1

RE[2]: Uh?
by moondevil on Tue 7th Aug 2012 15:55 UTC in reply to "RE: Uh?"
moondevil Member since:
2005-07-08

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...


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

Reply Score: 2

RE[3]: Uh?
by ilovebeer on Tue 7th Aug 2012 20:07 UTC in reply to "RE[2]: Uh?"
ilovebeer Member since:
2011-08-08

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.

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.

Reply Score: 3

RE[4]: Uh?
by moondevil on Tue 7th Aug 2012 20:46 UTC in reply to "RE[3]: Uh?"
moondevil Member since:
2005-07-08

Please elaborate how it is untrue.

Reply Score: 2

RE[5]: Uh?
by ilovebeer on Tue 7th Aug 2012 23:21 UTC in reply to "RE[4]: Uh?"
ilovebeer Member since:
2011-08-08

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.

Reply Score: 3

RE[6]: Uh?
by moondevil on Wed 8th Aug 2012 06:35 UTC in reply to "RE[5]: Uh?"
moondevil Member since:
2005-07-08

"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.
"

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.

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.


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;


Since you made the claim, perhaps you should explain why you think it is, despite the fact we already know it isn't.


If you care, I can also list use cases for every single point I've listed on my previous comment.

Reply Score: 1

RE[7]: Uh?
by ilovebeer on Wed 8th Aug 2012 14:51 UTC in reply to "RE[6]: Uh?"
ilovebeer Member since:
2011-08-08

Linux is not the only kernel in town, and not all provide C API abstractions to access the hardware.

No, of course not. I used only one example.

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.

He's been paid to write drivers for over 10 years (probably closer to 15) and that has not been true yet.

Linux kernel version 3.4.7 driver tree has

- 8 Assembly files;
- 58 C files making use of inline Assembly;

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.

If you care, I can also list use cases for every single point I've listed on my previous comment.

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.

Reply Score: 3

RE[3]: Uh?
by Soulbender on Wed 8th Aug 2012 11:34 UTC in reply to "RE[2]: Uh?"
Soulbender Member since:
2005-08-18

- drivers;

Depends on the OS and what hardware you develop the driver for.

- operating systems utilities;

I'm not sure exactly what you qualify as os utilities and why they would require assembler.

- games;

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.

- develop applications that need to run in embedded systems

I doubt assembler is a hard requirement for this.

Reply Score: 3

RE[4]: Uh?
by moondevil on Wed 8th Aug 2012 13:26 UTC in reply to "RE[3]: Uh?"
moondevil Member since:
2005-07-08

"- develop applications that need to run in embedded systems

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.

Reply Score: 2

RE: Uh?
by paolo on Tue 7th Aug 2012 13:07 UTC in reply to "Uh?"
paolo Member since:
2010-06-03

"the most used parts of x86-64"


opcodes...that've been around since 8088


These two statements are not necessarily mutually exclusive I fear ;)

Edited 2012-08-07 13:07 UTC

Reply Score: 2

Mmm. ASM... [drool]
by Drunkula on Tue 7th Aug 2012 14:37 UTC
Drunkula
Member since:
2009-09-03

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

Reply Score: 2