Anyone want to help an idiot with a few questions?

[cheetahclaws]

I was taking Assembly in school for x86 IBM. I was never too good at it and never understood much of what was going on, though by the time the class was over, I had a good understanding of the basics.

Anyway, I have a few questions I wondering if you could help me with.

1. From my understanding, what I was taught in school was 16-bit ASM. Were were using TASM for editing/assembling. Our hello world looked like this below:

.MODEL SMALL
.STACK 100H
.DATA

MSG DB ' HELLO JULIAN HERE$'

.CODE
MAIN PROC   
   MOV AX, @DATA
   MOV DS, AX
   LEA DX, MSG
   MOV AH, 9
   INT 21H
   MOV AX, 4C00H
   INT 21H
   
MAIN endp
END MAIN


My question is what is the difference between 16-bit and 32-bit ASM?

2. MASM is a program package made by Microsoft, right? If so, is MASM32 based on it except it's purpose is for assembling/writing/debugging 32-bit ASM code?

3. I was wondering. We only had one class on ASM so far, unlike C/C++ which had other classes. Should I continue trying to learn the 16-bit ASM I started out learning or should I switch to trying to learn 32-bit ASM? All of the programming I plan on doing will be for Windows as I don't have any plans on going to Linux any time soon. I also hear crazy stuff like that the next in the next iteration of the Windows OS, DOS won't be present at all. If DOS is going the way of the dinosaur and 16-bit code is used for creating DOS programs, I don't see why I should bother with it. Am I wrong on this?

4. Is the "32" at the end of "MASM32" because we're(some of us) using 32-bit processors? If that's the case and Windows Longhorn is a 64-bit OS and requires a 64-bit processor, does that mean there will be a "MASM64"? Will MASM32 code run on 64-bit processors?

5. Are there books on 32-bit ASM or is it something that is realtively new?

6. Who decides the standards of 32-bit ASM? For example, the baseball league has a board that decides how everything work. For computers, there's also the ASCII(American Standard Code for Information Interchange). I think what I'm trying to see are there people regulating what's the proper way for this/that, etc.

7. How useful is 32-bit ASM? I mean like in a work enviornment, would it ever come in useful?


-Thanks!

[doomsday]

1. From my understanding, what I was taught in school was 16-bit ASM.

Yup.  Definately 16-bit code there :)

My question is what is the difference between 16-bit and 32-bit ASM?

Difficult question.

As far as the assembly instuctions go there's very little difference.  ADD still adds and SUB still subtracts.  The biggest difference is that with 32-bit code you'd be using 32-bit registers. ie. EAX and EBX instead of AX and BX.

The difficult part is that 16-bit code is used for writing DOS programs whereas 32-bit code is used for Windows programs.  In DOS code you use interrupts to print a string to the screen whereas in under Windows you call a Windows function like OutText.  DOS is a single-tasking OS whereas Windows is multi-tasking.  The change in thinking required to go from one to the other is more difficult that the change in instructions which you'll be using.

2. MASM is a program package made by Microsoft, right?

Right.

If so, is MASM32 based on it except it's purpose is for assembling/writing/debugging 32-bit ASM code?

I'll leave Hutch-- to answer this one, but basically the MASM32 package is designed to make it easier to write Windows programs in assembly.

3. I was wondering. We only had one class on ASM so far, unlike C/C++ which had other classes. Should I continue trying to learn the 16-bit ASM I started out learning or should I switch to trying to learn 32-bit ASM? All of the programming I plan on doing will be for Windows as I don't have any plans on going to Linux any time soon. I also hear crazy stuff like that the next in the next iteration of the Windows OS, DOS won't be present at all. If DOS is going the way of the dinosaur and 16-bit code is used for creating DOS programs, I don't see why I should bother with it. Am I wrong on this?

Six of one and half-a-dozen of the other.

The benefit of continuing to learn 16-bit DOS code is that DOS is dead.  It's not going to change in the forseeable future and there is a lot of material (tutorials and such) available to learn from, and you _will_ learn assembly writing it.  The step from knowing how to write DOS programs in assembly to knowing how to write Windows programs in assembly is not so great as trying to learn to write Windows programs from scratch.

BTW, don't be too concerned about DOS disappearing in the near future.  It's been said for years that "DOS is dead"... but it's persistant :)

4. Is the "32" at the end of "MASM32" because we're(some of us) using 32-bit processors?

