I began learning 16-bit ASM and practice 16-bit ASM programming under DOS and MASM 6.x three weeks ago. I am very impressed with ASM and the control and simplicity ASM brings to programming. 16-bit ASM is so simple. Programmers have the most flexibility in terms of program design. I enjoy ASM programming and will definitely continue learning and practicing 16-bit ASM.

As I mentioned before I am learning 16-bit ASM, not 32-bit ASM. The author of the ASM book for which I am studying from emphasizes that 32-bit ASM is not as important or as practical as 16-bit ASM. One key reason is the presence of high-level languages including C/C++, making 32-bit Windows and Linux programming much easier and quicker. I definitely agree. Yes, 32-bit ASM is powerful and gives you unparalleled control, but at the cost of design, implemetation, and debugging time.

Software technology changes so rapidly. Consider Microsoft's C#. Companies are in a race to design overly simple and extremely easy, at a cost of control limitation, programming languages. I would like to know what is the future of Assembly language and 16-bit, 32-bit, and soon 64-bit ASM programming? I am most interested in 16-bit ASM because, again, 32-bit and 64-bit ASM programming in Windows and Linux is really not worth the time and effort except for specific reasons such as hardware control.

Posted on 2002-09-20 23:38:51 by kuphryn
I would say that 16 bit, whether it's assembler or anything else is dead. Except maybe to bootstrap an OS.
32-bit is the most common now (Linux and Windows). And 64-bit is the future. It remains to be seen what are Microsoft's plans for a 64-bit version of MASM, but we'll get a 64-bit assembler some way or the other.
And about
because, again, 32-bit and 64-bit ASM programming in Windows and Linux is really not worth the time and effort except for specific reasons such as hardware control.

I don't think that's quite right. For example, you don't get any more (even ANY) hardware control on user-mode WinNT whether you use C/C++/ASM/C#/Gofer, etc.
Also, when you write correct ASM code, you get better performance in time-critical code sections (NOT API calls, or GDI or that stuff).

Posted on 2002-09-21 00:10:58 by GogetaSSJ4

You made a very good point about how recent versions of Windows give no hardware control to programs in user mode even with ASM code. I suspect that the only way to get more hardware control is to boot to pure DOS mode. In that case, how does 16-bit ASM come into effect?

Posted on 2002-09-21 00:20:42 by kuphryn

32-bit and 64-bit ASM programming in Windows and Linux is really not worth the time and effort except for specific reasons such as hardware control.

We have all heard this stuff from time to time but no-one has ever delivered the code that does it, compilers have their place as do assemblers but particularly in 32 bit operating systems like Windows, 32 bit assembler is a lot faster, simpler and easier to understand than 16 bit assembler.

It sounds like the book you are working with is out of date in the assembler area which is common with stuff aimed at the C/C++ market. Most of these authors have little experience in assembler and mislead their reader because of it.


Posted on 2002-09-21 00:24:05 by hutch--
Hi again.
If I understand your question correctly, then DOS is a 16-bit OS (sort of). So you program in 16-bit ASM/C/C++, etc. But now, programming for DOS it's just an academic thing, in my opinion it's useless except for learning purposes, of course.
If you decide to go ahead with WIN32 assembler, then you've come to the right place!!
Posted on 2002-09-21 00:48:21 by GogetaSSJ4
Yes. I plan to learning 32-bit ASM and even 64-bit ASM in the future. I want to have a strong grasp on 16-bit ASM first. I believe learning 32-bit ASM will be easier and quicker afterward.

Posted on 2002-09-21 00:58:40 by kuphryn
I unfortunately am familiar with 16 bit assembler and I am still trying to erase it from my memory. ;) I still have nightmares of normalizing segment:0ffset pairs and working with BIOS calls and writing to the video buffers, etc. Each night I wake up in a cold sweat and have to turn on my computer to make sure it's still using a a flat memory model. Phew. ;)

