Hi :D,
  In your experiences as an assembly language programmer - what would you say has been the best method for picking up the language?

Thanks

Q
Posted on 2009-02-05 10:55:24 by quddusaliquddus
Jump right in and set yourself an easy goal - like creating a notepad clone. Then create an alarm clock or an egg timer. First will teach you on how to create a Window, a Menu and a few Dialogs. Second one will teach you comparing and calculating. After that you could be on your way for your own stuff.

The MadWizard (http://www.madwizard.org/) tuts along with the Iczelion (http://win32assembly.online.fr/)  tuts should give you a great headstart.
Posted on 2009-02-05 13:53:55 by JimmyClif
Thanks.
Posted on 2009-02-05 13:56:12 by quddusaliquddus

Jump right in and set yourself an easy goal - like creating a notepad clone. Then create an alarm clock or an egg timer. First will teach you on how to create a Window, a Menu and a few Dialogs. Second one will teach you comparing and calculating. After that you could be on your way for your own stuff.

The MadWizard (http://www.madwizard.org/) tuts along with the Iczelion (http://win32assembly.online.fr/)  tuts should give you a great headstart.


Hi Jimmy! Your method is actually not the best method to study a new programming language, for me - an example. I have started study Assembly for 1 month in the college and i found Assembly is the most interesting programming language that i ever learned. But I still get some stuck (I am studying 8085 Microprocessor)  :shock:. I hope you guys can help me out with this (I think in forum there is no topic that's discussing about 8085).

Posted on 2009-02-20 13:31:24 by hoanock
Yes, I have to agree with you that I thought more along the lines of win32 programming than 8085 programming. :D I hope that you will find answers to your questions here.
Posted on 2009-02-20 18:17:35 by JimmyClif
Hi all :D,
        Im not sure - but I think that there are different asembly languages around. Which is the best - if there is such a thing?

Thanks

Q
Posted on 2009-04-29 08:07:26 by quddusaliquddus
Every CPU has its own set of instructions and therefore its own assembly language. Asking "which one is the best" is like asking "which CPU is the best". They all have their applications. Otherwise they wouldn't exist.
Posted on 2009-04-29 15:28:46 by ti_mo_n
Get an ASM-editor which supports syntax-highlighting (I recommend RADASM). This will support you much.
Have a (maybe simple) problem which you really want to solve - or -
create a simple "Hello-World"-high-level-language program and disassemble it. Create an ASM-listing file and study it. Once you get conformed with it expand and disassemble it again.
Get source-code from the MASM32-community and use it as hints.
Get familiar with the "von Neumann"-structure of a general todays-computer design.
This is essential to understand managing data- and code structures.
Get familiar with the 80x86-processor structure:
Basically this includes:
- the standard registers (xAX, xBX, xCX... xSI...)
- Boolean operators (AND/OR/XOR/NOT...)
- Mathematic instructions (ADD/SUB/MUL/DIV...)
- Memory-addressing modes (which are very versatilely on 80x86-processors)
- the stack (which includes calling subroutine conventions)

(If you plan to program in WIN32 only, you are spared to learn anything about interrupts.)

After you have mastered the processor design (which is a lot of initial work, of course) and if you have understood it then you will recognize that not much more is necessary to write a good program and how easy algorithms can be created in contrast to long-winded high-level-language constructs.
But there will be a lot of work and time to achieve this...
Posted on 2009-04-29 15:46:46 by TasmDev
Thanks for the info. It is very helpful.
Posted on 2009-04-29 18:20:21 by quddusaliquddus
Code your C homeworks in Assembly. Did the trick for me.
Posted on 2009-04-30 09:07:26 by ChaperonNoir
Personally, I think the best method to learn any language if you have no prior programming experience is to start out by studying program logic before undertaking a language itself. There are tools out there that can help you to learn this without having to know any language at all, such as Alice 2.0. These tools give you a graphical world to model through the use of a very simple to use utility which helps you to begin to understand things like conditional statements, iterations, all the way up to objects, methods, and inheritance. Once you've played around with such a tool for a few weeks and have designed a few interactions (a game or two) then start looking into taking the fundamentals you've learned and applying them to the programming language of your choice.

When I started out they didn't have tools like this, I wish they did. I was only introduced to them recently when I was made to take a program logic class in college. I was amazed at how quickly people picked up programming concepts by using such tools. Trust me, it's in your best interest.

When you begin to program, get in the habit of writing up Event Planning Documents, Requirement Documents, and Use Case Definition files for each one of your projects. You'll need to know these formats if you ever plan to do anything professionally and they are major time-savers in the design phase for large-scale projects when you start getting serious about programming. Also get used to drawing rough drafts of your user interfaces on paper (I still rarely do that, but probably should).

As far as assembly language itself, get a copy of the Intel Instruction set manuals, and as much demo code as possible. If you wish to learn on Linux I suggest the asmutils package, it's a version of the standard binutils written completely in assembly. It'll work as a great set of demos. If you are working through Windows then I suggest Iczellion's tutorials and his file repository, as well as the MadWizard site.

From there, just write as much as you can. Reinvent the wheel if you have to, follow the full development process each time. Start out small and work your way up. For example, create a simple notepad clone, then add a build menu, then add regex search features, then add syntax highlighting, then add code folding, a snippets manager. Save each increment as it's own project, rewriting the program from scratch each time. This will solidify your API and Assembly Language knowledge as well as give you tons of practice. Do this with as many types of projects and see how far you can take them.

Also, try to vary your applications. If you do the code editor, make your next application a network server/client, and then your next one some kind of image editor or media player. Work with databases, or whatever. Get play don't get stuck in just one type of application because I see people really become specialized to the point where they CAN'T do anything else.

These are basically my suggestions from mistakes that I myself and people I know have made in the past, as well as things I've picked up from being in college. If you were wondering how I learned, well I did it the hard way, I would write a program in C then open it in a debugger and play around with the code till I learned what it did. But back then there wasn't much of a choice, I didn't have internet, I ran DOS, and I had no documentation except the ones which came with the installation of Turbo C++ which was on the computer I bought... It was very rough going back then. (I was 9 y/o) It took what seemed like forever and I don't suggest anyone try it. It's more of the "What Not To Do" lol.

~Bryant
Posted on 2009-05-01 00:04:50 by Synfire
I agree with Synfire. I think you first need to know what 'programming' is, before you learn programming in assembly.
If you have no prior experience at all, you could start with a simple programming/script language, perhaps VB, Java or PHP or something like that.

Then you could start with C (not C++ , as C++ is very complex and a lot of its features such as templates and object-oriented programming don't really have a lot of value when you're just starting with assembly). C is a very simple and straightforward language, close to the machine. It will give you an idea of structured programming and how memory is laid out, and how it can be addressed etc.
Once you know C, it's very easy to go to assembly from there. I like to think of C as 'portable assembly'. C statements are little more than simple macros for standard assembly operations. So you can start by systematically translating C to assembly easily.
Another advantage is that most C compilers allow you to put inline assembly in your code. So you don't have to write your entire program in assembly at once. You could start by just making one or two functions in assembly, and gradually make the transition.

That's more or less how I learnt it anyway. The thing with languages like C and assembly is that they have very little rules by themselves... But if you are familiar with more highlevel languages, it is good practice to apply some of their concepts in C or assembly, because it will give you nicely structured code, which is easier to understand and maintain. So just because the language doesn't really have rules doesn't mean that you shouldn't force rules on yourself when writing it :)
Posted on 2009-05-01 05:59:56 by Scali
Another good idea is to hang around Assembly language forums and read!

By the way Synfire, is it really that easy to create a Notepad clone? I think it's a pretty bad idea because you have to learn a shitload about the Windows API and in the end you end up reading documentation more than writing assembly code... I know that when I started, I wanted to do just that and I learned assembly with the win32 api at the same time. It's like learning 2 very complex things at the same time! I don't recommend someone to do that. Because of that, It took me a long time to become good in both of them. I don't regret doing that but if you want to learn assembly faster, you have to put a few things aside.

But your part about the logic, I totally agree.  I would add that understanding how linkers work, how data works, DLLs and stuff like that is really useful. And of course, learning how to use a decent debugger. With assembly, you can really test the limits of your machine. How fast is that, how big is that, how are instructions encoded etc.
Posted on 2009-05-01 21:42:34 by ChaperonNoir
Whats the most exciting thing you can do with assembly that you cant do with other languages (in your opinions)?

Personally - I like the idea that you can build your own OS - no matter how simple.
Posted on 2009-05-02 16:50:59 by quddusaliquddus

Another good idea is to hang around Assembly language forums and read!

By the way Synfire, is it really that easy to create a Notepad clone? I think it's a pretty bad idea because you have to learn a ****load about the Windows API and in the end you end up reading documentation more than writing assembly code... I know that when I started, I wanted to do just that and I learned assembly with the win32 api at the same time. It's like learning 2 very complex things at the same time! I don't recommend someone to do that. Because of that, It took me a long time to become good in both of them. I don't regret doing that but if you want to learn assembly faster, you have to put a few things aside.

But your part about the logic, I totally agree.  I would add that understanding how linkers work, how data works, DLLs and stuff like that is really useful. And of course, learning how to use a decent debugger. With assembly, you can really test the limits of your machine. How fast is that, how big is that, how are instructions encoded etc.


It sorta depends. If a person makes use of resources, creating a notepad "clone" isn't really that difficult of a first project, they can focus on learning things like comparison, saving loading variables, etc. Then add in searching/replacing functions, and then finally brake out a win32 api guide and build up the basic copy/paste/etc. I've tutored a few people in learning assembly who had no programming experience prior and I usually start them out with either a win32 text editor or a cli ini/registry tool depending on what their goals are. Keep in mind, I like their first application to be something they can start on, build on, and when completed they will usually be proud of and might actually use. They also learn during the process patience, as unlike when developing "Hello, World" they spend time on the program and it could take months to finish. They get to experience our good friend "The Bug" in most cases and when they do they get to play around with debugging tools and learn how to find/fix the problems (further reinforcing the proper development process). Throughout their development process they build in increments, adding features to the clone, building, testing, etc. so that they can see immediate results of their work and their progress. A lot of people don't like this method so I'm not surprised with your response, and with those I have tutored, I always advise doing smaller side projects to test out algorithms and features before commiting them to their current project. But I just know too many people who have learned through the "Hello, World" -> "ReadIn" -> etc. method and by the time they get through with the sockets they have forgotten what they did in the first few because as they finished each part they deleted it thinking "Oh! I'm done with that one! Yay!".

Scali,
The only warning I like to give people who start out with C is not to get stuck on types. As we both know that can confuse the heck out of a lot of novices. That's why I like the use of these newer tools like Alice, and even scripting languages like Ruby and PERL which have no types to worry about because it makes the transition a little easier (IMHO). It just seems people have trouble understanding that in memory you aren't restricted to a set type size or container, especially when dealing with C/C++ linguists. I've actually seen people write typecasting macros which result to nothing just so they won't get too confused.

like:
MACRO $INT(X)
EXITM<X>
ENDM


Things like that are just so redundant and I hate to see people get stuck in that kind of mindset.
Posted on 2009-05-03 12:39:25 by Synfire

Whats the most exciting thing you can do with assembly that you cant do with other languages (in your opinions)?

Personally - I like the idea that you can build your own OS - no matter how simple.


Well, if we are restricting this conversation to just intel based processors then optimization hacks are always fun, bootstrap code and playing around with undocumented opcodes and windows structures can be worthwhile as well. If you let us broaden the spectrum a little, I've been doing a lot of TI-BASIC and there are just some things which take the calculator to draw out, but if build your program using a Z80 assembler then upload it to the calculator as an application you aren't restricted by the lag of the runtime interpreter and you can design anything from games to study tools.

Truthfully, for small devices there are limitless uses for assembly because those still have limited memory. With the PC/Desktop environment you generally use assembly to get access to things which the OS/application developer may have failed to think of giving you access to or when performance using their routines just isn't up to par and you know you can do better.
Posted on 2009-05-03 12:49:37 by Synfire

C is a very simple and straightforward language, close to the machine.


Perhaps simplistic, but not simple. How the use of * changes, depending on context, is one example of how not-so-simple C can be, even for experienced developers.

No matter what language you decide to pick up, I suggest one thing... write clean and commented code!!! Whitespace is cheap, deep analysis is expensive.
Posted on 2009-05-03 13:22:48 by SpooK

Perhaps simplistic, but not simple. How the use of * changes, depending on context, is one example of how not-so-simple C can be, even for experienced developers.


Matter of perspective I suppose.
Firstly, I wouldn't call anyone who doesn't properly understand using pointers and dereferincing an 'experienced developer'.
Secondly, is there any language where using pointers is easier than in C?
Most languages either don't let you manipulate pointers at all... or when they do, they have all kinds of special rules before you're allowed to touch pointers.
C makes it all very simple. A pointer is little more than just a number, and you can easily do arithmetic on it, just like in assembly. Ofcourse if you don't properly understand pointers and memory addressing, you can screw up royally in C... but if you want to learn assembly, you had better master this concept aswell, because assembly depends on it even more heavily than C does.
Posted on 2009-05-04 03:01:27 by Scali
The reason why I understand pointers in C perfectly now is because I program in assembly. Before, I knew what to do and what not to do but I didn't completely knew what was going on.
Posted on 2009-05-04 12:52:00 by ChaperonNoir