Because we're writing 32-bit code... which, in turn, will run on 32-bit processors so the distinction is not that important.

If that's the case and Windows Longhorn is a 64-bit OS and requires a 64-bit processor, does that mean there will be a "MASM64"?

Probably

Will MASM32 code run on 64-bit processors?

Strictly speaking, no.  But it's not quite so clear cut.  16-bit DOS programs will run on your 32-bit Windows which runs on a 32-bit processor.  The 64-bit AMD64 chips run 32-bit programs (notably 32-bit Windows and it's programs).

5. Are there books on 32-bit ASM or is it something that is realtively new?

I've seen a couple but nothing I'd recomend.

6. Who decides the standards of 32-bit ASM? For example, the baseball league has a board that decides how everything work. For computers, there's also the ASCII(American Standard Code for Information Interchange). I think what I'm trying to see are there people regulating what's the proper way for this/that, etc.

The assembly language is based on the processor.  The instructions of the assembly language (ADD, SUB, DIV, etc) are the instructions which the processor can do.  So long as the processor is x86 compatible it HAS to support that set of instructions (otherwise it's not an x86 compatible processor).

The other half of what you'll write as an assembly programmer is defined by the operating system.  Under DOS you'll write assembly instructions which call interrupt handlers and under Windows you'll call various Windows functions to create windows, and move the windows, and draw text on them, etc.  And for both DOS and Windows the "standards" (which interrupt you call or which Windows function) are defined by Microsoft.

7. How useful is 32-bit ASM? I mean like in a work enviornment, would it ever come in useful?

Another difficult one.

All things being equal, you'll probably never use assembly in a programming job.  It's true that there are some jobs where assembly is essential, generally where the code you write must be either fast (game programming, graphics/sound processing) or small (bios code, devices with limited resources), but generally speaking assembly is something which is not necessary, but extremely useful to know.

Perhaps it's a bad analogy but here goes.  You don't HAVE to be a mechanic to drive a car.  But if you want to be a really good (race car) driver it definately helps to understand what's going on beneath the hood, even if you're not doing the tuning work personally.

You don't HAVE to know assembly to write programs.. but it makes you better at it when you do.

regards,
-Brent

[cheetahclaws]

Hey, thanks for the reply. I think I'll give this stuff a shot. It could only help me out later on down the line so there's no harm in try.  :toothy

[The_Grey_Beast]

Also, some High-Level Language compilers support the insertion of an asm block, like MSVC++. You can always insert assembly instructions directly into your HLL functions, etc.
MSVC++ also supports using mixed-languange -- that is using other .obj files and import them into your program. So, if you have a dozen of assembly functions and want to use them in your HLL game, get a compiler that supports mixed-language and link those .obj files into your program...


In a short comment: LEARN ASM as it will definetely make you better in programming. Use asm wherever you need it (either it's for speed or size), don't be shy to use it.. This will make you a professional programmer.  :U

[hutch--]

cheetahclaws,

Just to complete a very good answer to your question by Brent, MASM is a Microsoft tradename and they have developed it since 1981. The MASM32 project that I maintain is a project based on MASM tuned to 32 bit assembler under Windows. the course you do at school will determine what yopu have to produce and which platform you have to write it under with the choice being either 16 bit DOS or 32 bit Windows for MASM.

If you have the choice of either, 32 bit Windows is a lot more attractive in that it is technically simpler and a lot more powerful. It also has less restrictions than the older code but it has a few others that did not occur in DOS.

If you can use 32 bit code at school, the MASM32 project is pointed at people learning assembler and it has a lot of macro and library support to get the hacky things done like input and output to the console.

Do not lose great amounts of sleep over the coming 64 bit code, it will be some time before the OS is stable, the hardware will probably improve a lot and 32 bit code runs better on 64 bit hardware than on 32 bit. Current designs of 64 bit Windows sound like mixed 32/64 bit hybrids so the big advantages will not come for some time yet and it will only be in massive databases and similar unusual applications.

[carlos]

4. (First quiestion deleted...)  Will MASM32 code run on 64-bit processors?

-Thanks!

Will MASM32 code run on 64-bit processors?

Strictly speaking, no. But it's not quite so clear cut. 16-bit DOS programs will run on your 32-bit Windows which runs on a 32-bit processor. The 64-bit AMD64 chips run 32-bit programs (notably 32-bit Windows and it's programs).

-Brent

Hi cheetahclaws and Brent

A teacher of mine said once that there are NO idiot questions, only idiots that don't ask, and anyone asking a question is NOT an idiot,

Regarding Longhorn (what a name!!!) runing masm32 code, it better will, you see, masm32 is a win32 app, (even if is a console one) not a dos app, and if longhorn didn´t run win32 apps, BGates should better sell his shares in MicroSoft, before longhorn ships, why?, I don't see anyone, (idividuals and/or corporations), changin OS and Applications *At the same time * (think of the cost!!!), and if LH didnt suport Win32 they will had to, so the result? No switch to LH till there's apps, and no Apps till there is enoug LH plataforms instaled to make the porting wortwhile. the reason Win 9X/NT whas adopted so quickly was that you could run Wordperfect /Lotus123/dBase graphics in it, hadn't done so, we will still be running Windows 3.58,

Ask IBM what they learned from PS/2 !!!

Saludos
Carlos

[AeroASM]

the MASM32 project is pointed at people learning assembler

On www.masm32.com it says that "[masm32] is not designed as a beginners package".

wtf?

[MichaelW]

With Total Frankness? Yes, I'm sure.

The complete statement: "It is not designed as a beginners package and it does not have the support for beginners to learn the basic concepts about assembler." Seems reasonable to me.

[doomsday]

Hi cheetahclaws and Brent

A teacher of mine said once that there are NO idiot questions, only idiots that don't ask, and anyone asking a question is NOT an idiot,

Just to be contrary, I think there are idiot questions.  Mostly if someone asks a question(s) when they've made absolutely no effort to arrive at a solution themselves.  Thankfully we don't tend to get that kind on this board :)