32 bit can be easier or harder than 16 bit depending on which level you are working with. From an OS standpoint it can be a royal pain in the neck. Switching into PMode and setting up the IDT and the segment registers and all of that fluff can get mighty complicated. However, from an application's point of view it's much easier than 16 bit. No more weird memory addressing and you have various APIs at your disposal to make life much easier. I think you should forget working in 16 bit and come to the dark side. :grin:
Posted on 2002-09-21 03:04:52 by iblis
You have probably heard about the new AMD CPU, Hammer (from what I've dug up they're going to call the two first CPU-models Opteron and ClawHammer).
If it does work then this is the next step, from 32-bit to 64-bit; Just like from 16-bit to 32-bit (16-bit still exists, backwards compatibllity it's called; good thing :) ). This is IMO very good since the current 64-bit CPUs use another instruction set (or at least partially), thus making it next to impossible to run 32-bits app on them, and we want to be able to run our "old" games in the future (think playing UT2003 will soon be called nostallgia).
If the pricing is right for an complete AMD-system using this new technology I will most likeley buy myself one and start do 64-bit apps (and 32-apps too of course). But today I don't bother to read the 64-bit docs, since they might not be valid for the Hammer-CPUs (possible except for the ones on AMDs site) and it might take sometime before the price has fallen enought.

If AMD does things right (pricing, advetisment, etc) then they have a big potential to rule parts of the future CPU market like Intel does today. If the new CPUs are what they say, then 16-bit apps/OSes might be forgotten. Just like the even more obsolete* CPUs and OSes, wasn't CP/M an 8-bit OS? (Win 3.11 is already beginning to fade away into the history-books)

* Obsolete in the term of ordinary-mortal-ppls desktop-computers and (super) servers, not in terms of calculators (ok, thats 1-bit overkill...)

(Strange, I didn't push the submit button; I see this thread posted after pushing teh Preview button) :confused:

Deleted the false post. Strange, but I must have pushed wrong button somehow, how else would it have happened?
Posted on 2002-09-21 11:51:24 by scientica
Okay. Thanks.

I read many responses and have found the majority of them seem to convey one point.

- 16-bit ASM have little use in a 32-bit environment and 64-bit environment. Even under a high-level project using C/C++, programmers rarely use 32-bit ASM, much less 16-bit ASM. In general, the responses I have seen seem to convey that developers prefer high-level languages. I do not agree that we should rely solely on contemporary high-level compilers. There are times when ASM will definitely provide more control. For example, consider direct communication with hardware devices. How do you communicate with hardware devices without 16-bit ASM?

All the responses about advancement in C/C++ compilers got me thinking about the future of programming. We are into programming be it games, applications, or other software technology. With the advancement in programming technology, one day the computer will be able to program itself. Now that is amazing, but scary too. For example, what if the programmer wanted a code a certain way, but the compiler felt that the code is more optimized another way?

Posted on 2002-09-21 11:54:28 by kuphryn

one day the computer will be able to program itself.


what if the programmer wanted a code a certain way, but the compiler felt that the code is more optimized another way?

Well, that is exaclty what M$ Window$ does (=make sure the program crashes and destoyrs all important data for you)... :grin: :grin: :grin:
Posted on 2002-09-21 13:39:28 by scientica
16-bit code is harder than 32-bit?!?! NOPE not to me. I find 16-bit code VERY easy, almost as easy as 32-bit code, but 16-bit code is slower as segment overrides slow CPU down and my game engine (old 2D game) does alot of it. Probably will run very slow on 386/486 CPU. I unfortunately have used 16-bit ASM code for a learning tool. Using NASM then PASS32 then TASM/TLINK. I also know how to program the OPL FM synthesizer chips directly (OPL2 only, dont know OPL2 very well). I didnt know 16-bit code was hard!! At first I thought 32-bit code was hard and tedious!! :confused:
Posted on 2002-09-21 20:47:58 by x86asm
As a newbie, is it still worth learning 32-bit Assembly now? Because I think that 64-bit Asm will be a lot different.
Posted on 2002-10-05 01:18:06 by nyook
nyook and kuphryn,

x86 architecture has been with us for a long time and for that reason alone, it will be with us for some time yet. 64 bit processors have been around since before the 90s but cost and other historical reasons will ensure that they are not freely available on the major market for years to come.

IA64 is already up and running but has a very small user base because of the cost and design and there are already others in the 64 bit market. AMD are playing with the idea but under current economic conditions, they may not even survive in the longer term.

Current Intel and AMD processors already support 64 bit and 128 bit operations (MMX & SIMD) and they are already mainstream.

Going back to the past is a waste of time, 16 bit assembler is slow and far less powerful than the current 32 bit assembler and to make the point, it is not properly compatible with 32 bit code so unless you are going to write specifically for 16 bit DOS or 16 bit windows, the code is no use to you.

It used to be defects in older compilers that made programmers use assembler for hardware access but most C compilers have an inline assembler and it has no advantage in terms of hardware access over the normal compiler. Assembler is generally used for performance in 32 bit code, not "hack" OS access.

Algorithm design and execution is where the C programmer has use of assembler so knowing how to write a module in an assembler and linking it into a compiled program is where you will find the best use for assembler with a high level language.


Posted on 2002-10-05 04:56:10 by hutch--
Okay. Thanks.

I am seriously looking into learning 32-bit ASM. I would like to know what is the best book for learning 32-bit ASM?

Lastly, what do software engineers use most to develep device drivers?

Posted on 2002-10-05 10:05:57 by kuphryn
I think they use low-level C, with very little inline assembly. I would say in a perfect world graphics card drivers would be written in assembly, but I dont think that happens. It would be cool to make my games run even faster :p:tongue:
Posted on 2002-10-05 10:08:00 by x86asm
Isn't asm the rule not the exception for drivers? Especially graphics drivers.
Posted on 2002-10-05 13:12:43 by drhowarddrfine
I really dont know, but I hear that they use C nowadays, for GFX drivers I'm pretty sure we wouldnt be able to run games like UT2003 if they didnt use assembly. The overhead probably would be too much.
Posted on 2002-10-05 15:43:21 by x86asm
I think that the gfx drivers are written in C, because the code is easier to maintain.
But the critical sections of an game engine are probably written in assembly.
Because I think it's more efficient to speed up the complex computations rather than some gfx driver interface.
Posted on 2002-10-05 15:49:12 by nyook
Ya but you see its also important to minimize the CPU overhead of interfacing with the graphics co-processor. You dont want the CPU spend 2 million clock cycles just instructing the GPU to plot a vertex (exaggeration :tongue: )
Posted on 2002-10-05 16:38:40 by x86asm