Hi,

First of all, I'm sorry for my bad english, I'm from Brazil and I don't know english ._.

Anyway, I'm new to assembly programming, and I have some doubts about assembly.

1 Wich is the difference about assembly 16bits and assembly 32bits?
2 I've read here, that "Art of assembly language" book has own syntax, is this true?
3 I want to learn the basis of assembly language, not only windows api like some programs I've saw.
4 Wich is the best book of assembly?

I'm sorry about the english guys ._.
I'm also trying to lean english ._.

Someone can help me? Thanks.

See you soon!
Posted on 2009-12-28 14:22:41 by Defcon
Well, I'm pretty new to assembly myself, but here are some of my thoughts (I'm mostly just regurgitating some of what I have learned recently):

1.  This is quite a general question, but there are a couple of main differences:
-16 bits will pretty much be DOS development, otherwise you are looking at 32 bits:  i.e Windows, Linux, plus many other smaller players.
-16 bits is, for most people's intents and purposes, dead for PC development (unless you are looking to develop for embedded systems), although there is still some activity.
-the available instructions, for the most part, will be the same for 16 and 32 bits:  the difference will be that the assembler will generate a prefix byte on the assembled instructions; in 16 bit mode, the prefix byte will be on 32 bit instructions and vice versa in 32 bit mode.  The idea being in 16 bit mode you try to use mostly 16 bit instructions:  i.e. deal mostly with the 16 bit registers (ax, bx, cx, dx, di, si, bp, sp) and in 32 bit mode use eax, ebx, ecx, edx, edi, esi, ebp, and esp.
-16 bit mode also forces you to use the segment registers to address any significant amount of memory > 64 KB whereas 32 bit mode allows you to address 4 GB directly.
In conclusion, although there is a lot of old 16 bit tutorials and books out there, you probably want to start in 32 bit mode:  it is going to be a lot easier to learn in and there is starting to be quite a bit of available information/tutorials.

2.  Yes, the latest version of Art of Assembly is written for use with HLA, which is designed to be a beginner's learning guide.  However, you can find older versions through search engines (this is what I am using to teach myself).

3.  It doesn't really matter what OS you use:  you are really going to have to learn an API, whether it be Windows API, Linux API, DOS API, or a hobby OS API.  However you may want to look into FASMLIB which allows you to skip some of the API learning (in exchange for learning FASMLIB).  I haven't tried it myself, but I think you can use it with most common assemblers.

4.  Art of Assembly is certainly a great start.  You may just want to google "NASM Assembly tutorial" and start from there.  There are lots of good sites/forums out there:  for example http://www.drpaulcarter.com/pcasm/index.php (from the google search above) although it has a few languages, unfortunately Portuguese doesn't seem to be one of them.

This forum has a good resource:  http://www.asmcommunity.net/book/.  Also try the FAQs at http://board.flatassembler.net/.

It doesn't really make a difference which assembler you use (it is relatively easy to learn another once you have learned one):  I started with NASM, but am finding that I like FASM better and am starting to port my code (what little I have written) to it.
MASM probably has the most examples out there, but there is plenty of NASM info as well.  Depending on how much programming you have done (I'm thinking especially with linkers), you may get your first program up and running faster with MASM, but I would recommend starting with FASM (the initial learning curve isn't too bad - if you can get the example programs, particularly 'hello world' to assemble and run, you are well on your way) - you won't have to deal with linking.  Most NASM tutorials are also quite applicable to FASM as the syntax is very similar.

Hopefully this helps you get started: good luck!

Posted on 2009-12-29 18:43:32 by sysfce2
When your projects start to grow larger (think Little Shop Of Horrors), they become unbearably slow to build.
That's where generating OBJ files and using a Linker really comes into its own.
I never really understood why Linking obj files was useful until I started coding OOPASM under MASM/ObjAsm32.
Rather than simply assembling *everything*, we can assemble *COMPONENT OBJECTS*.
Now when we build our "main project", we can link these prebuilt OBJ files, which "vastly" improves build times.
As an example, a project which normally takes 45 seconds to assemble from scratch might take 5 seconds when linking to prebuilt component objects.
For a developer, this can translate into a massive saving in development time, since you're no longer wandering off to make a coffee every time you fix a bug/rebuild your project.
And if these component objects contain code that is generally useful, you'll find yourself linking them into various projects, magnifying the benefits, and saving you from reinventing the wheel / debugging yet another implementation of the same old code you wrote for that previous project some months ago.

