Hi,
I've recently started to learn assembly (80x86, MASM32) as a hobby. I was wondering, is it true that once you get the hang of it, other languages, such as Delphi and C++, will become easier to learn? Also, I'm currently using this tutorial because it was one of the most in-depth ones I've read so far:

http://maven.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html

The only problem is that the last update occurred sometime in the 1960's. I was wondering if this guide was good to learn from (I've been reading a chapter a day, currently at chapter 6), seeing as it doesn't have any beginner example coding such as "hello-world."

  Another problem I'm having is that I'm learning some new techniques and concepts from the tutorial, but I'm unsure of what I can actually do with the newly learned things. For example, arrays and structures, what is their purpose? I've learned so far that they basically hold elements, of which we use some formulas (Base_Address + (current index-initial index)*element size <-- something along those lines) to access.

Any help is greatly appreciated, sorry if I've written too much.
BeginnerASM-ist.
Posted on 2007-08-14 23:25:34 by BeginnerASM-ist

Hi,
I've recently started to learn assembly (80x86, MASM32) as a hobby.


Welcome aboard :)


I was wondering, is it true that once you get the hang of it, other languages, such as Delphi and C++, will become easier to learn?


Yes and no. Ideally, learning assembly language will teach you what those High-Level Languages "really" do. With that knowledge, you can understand the basis of such High-Level Languages by simply breaking-down the functionality of the language into actual mechnaisms. Also, this will help you pick the most optimal/efficient routines and methods (e.g. using an LONG instead of an unnecessary FLOAT in C.)

Realistically, it is up to how much attention you pay to your programming efforts. Most High-Level programmers I have met effectively see the computer as "magic" and they don't care as long as MessageBox() creates a Message Box. If you pro-actively analyze your code and how it relates to what the computer actually does (i.e. mass data manipulation), you *will* achieve a greater level of understanding and such habits will manifest themselves by an increase in program execution speed, decrease in program size and/or decrease in development time.


Also, I'm currently using this tutorial because it was one of the most in-depth ones I've read so far:

http://maven.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html

The only problem is that the last update occurred sometime in the 1960's. I was wondering if this guide was good to learn from (I've been reading a chapter a day, currently at chapter 6), seeing as it doesn't have any beginner example coding such as "hello-world."


That site you are reading is actually a version of Randall Hyde's AoA (Art of Assembly) book. You can find his "authentic" website at http://webster.cs.ucr.edu/ which contains PDF format downloads for all of his AoA works. AoA is very popular in that it helps teach assembly language basics.

As for the "1960's" comment, between the fact that the x86 didn't exist in the 60's and AoA's publishing timeframe... you must have mis-read/interpreted it. All of the AoA material was, to my knowledge, written within the last two decades.


  Another problem I'm having is that I'm learning some new techniques and concepts from the tutorial, but I'm unsure of what I can actually do with the newly learned things. For example, arrays and structures, what is their purpose? I've learned so far that they basically hold elements, of which we use some formulas (Base_Address + (current index-initial index)*element size <-- something along those lines) to access.


Structures and Arrays are the basis of organized data sorting and manipulation. From my experience, you are required a need for such material before it becomes useful. My best advise at the moment would be to keep those principles in the back of your mind, continue futher on with your reading and when you get to the point where you need to actually *implement* such things... rely on the fact that you know *where* to find the information you need to bridge those knowledge gaps.

However, to illustrate a little, imagine an algorithm that processes fixed-size data in sequential order (e.g. telephone numbers in a phone book.) In order to increase efficiency, the location of said data would be one after another after another ad infinitum. Using such a data structure, your algorithm can take an offset number (e.g. entry 23), calculate the physical memory offset based on fixed-data size TIMES entry number, add that to the actual base address of the data structure and there you have direct and controlled access to indexed information. Using that same entry number, you can (in this example of a telephone book) access a new and relative structure of names for those telephone numbers. All of a sudden, due to neat and organized data structures/arrays, you have easy scalability (i.e. minimal work in implementing new program features.)