Regarding Longhorn (what a name!!!) runing masm32 code, it better will, you see, masm32 is a win32 app, (even if is a console one) not a dos app, and if longhorn didn´t run win32 apps, BGates should better sell his shares in MicroSoft, before longhorn ships, why?, I don't see anyone, (idividuals and/or corporations), changin OS and Applications *At the same time * (think of the cost!!!), and if LH didnt suport Win32 they will had to, so the result? No switch to LH till there's apps, and no Apps till there is enoug LH plataforms instaled to make the porting wortwhile. the reason Win 9X/NT whas adopted so quickly was that you could run Wordperfect /Lotus123/dBase graphics in it, hadn't done so, we will still be running Windows 3.58,

Ask IBM what they learned from PS/2 !!!

Saludos
Carlos

I'm not quite sure what you're getting at here, but I didn't mean to suggest that Win64 won't, more or less, support 32-bit programs.  I don't know enough about Longhorn (kinda satanic name isn't it?) to make a definative comment, but my money says that we'll have a similar situation to what we have with running 16-bit DOS programs now.  Kinda emulated and executed at the same time.

"Whacha mean your <insert your favorite program>-32bit won't run on Longhorn.  Of course it will.  But you'll be better off buying Office-64 which will solve all of your problems including some which you don't even know you have" :)

regards,
-Brent

[carlos]

( previous quote deleted....)

I'm not quite sure what you're getting at here, but I didn't mean to suggest that Win64 won't, more or less, support 32-bit programs. I don't know enough about Longhorn (kinda satanic name isn't it?) to make a definative comment, but my money says that we'll have a similar situation to what we have with running 16-bit DOS programs now. Kinda emulated and executed at the same time.

"Whacha mean your <insert your favorite program>-32bit won't run on Longhorn. Of course it will. But you'll be better off buying Office-64 which will solve all of your problems including some which you don't even know you have" :)

regards,
-Brent

Yes I see your point. But the situation is diferent here,  DOS (16 bit apps) use a diferent programing paradigm than Windows, DOS apps had access to ALL machine resources, any program could (and DID) bypass the OS, and even the BIOS, and talk directly to the hardware,  WIN32 didn't allow this, (for it's and our protection), that's why Win32 had to "emulate and execute (a very apt methapor :U)", the DOS apps, to make sure the app had "access to the machine" without being screwed by a wild app.

Regarding Win64 there is no *need* to change the paradigm, at least *NO techincal reasons", a win32 app should run without problems, if there are compatibily problems, there will be forced by marketing presure, to force people to upgrade to "Office 64", but it could hurt them badly.

Salu2
Carlos