Posted on 2009-12-29 21:24:50 by Homer
When your projects start to grow larger (think Little Shop Of Horrors), they become unbearably slow to build.
That's where generating OBJ files and using a Linker really comes into its own.


Yeah, but for a starting point, FASM bypasses the problems that linkers can pose to beginners.  Although listing imports might be just as hard (I actually haven't tried building a program directly with FASM yet as I was focusing on getting my project to build - all my source is broken up into fairly small modules, for the reasons you state, and also because NASM seems to run slow on my machine with even moderate sized sources - part of the reason I am trying out FASM) but it doesn't look that bad though - the initial learning curve would likely be (slightly) higher than MASM, but I think in the long run leads to a better understanding of how assembly works.
But if using a linker, GoLink is an easy to use tool.

NASM (with NASMX for windows) is probably easier to use when starting out if generating .OBJ files and linking as I had to tweak the FASM macros to work with .OBJ files.  Also, if the OP doesn't mind using windows, GoAsm looks like a good tool.  I just don't particularly like the syntax as it is not what I am familiar with.

I had to google what Little Shop of Horrors was - but it looks like a good analogy.
Posted on 2009-12-29 23:38:11 by sysfce2
All I meant to convey to the new user is that code can be reused and that you can start to make your own code base from nothing. You are free to be you.
Posted on 2012-10-06 08:31:49 by Homer
Hello defcon,
I will attempt to explain a little further:


...I have some doubts about assembly.

Perhaps you mean questions about assembly.


1 Wich is the difference about assembly 16bits and assembly 32bits?

Initially, the difference is based upon the architecture of the microprocessor that the program is going to be run on.
Microprocessors have typically been 8-bit, 16-bit, 32-bit, 64-bit, etc.
The number of bits used in a microprocessor has to do with several factors dealing with the CPU design and architecture.
The width of the data bus is one factor, the number of bits used to form memory addresses is another and the number of bits used to form the CPU registers is another factor.
Nearly everything a CPU does (execute instructions) is done with the CPU registers.
Some CPU instructions bypass the registers and manipulate memory directly.
Some early 8-bit CPUs used simple registers and they were named: A,B,C,D, etc.

Later, when it was determined that CPUs needed more bits, to perform more complex instructions, the number of bits was increased to 16.
The register names were modified to reflect that they were eXtended from what they had been previously and renamed: AX,BX,CX,DX, etc.
For the benefit of programmers, the original 8-bits could still be accessed by referring to them as either: AH/AL, (for: A-High/A-Low), BH/BL, CH/CL, etc.
A 16-bit assembler is designed to create programs that generally run on a 16-bit microprocessor.
MS-DOS and Windows 3.x are 16-bit operating systems that runs on 16-bit CPUs.

A 32-bit assembler is designed to create programs that generally run on a 32-bit microprocessor.
An exception would be that, (depending on the operating system), in some cases, 16-bit instructions can be assembled and executed on a 32-bit CPU.
32-bit registers are named: EAX,EBX,ECX,EDX, etc.
Many modern CPUs have a backward compatibility, so to speak.
Windows 98 and upwards are 32-bit (and/or 64-bit) operating systems.


2 I've read here, that "Art of assembly language" book has own syntax, is this true?


Well, no..., not really.

The book: "ART OF Assembly Language Programming" by: Randall L. Hyde ((c) Copyright 1995), is perhaps one of the best for the Assembly Language beginner.
This book is fully illustrated and teaches beginner to advanced Assembly Language concepts.

Randy Hyde is also the author of Assembly High Level Language (or rather) *"High Level Assembly", which is something entirely different.
High Level Assembly Language is an effort to create a programming dialect which uses high level syntax, (found in all modern programming languages) to facilitate writing programs in a pseudo-Assembly Language.

Assembly Language and HLA are very different things and not at all the same.


3 I want to learn the basis of assembly language, not only windows api like some programs I've saw.


The Windows API (Application Programming Interface) is perhaps the most widely known.
Apple's OS also has an API, (I have not used it).
Linux has what some call an API, but, I hesitate to call it that, (that is only an opinion).
In fact, Linux does have an API, it's just a mess.

MS-DOS didn't really have an API, (...perse).
DOS, instead, used interrupts to make system calls to make things happen.
Nearly everything you did in DOS was through calling interrupts.
When writing DOS programs, if you want keyboard input, you call an interrupt to perform that function.
If you want to display to the console screen, you call an interrupt to display to the console screen.
(Personally), I find programming in DOS to be a rather fun thing to do, but, I rarely do it any more, nor does anyone else, other than students of Assembly Language programming.


4 Wich is the best book of assembly?


Well, that really depends on what you want to program.
What Assembler will you be using ?
What type of computer or device will you be programming on ?
What operating system will you be using ?

I recommend for beginners to learn to program DOS.
Modern programming begins when you start using the API.

Search Amazon.com for cheap, used, MS-DOS Assembly Language books.
Also, look for used, Windows programming books.

BTW,
I must add, that there is no ONE Assembly Language.
Dialects of Assembly Language will vary between CPUs and again between Assemblers of the same CPU.
In other words, first you decide which CPU you will be working with. That will narrow the field to certain assemblers.
Then you decide which assembler you wish to use.
That will determine the dialect you will be learning.
Most books published on the subject of Assembly Language are based on MASM, the Microsoft Macro Assembler.

edit:
I stand corrected, edited for corrections.
*I have been a member of Randy's AOA group for many years, 'tho I have never quite grasped the point of an HLL for Assembly Language.
I always thought C was a suitable HLL for Assembly Language.
In my opinion, HLA was a misnomer, a sort of oxymoron.
Posted on 2012-10-09 14:41:51 by blakguypeez
Windows 98 and upwards are 32-bit operating systems.


And since Windows Server 2003/XP, there is also support for 64-bit x86 processors (called x64 by Microsoft).

Windows 98

2 I've read here, that "Art of assembly language" book has own syntax, is this true?


Well, no..., not really.

The book: "ART OF Assembly Language Programming" by: Randall L. Hyde ((c) Copyright 1995), is perhaps one of the best for the Assembly Language beginner.
This book is fully illustrated and teaches beginner to advanced Assembly Language concepts.

Randy Hyde is also the author of "Assembly High Level Language", which is something entirely different.
Assembly High Level Language is an effort to create a programming dialect which uses high level syntax, (found in all modern programming languages) to facilitate writing programs in a pseudo-Assembly Language.

Assembly Language and A-HLL are very different things and not at all the same.


I think the confusion here is that there are multiple editions of Art of Assembly Language.
The original book was aimed at 16-bit DOS, and used MASM as the assembler.
The second edition was aimed at 32-bit, and came in linux and Windows versions, and for this, Randall Hyde introduced his own assembler (which I think is called HLA: High-Level Assembly, not A-HLL).

You can find all editions here: http://www.plantation-productions.com/Webster/www.artofasm.com/index.html
Posted on 2012-10-17 05:38:14 by Scali
Pretty good book here:
http://www.abreojosensamblador.net/Productos/AOE/html/Pags_en/Preamble.html
Originally written in Spanish, most of the chapters have been translated to English. Examples are mostly available for Masm, Fasm, and Nasm - which gives it a big advantage, IMO. Worth a look!

Best,
Frank

Posted on 2012-10-17 10:26:39 by fbkotler

Randall Hyde introduced his own assembler (which I think is called HLA: High-Level Assembly, not A-HLL).


Thanks, Scali.
I stand corrected.  ;)
Posted on 2012-10-18 13:08:51 by blakguypeez