Remember, computers only "see" numbers, and that is essentially what you have to work with... so make those numbers work for you in the most efficient manner as possible ;)
Posted on 2007-08-15 00:14:39 by SpooK
Theres a couple of packages that can give you a visual picture of what you're doing right...or not doing right in those early stages.  ;)

http://www.btinternet.com/~btketman/
(Even runs on a DOS handheld for read-anywhere portability)

http://www.emu8086.com/

Posted on 2007-08-15 04:07:46 by eek
Hi,
Thanks for all the replies! I tried the newer version of Art of Assembly before, but I remembered I didn't want to learn it because it was about HLA rather than MASM. I think I'll try to find another tutorial with more example codes.
Thanks,
BeginnerASM-ist.
Posted on 2007-08-15 10:18:23 by BeginnerASM-ist
I played around with the emu8086 a little because a friend of mine was wondering if it was worth buying to learn with. It's an alright little tool to play around with, iirc it also supports a FASM syntax mode so you can practice 8086 programming using that preferred style and easily switch over to FASM when you get to 80x86. Although I'm still not sure if it's worth buying.. it's not that great and it's primarily based off of open source utilities (other than the emulator and you can get emulators free anywhere). My suggestion would be to just look  on this forum where it says "The ASM Wiki Book" and go there, then scroll down to the bottom of the page to the "Resources" section and click the "Links" link to check out the list of recommended sites suggested by members of this forum. If you cover all the information in those links you should be set. ;)

In my opinion, I think Spook downplayed the importance of structures and arrays to programming. I personally think you should spend a little extra time really solidifying your understanding of data management/handling before you move on to other areas. My reason is, depending on what your interested in, you will use this stuff A LOT. His example was a phone book program, good example. But take for example networking applications, yes simple demo networking applications rarely show much of this kinda stuff, but when you decide to write anything that is actually going to be used by someone chances are you are going to start managing multiple sockets, threads, and sometimes even creating your own sub-(TCP|UDP) protocols which will have their own headers. And believe it or not, this is actually very common. This material will also come in handy whenever you want to manipulate binary files (like images) or maybe save settings but you don't want to make bulky ini files or rely on a non-portable registry entry. Encryption, compression, the list goes on. Who knows, maybe I'm over thinking it. I just consider that to be one of the more important first steps to understanding Assembly language.

Regards,
Bryant Keller
Posted on 2007-08-15 17:29:10 by Synfire
   Thanks for the links, I checked out some of them, but a lot were broken. I've decided to learn from Iczelion's tutorials (I read that it was the best tutorial to learn ASM from). Thanks for the help! Oh and about the arrays and structures, I guess I didn't know how important they were because the tutorial I read didn't specify their purpose. Next time I come across it, I'll make sure to pay careful attention to them.

Thanks,
BeginnerASM-ist.

EDIT: Iczelion's tutorials are HLA I think, so I'm just going to stick with the outdated AoA but reread it and implement more program creation into my learning sessions.
Posted on 2007-08-15 19:25:33 by BeginnerASM-ist
Iczelion's tutorials are HLA I think, so I'm just going to stick with the outdated AoA but reread it and implement more program creation into my learning sessions.


Iczelion's tutorials target Microsoft's Macro Assembler (MASM), more specifically, a package called MASM32 which includes MASM, libraries, code and tutorials for Win32 Assembly Language Development. With MASM32, you are basically targeting the x86 processor series running in 32-bit Protected Mode (current standard) using the Windows API... hence "Win32ASM" ;)

Randall Hyde's HLA is the successor to his AoA teaching methods. Gradually takes you from High-Level concepts down to Low-Level ones.

MASM is more standard, HLA is probably more "newbie" friendly. Choose your poison :P
Posted on 2007-08-16 00:58:22 by SpooK
How come Iczelion's tutorials don't go over the instruction set (like mov, add, sub, lea)?
Thanks for your help.
Posted on 2007-08-16 08:54:38 by BeginnerASM-ist
Iczelion's tutorials cover win32 programming in assembly, focus is more on win32 programming. Check out madwizard.org, it has a tutorial that covers some of the frequently used opcodes and stuff.
Posted on 2007-08-16 09:49:40 by lone_samurai5
More specifically, the tutorials section at madwizard :)
Posted on 2007-08-16 17:52:55 by f0dder
Sorry, one last question.

