Where do I start with assembly?

Hey I can program in C,little bit in Python and Pascal and I really want to learn assembly. I'm 18 and finishing high school, programming is my hobby because school work sure isn't much of a challenge.

I've downloaded a few books on Assembly they are: The Art of Assembly,Assembly for Beginners, Assembly for Complete Beginners and Wrox Professional Assembly Language. I also downloaded a FASM, MASM and HLA compiler.

Now a few questions.

1. The examples in the Assembly for Complete Beginners are for MASM, should I run them in an emulator,someone told me that I can damage my pc if I don't use one, and if yes which emulator should I use?

2. Also how do developers make their assembly code portable? The only info I've found on this topic are on writing viruses, since viruses written in assembly have to be portable.

3. What exactly is HLA and is it the real thing or just a HLL disguised as assembly to help teach beginners assembly?

4. And where is the assembly community, except for on the obvious vxheaven and cracker websites?

I am reading a lot lately but I feel like someone who's learning Latin, but will never make it to the Vatican to meet others who speak Latin. My friends all program in Java, but don't seem to care about C or C++, they think they can use Java for everything. I'm running Windows 7 and Ubuntu 10.0.10 on an Intel. I've only been programming for about a year now... am I diving into assembly too soon? My reasons for wanting to learn assembly:

1. Want to understand more on how CPU's work.
2. Looking for a challenge.开发者_如何转开发
3. Want to learn to write efficient code.
4. Want to write smaller en faster programs.
5. Want to learn more about OS dev when I have mastered assembly.
6. If I master assembly, learning more HLL would be easier.
7. Want to have something to offer when applying for a job that others won't have.
8. Interested in AVR for example the Arduino,which uses C and not assembly but would like to understand more about AVR.

Thanks. T

1) You can't really "damage" your system more from running an assembly program than you can from, say, C. On a modern OS, the worst you'll usually end up is crashing your process. It might be a bit easier to crash your process from assembly code inadvertantly, though. If you want to get something useful out of an emulator, check out Bochs or QEMU - rather than just providing a sandbox, they have helpful debugging tools. You'll be fine without a vm, though, writing+testing code on your regular OS with your regular debugger.

2) You don't, really. You can make portable across OSes (but with same CPU) like you do it for C, but cross-cpu assembly just doesn't make sense (if you want to do that, you might as well use C or .NET or Java bytecode).

3) The subject of many a flamewar. Depends on how you look at it... an Assembler is really just a compiler that deals with assembly language. There's a lot of flavors of assembly, some higher than others; most of the ones available for x86 has macro support. HLA adds a lot of macro support and a syntax that a lot of people don't like, plus a big standard library. Not my cup of tea (I'd rather use a "real" HLL), but in my book it's still assembly language.

4) http://www.asmcommunity.net/board/ , http://board.flatassembler.net :) - stay away from IRC channels. Also, stay away from usenet alt.lang.assembly, it's been all but destroyed by a few mean individuals.

As for a couple of your reasons for learning assembly:

6.If I master assembly, learning more HLL would be easier.

Not necessarily, and it could even be harder if you "do too much" before digging into HLLs. I find that some machine architecture knowledge can lead to writing better software, but only if you learn not to obsess over tiny irrelevant details all the time.

7.Want to have something to offer when applying for a job that others won't have.

Won't necessarily help you, as assembly is utterly irrelevant in most positions. Heck, you risk prejudice of the "oh, he'll never get things done, getting lost in useless microoptimizations" kind.

Here goes...

• x86 is not ideal:
  • Very few 3-op instructions (lea is usually used as 3-op add IIRC). I like 3-op instructions.
  • x86 machine code is very different from the micro-ops that actually run on the CPU. There's a large pile of preprocessing done; the assembly you see tells you very little about how the CPU actually works.
  • A lot of assembly advice ("this instruction is faster") is a bit antiquated. Apparently you can make some ancient x86 apps faster by binary-translating x86 to x86 to get rid of the slow instructions.
• Assembly won't necessarily teach you to write "faster code". When someone goes "oh, this $large_function is slow, so I'll write it myself in assembly", usually it ends up being slower. Reading assembly and spotting the slow bits is useful; you can then tweak code to see what helps the compiler (even if it's as simple as "oh, GCC didn't notice that the result of that function call is constant").
• Assembly probably lets you write smaller code (humans are quite good at code golf), but the biggest space-saving is often because you don't need to include the C runtime. Humans can also get away with not following calling conventions.
• Operating systems are largely not written in assembly (this is where I dig up an anecdote about the person/people who wrote an entire OS in assembly only to find out that it was slower). A few bits are, the biggest of which is the boot loader (which, on x86, is still in 16-bit "real mode"). I know someone who programmed things into his boot loader; it sounds fun (but you might want to run it in a VM, if only so you can use the internet at the same time).
• Assembly probably won't help you with most jobs (but just as I wouldn't work for a place that wanted to see $list_of_languages in my CV, I wouldn't work for a place who turned me down because I've done some hobbyist assembly).
• Assembly is not portable. Even systems that use the same CPU often use a different ABI (e.g. "Classic" Mac OS vs. Mac OS X).

Most CS courses tend to use something RISCy (ARM, MIPS, SPARC). I started on M68K, picked up a bit of PPC at some point, and learned ARM at university. ARM is reasonably clean and potentially useful if you want to work with phones/embedded devices, or for ARM; for fun things you can do on ARM, try the SheevaPlug or similar.

I've never done anything on a microcontroller, but it sounds similar to using ARM dev boards (possibly the most fun I had in my entire CS course).

As you mention in nr. 8, I encourage you to use AVR, as it's a nice platform for learning and using assembler.

Why?

Because on my pc I'd not just run some self-written assembler program except in an emulator.
I can't think of any regular program for the pc where it makes more sense to program in assembler than in a modern, sophisticated language.

AVR or other microcontroller (µc) related programming is very close to the hardware, filling registers, shifting bit sets and so on.
In a µc you get immediate results that you can show (flash some led! yeah.). Also, µc programs tend to be short and their speed profits from effective programming.

Optimizing assembly language is a thing of the past. Modern C/C++ compilers and processors are amazingly efficient at optimizing well written C code. They are well aware of all the tricks to order the instructions so they maximize parallel execution and utilize the cache most efficiently. That is very hard to do by hand. Most compilers also have the option to optimize for size, if that is an issue.

If you do want to play around with assembly you can check out the GNU assembler. It is reasonably cross platform, but assembly is by nature not cross platform. You program assembly language because you want to perform some very specific hardware tricks that your compiler may not know.

If I were you and I wanted to go low level I would definitely dig into graphics hardware instead. It is close to magic what you can do with a modern GPU.

Or learn to be great at C++. Check out boost.org or game programming sites. It will give you plenty a challenge and all the speed you need.