The Windows API (Application Programming Interface) is perhaps the most widely known.
Apple's OS also has an API, (I have not used it).
Linux has what some call an API, but, I hesitate to call it that, (that is only an opinion).
In fact, Linux does have an API, it's just a mess.

MS-DOS didn't really have an API, (...perse).
DOS, instead, used interrupts to make system calls to make things happen.
Nearly everything you did in DOS was through calling interrupts.
When writing DOS programs, if you want keyboard input, you call an interrupt to perform that function.
If you want to display to the console screen, you call an interrupt to display to the console screen.
(Personally), I find programming in DOS to be a rather fun thing to do, but, I rarely do it any more, nor does anyone else, other than students of Assembly Language programming.


You find programming INT calls in DOS fun but call Linux a mess?  :shock:
Making SysCalls in Linux is almost identical in concept - just different register usage.
Have you even written a single assembly program for Linux?
My guess is you haven't because if you had then you wouldn't be spreading these fallacies.
Posted on 2012-10-18 16:33:48 by p1ranha
You find programming INT calls in DOS fun but call Linux a mess?  :shock:
Making SysCalls in Linux is almost identical in concept - just different register usage.
Have you even written a single assembly program for Linux?
My guess is you haven't because if you had then you wouldn't be spreading these fallacies.