Will reading iczelion's masm32 tutorials allow me to understand the code make-up programs? For example, will it help me understand why we use certain functions in certain situations (like lea and mov, lea is used for near pointers, but mov basically copies data from one location to another right?). I'm sorry if I'm asking too many questions, its a little confusing for my first language but I really want to learn this.
Thanks,
BeginnerASM-ist.
Posted on 2007-08-21 20:34:29 by BeginnerASM-ist

Sorry, one last question.

Will reading iczelion's masm32 tutorials allow me to understand the code make-up programs? For example, will it help me understand why we use certain functions in certain situations (like lea and mov, lea is used for near pointers, but mov basically copies data from one location to another right?). I'm sorry if I'm asking too many questions, its a little confusing for my first language but I really want to learn this.
Thanks,
BeginnerASM-ist.


Perhaps, but you will have to be aware of the context of the instructions being used. I wouldn't rely on Iczelion's Tutorials as more than a means of writing assembly language-based programs under the 32-bit Windows.

AoA will be a better source of theory and application.
Posted on 2007-08-21 20:56:55 by SpooK

Will reading iczelion's masm32 tutorials allow me to understand the code make-up programs? For example, will it help me understand why we use certain functions in certain situations (like lea and mov, lea is used for near pointers, but mov basically copies data from one location to another right?).


Stepping through some simple code in a debugger might help you understand these instructions better. Try ollydbg.
Posted on 2007-08-22 01:33:17 by lone_samurai5
Right. Stepping through a Debugger is the easiest way for learning. The reason why the RosAsm team has created the Twelve Assembly Lessons:

< http://rosasm.org > ---> Top of the Tutorials Section.


Betov.
Posted on 2007-08-22 04:48:10 by Betov
Also, if you have high-level language experience, you can try looking at the assembly output from your HLL code - that can also be a valuable experience.
Posted on 2007-08-22 05:03:37 by f0dder
My best advice right now would be for you to learn a higher level language (I know I absolutely hated it when people said this to me but I now see the wisdom). However if you're determined to sticking to asm (right on! :D), I would suggest you learn how the processor handles commands and the actual binary coding of each command. Not to memorize all of the opcodes like mov and etc. but look and understand the SIB and Mod/RM byte because (for me at least), it helped to eliminate many of the errors and other hardships I encountered when first learning asm. Also, don't focus on Floating points yet, cause that really screwed me over in the beginning, when I tried to learn the FPU way too soon. For now just stick to the basic, ie, what does mov, lea, xor etc. do, the operands of each command, etc. Imo, I don't think you should learn DOS simply because it is so old. Instead start with simple stuff like a Hello World MessageBoxA example once you get the very very basic stuff down. After that, just go through iczelion's tutorials. They will be the most useful to you since you will PROBABLY be programming Win32 asm.

If you want to look at the future and other more advanced stuff that you're going to program say... a partition magic clone, a network sniffing driver, a game, or whatever, you'll mostly need to grab it from C++ or other code since majority of examples are written in it.
Posted on 2007-08-24 00:13:11 by 16thfactor
My advice is to take it a step at a time. Start with the Iczelion's Tutorials as previously noted and try to get a hang of the most basic opcodes and macros (ie: mov, ret, invoke ...) and get a window going. There is no need to know how to create a window from scratch, if you understand enough to modify an existing one you should be all set. (quick progress minimizes frustration)

Soon enough you want to stray from the path and you be stumped on how to examine a string, or just figure out how many 's' there are in 'Mississippi' or something like that. Then you look into those opcodes (scasb, movsb, lea ... )

Never read ahead - like FPU, Optimizations, etc, etc until you actually "need" it is my advice. :)

No need to jump in and get overwhelmed. As long as a newcomer doesn't want to create a DVD-Burning program off the bat I guaranty fast progress and lots of fun.
Posted on 2007-08-24 07:29:26 by JimmyClif
Thanks for the reply, I'll try and clear up my purpose of learning assembly.

   I originally wanted to make games, but right now I'm just trying to understand the coding and try to alter it. I look at some free mmorpgs in a debugger (I'm using ollydbg), and am utterly confused at the coding. I want to learn how to understand the code and write programs that use the code and modify it. (after I get past this step, I'll try and code some very; and I mean very, simple games).

  I was thinking of learning a bit of C++, but before that I'll try iczelion's tutorials and see if I understand any of the coding after that.
Posted on 2007-08-24 22:26:32 by BeginnerASM-ist
Learning programming starting from debugging is probably going to keep you from learning at all. Disassembled/debugged code lacks comments, and I don't care what anyone says... comments are vital for clarity of code functionality. It can take a long time for even seasoned experts in debugging/reversing to *completely* deduce what the purpose of any particular block of assembly language code. Functional languages, such as C, help make this task a little easier due to some predictability of code output from compilers... but it is still a heavy task none-the-less.

You are definitely better off learning a higher-level language at this point, as you seem to have little understand of programming basics in general. Start learning C/C++ or Pascal, perhaps even a form of BASIC, and get down the general programming fundamentals. Once you've developed small examples, of these things you want to modify, in a higher-level language... well... you'll understand what to do at that point ;)
Posted on 2007-08-24 23:06:37 by SpooK
Personally, I see nothing wrong by learning programming in Assembly first. True, first earning a high-level language such as C or BASIC will give you instant gratification, and let you put text on the screen ala a "Hello World" program. But, learning programming this way, you will not have a deep appreciation for what is actually going on. You will learn to think in high-level terms, such as 'print "blah"' puts "blah" on the screen, and have no idea of why it works.

In that same regard, I would say Iczelion's tutorials, while they are excellently written and are a perfect introduction to Windows programming in assembly, are the worst thing you could be reading to learn Assembly. All you would be doing is replacing high-level programming statements, such as "print", with API calls, such as "DrawTextA". Essentially, everything would still seem magical in so far as how they worked.

I would advise a couple different courses of action. You could stick with the Art of Assembly. If you do that, you will REALLY learn how a program and computer processor work, specifically those of the Intel family. Once you understand HLA in its low-level terms, translating to MASM, TASM, NASM, GoAsm, RosAsm, or any other assembler is only a matter of learning that assembler's dialect. That really only takes a few minutes, in most cases. Notwithstanding, I kinda agree with you on not wanting to learn HLA. It does feel a bit not-assembly-ish. Alternatively, you could pick up a good book that dives right into real, low-level Assembly, like Assembly Step by Step. Going that route, it will take you a while before you can even put a sentence on the screen, but it is a great book for learning the basics, and it gets you up to speed quickly. I would only caution that you skip the chapters on Linux assembly, which kinda suck, in my opinion. I am sure some of the staff here could point out dozens of other great books and online resources.

Once you learn Assembly, then go back to Iczelion's tutorials and learn Windows programming concepts... in Assembly.

Assembly is not hard to learn at all, given the write learning material, but it is involving.

SpooK said that learning programming from debugging will probably keep you from learning at all. He is right in the sense that watching some random program in a debugger will give you little clue for what is happening. But, I would further qualify his statement in that you SHOULD watch YOUR programs run in a debugger, and keep an eye on your Flags and Registers. This will teach you volumes in what your instructions are actually doing, where your assumptions may have been wrong, and what you need to fix when something does not work.

And, do comment your programs well, even more than you think you need when first starting. No need to comment what each instruction does... That is pointless unless the instruction is doing something out of the ordinary. Comment what sections of your program are doing, and comment any assumptions that you make. It will pay dividends in your learning and in understanding what you wrote months ago when you come back to it later. If you noticed anything in Iczelion's tutorials, he has a mountain of explanation to a mole hill of code. Can you imagine how incomprehensible his tutorials would be without his explanations? That is what your comments should do, explain what is happening in human-understandable terms.
Posted on 2007-08-25 23:57:30 by TheAbysmal