I suppose interrupts are still an API. The MS-DOS interrupt API is based on the x86 version of CP/M by the way.
Anyway, the way I interpreted his remark is that the linux 'API' is a 'mess' because he referred to linux as in a linux distribution. And where the Win32API covers all aspects of the OS, a linux distribution is built up from various projects, where especially GUI environments can get messy... You have Xorg, then something like Qt on top of that, and the actual desktop environment (KDE, Gnome, etc) on top of that... and generally you'll have several of such libraries side-by-side, because every application just uses whichever libraries its author prefers.
So I found myself installing KDE, Gnome, lesstif and other common UI-libraries side-by-side.
There's various other areas of the system where there are multiple common libraries for a single area of functionality.
There are examples of such competing libraries/APIs on Windows as well (especially considering audio), but on the whole I suppose the Windows environment is somewhat more consistent.
Posted on 2012-10-18 17:30:13 by Scali

You find programming INT calls in DOS fun but call Linux a mess?  :shock:
Making SysCalls in Linux is almost identical in concept - just different register usage.

I wasn't referring to making system calls, I was referring to the API.  :thumbsup:


Have you even written a single assembly program for Linux?
My guess is you haven't because if you had then you wouldn't be spreading these fallacies.

I wasn't spreading a fallacy, rather I was voicing an opinion.  ;)
In fact, I'm speaking from experience in this matter, ...yes, I 'm working on an assembly program in Linux at this moment.

I think Scali got my meaning and hit the nail on the head:

...that the linux 'API' is a 'mess' because he referred to linux as in a linux distribution. And where the Win32API covers all aspects of the OS, a linux distribution is built up from various projects, where especially GUI environments can get messy...

...but on the whole I suppose the Windows environment is somewhat more consistent.


I can only assume you are an avid Linux user and programmer.
I assure you, no offense was intended.
I'm one who finds the sheer number of Linux distros to be a bit overwhelming.
Too many distros, too many flavors, too many projects, too many APIs, ...
I prefer consistancy in an API,  ...just my opinion...  :)
Posted on 2012-10-18 21:16:01 by blakguypeez
I'm a fairly "avid" Linux user, and I think you've got a point. Depends on what you consider "the API". System calls could be considered "the API", but "the C interface IS the Unix interface" in another sense, so maybe that's "the API". You're interacting with a dynamic library - just like the Windows API. When it comes to graphics, it's a wildly different situation. The "X server" is an independent program - completely separate from the kernel. It is possible to communicate with X via "pure system calls" - socket, connect, write, read... much like communicating with the internet. Virtually nobody does it that way. Xlib wraps this connection, but it's considered "too low level" by most programmers. Most people use "helper libraries" of various flavors and "levels". At this point you could reasonably call it "a mess". Or... you could say that we have choices not available in Windows.

In terms of "some help to start" (are we still talking about "some help to start"?), you aren't likely to find much information based on assembly language. If you know how to interface with any library - the Windows API, C libraries, Xlib... the idea is generally the same. The "assembly language part" isn't too difficult - "push" and "call" mostly...

If it isn't too far off topic, what sort of a Linux program are you working on, blakguypeez?

Best,
Frank

Posted on 2012-10-18 23:17:20 by fbkotler

At this point you could reasonably call it "a mess". Or... you could say that we have choices not available in Windows.


Technically that's not even true.
There are various X-Window implementations available for Windows. And various popular GUI libraries used on linux are actually cross-platform and also have a Windows port.
It's just that hardly anyone makes that choice. X-Window applications on Windows are generally just lazy ports of *nix applications (you see the same on OS X for example). Instead of trying to write platform-agnostic code, they'll just use something like Cygwin to simulate a *nix environment on Windows.

And a lot of applications are written as native Windows applications, where most people prefer to use the standard Win32/MFC/WinForms/WPF/etc toolkits from Microsoft, rather than opting for a cross-platform solution such as Qt.
Posted on 2012-10-19 03:44:43 by Scali

Depends on what you consider "the API".
System calls could be considered "the API", but "the C interface IS the Unix interface" in another sense, so maybe that's "the API".


When I was doing DOS programming, I never considered DOS system calls as being the API. In fact, not until MS first introduced Windows did I ever hear the term API. I recall that being a major discussion among programmers at the time, that you no longer made system calls, but, instead used this new 'API'.
http://en.wikipedia.org/wiki/API


In terms of "some help to start" (are we still talking about "some help to start"?),

I thought we were.
Sorry Defcon, I didn't mean to derail the thread....

OT:

If it isn't too far off topic, what sort of a Linux program are you working on, blakguypeez?

It's way OT, but,...
My personal interest is in programming language compilers, translators and assemblers.
Currently, I'm working on a little project that translates the libc headers to 'inc' type files for usage with assemblers. Yet another attempt at producing a workable h2inc like program. This is not a new idea. It's been attempted a number of times by others, but, never quite finished or succeeded in getting very far, as I'm sure you know.
A problem encountered, with regard to Linux, is that there appears to be too many cooks in the kitchen.
Posted on 2012-10-19 09:45:27 by blakguypeez

When I was doing DOS programming, I never considered DOS system calls as being the API. In fact, not until MS first introduced Windows did I ever hear the term API. I recall that being a major discussion among programmers at the time, that you no longer made system calls, but, instead used this new 'API'.
http://en.wikipedia.org/wiki/API


I think the problem might be that 'API' is a relatively new term. I don't recall anyone using that term in the 80s either, regardless of what OS and language they used.
But these days there's even a wiki entry for MS-DOS API: http://en.wikipedia.org/wiki/MS-DOS_API
I guess it's similar to people not referring to x86 as a CISC architecture until the advent of RISC: the term CISC simply did not exist yet. The technology did, obviously.
I'd like to know where the term 'API' actually came from, and when it first came into use.
The first time I heard it, was with Win32API, so I wonder if it's a term that came from Microsoft/IBM, or perhaps the VMS world.
Posted on 2012-10-19 10:29:35 by Scali

I think the problem might be that 'API' is a relatively new term. I don't recall anyone using that term in the 80s either, regardless of what OS and language they used.


FYI: You can find references to the term API as far back as the 70's - coincidentally with the appearance of the C language.  Early IETF RFC's also contain this term.
Posted on 2012-10-19 11:02:54 by p1ranha

But these days there's even a wiki entry for MS-DOS API: http://en.wikipedia.org/wiki/MS-DOS_API


In hind site, I guess you would/could consider DOS interrupts as a library of system function calls and in that respect it would be a valid reference to an API. It's just that most of us never thought of it as nor called it that.


I'd like to know where the term 'API' actually came from, and when it first came into use.
The first time I heard it, was with Win32API, so I wonder if it's a term that came from Microsoft/IBM, or perhaps the VMS world.


I don't know. When I first heard it, it was simply 'Windows API'.
Since I'd never heard that term before, I guessed it was perhaps a MS invented term.

I never heard of the CRT (C Runtime Library) being referred to as the C API, so I just assumed that the CRT was an integral component of the Win API, despite the fact that the CRT is a library all to its self.
Posted on 2012-10-19 11:54:57 by blakguypeez


I think the problem might be that 'API' is a relatively new term. I don't recall anyone using that term in the 80s either, regardless of what OS and language they used.


FYI: You can find references to the term API as far back as the 70's - coincidentally with the appearance of the C language.  Early IETF RFC's also contain this term.


Perhaps (in such cases it would be nice to cite sources), but that doesn't mean that the term was common outside that particular community.
I think at the very least the term was popularized in 'my community' of home/personal computing because Microsoft started using the term API in their Windows documentation. I don't recall seeing that term back in my Turbo C++ days in DOS, let alone on Amiga or C64. I just checked the Turbo C++ 3.1 help files, and they don't seem to make any mention of API at all.

Again I can draw a parallel with the term 'CISC': The term RISC comes from the Berkeley RISC project started in 1980: http://en.wikipedia.org/wiki/Berkeley_RISC
(All the more interesting with two of the most famous CISC architectures, 68k and x86, being introduced only just before that in 1978-1979)
But outside the research world, most people probably had never heard of RISC (and therefore CISC) until RISC processors actually became available in relatively mainstream devices in the early 90s.
Posted on 2012-10-19 15:32:10 by Scali

Perhaps (in such cases it would be nice to cite sources), but that doesn't mean that the term was common outside that particular community.


Irrelevant. Your original question was with regard to timeline of introduction - not common usage.
Allow me to quote you:

I think the problem might be that 'API' is a relatively new term. I don't recall anyone using that term in the 80s either, regardless of what OS and language they used.


FYI: For sources you can start with this RFC ( dated Aug, 1989 and authored by Vincent Cerf ) and work backwards to find the first usage.  I don't have time, nor inclination, to research further.
http://tools.ietf.org/html/rfc1109


I don't know. When I first heard it, it was simply 'Windows API'.
Since I'd never heard that term before, I guessed it was perhaps a MS invented term.


And this is exactly the problem with most people who have no experience outside of Microsoft.  They commonly think everything was "invented" by Microsoft when in fact a lot of the terminology and technology existed long before Windows was even a glint in Bill G's eye.  I'm not debating that Windows doesn't have any original ideas - just that Microsoft isn't the source of all technology innovation.

Posted on 2012-10-19 16:53:56 by p1ranha