Targeted Uses of Assembly

[psault]

Some people claim that spending time to learn assembly is not worth the effort.  I know this to be untrue, as I am understanding my computer on a more intimate level while I study Intel architecture.  It is clear that knowing how the central processor unit works is a fundamental of assembly programming.

With the current versions of Windows, I am impressed upon that a certain level of control has been taken away from the programmer as the OS governs the accessing of hardware.  Surely this is a requirement for stability for the complex multitasking operating system.  With this being said, I wonder what the major applications of assembly are for Windows.  I have seen many examples that use, what I believe is properly termed the Windows API in this context, to create GUI type programs that work with Windows.  I am curious about what gains a programmer achieves by going about creating this type of application using assembly.  In what ways is assembly better for doing this than using something like MFC, or C# .NET?

If you are interested in programming something like a device driver, is this type of code more privileged, in terms of things like using interrupts, than code you would write for a Windows GUI app with assembly? 

Another major question I have is about programming for embedded systems.  I'd think that this type of hardware would not be running Windows, and might be something else like a 16-bit processor.  If I understand correctly, MASM is intended for use as a Windows development tool only.  Obviously a programmer would then need to use a different assembler.  In a scenario like this, would you say that it is important to understand real-address mode programming for 16-bit systems, using a lot of things like interrupts which might not be permitted on Windows?

I know that this forum is dedicated to MASM, and I am excited about learning to program with it.  Please forgive if my embedded systems question is off-topic.  I ask here because MASM is the tool I will be using for trying to learn as much about assembly as I can, and I will definitely be using it to program on the Windows platform as I learn.

~psault

[FORTRANS]

Another major question I have is about programming for embedded systems.  I'd think that this type of hardware would not be running Windows, and might be something else like a 16-bit processor.  If I understand correctly, MASM is intended for use as a Windows development tool only.  Obviously a programmer would then need to use a different assembler.  In a scenario like this, would you say that it is important to understand real-address mode programming for 16-bit systems, using a lot of things like interrupts which might not be permitted on Windows?

Hi,

   Embedded processors can be 8, 16, or 32 bits (at least).  If
an X86 embedded processor is used, like an 80186 or 80386,
then MASM would be a proper tool to use.  If the processor is
something else, then learning MASM will be something of a side
trip as the X86 is not like much of anything else.  Real mode
X86 programming over protected mode is then mostly getting
used to a different set of resources.  16-bit real mode programs
are more constrained than 32-bit programming.

   Understanding interrupts is useful, but using them is quite like
using a CALL in other languages in practice, if used to invoke a
subroutine.  They have other uses that are variations on that
theme (routines to process hardware events for example).

$0.02

Steve N.

[dedndave]

Some embedded systems available today are capable of running reduced versions of windows. Also, you do not need to run windows to take advantage of 32-bit protected mode functions. The biggest advantage in programming in assembler is speed. Embedded systems is one place where speed may be of concern, depending on your application. Another major advantage of assembler is size. Again, this may be important for your embedded system, as space is limited. Depending on what you are trying to do, a C compiler that supports in-line assembly may give you the best of both worlds. One of the biggest limitations of 16-bit code is that you are only able to directly address 1 mb of ram. I would think that a protected-mode OS is highly desirable, even if it is not windows.
- Dave

[thomas_remkus]

My experience says that people who do not understand the benefits of assembly never took the time to learn assembly and only compare their efforts to something they don't understand.

[GregL]

If I understand correctly, MASM is intended for use as a Windows development tool only.

MASM can assemble 16-bit Real Mode (DOS) code.

[donkey]

If I understand correctly, MASM is intended for use as a Windows development tool only.

MASM can assemble 16-bit Real Mode (DOS) code.

I think he was talking more about non-windows non-Microsoft OSes, yes, the MASM license excludes all non-MS operating systems. However since you were interested in embedded systems, most of the ones around now use ARM or task specific processors which have a completely different instruction set, MASM or any other x86 assembler would be incapable of generating code for them. There are a few x86 embedded systems out there but the ones I have seen usually run a proprietary RTOS, the ARM processor is much better suited to the task and since Windows Mobile is available for the ARM there is no need to compromise on compatibility.

[Mark Jones]

...what [are] the major applications of assembly for Windows...

As I see it, for Windows, assembler is still absolutely a requirement in the following three niche areas: BIOS, ROM images, and embedded x86 processors. If someone is trying to code a BIOS in C#, then there is a problem. :bg

Beyond that, use for assembler becomes more subjective. Kernel-mode device drivers and other critical system code can be written in assembler, and like was already iterated, having this knowledge of the architecture greatly helps in understanding things. How do you do a native INT 21 in C? Since what the programmer writes in assembler is what the CPU does, code can be written which is both smaller and/or faster than anything a compiler could hope to produce. Of course, this all depends on the skill of the programmer and the task at hand - threads in the "Laboratory" here generally give an idea of how typical code snippets are improved in terms of size or speed, often with orders of magnitude improvement over "optimizing" compiler output.

With the advent of packages such as MASM32, it is even possible to write full-fledged user-mode programs in assembler. This is where most of the high-level language crowd balks, shirking assembler for its "extreme difficulty" and "impossibly long source code", which of course is simply not true. MASM32 assembler for ring-3 applications combines the best of all worlds: a comprehensive code library, extensive API import library (which means many "nice" high-level-like programming features), combined with the raw power and versatility of assembler. Of course, not everyone can comprehend or enjoy such a behemoth; however those that do, seem to like it. :bg

...Another major question I have is about programming for [non-Windows] embedded systems... would you say that it is important to understand real-address mode programming for 16-bit systems, using a lot of things like interrupts which might not be permitted on Windows?...

Excellent question. Take for instance the Microchip PIC brand microcontrollers. This vendor provides an entire suite of development tools, including an IDE, compiler, and assembler specifically-tuned to their products.

The x86 architecture is fairly unique, and as such, other topologies are very different. Programming instructions for the PIC for instance, are mostly directed at hardware-level interaction (reading a pin state or voltage, performing math on data, reading or writing data to ports or pins, etc.) The lower-end PICs have only around 40 instructions, compared to the hundreds in modern x86 processors. The PIC can also perform interrupts, and programming this can be rather tricky, but similar underlying principles apply. So I would say that yes, learning some 16-bit x86 assembler certainly can't hurt.

Others have created supplemental programming languages such as JAL which is both easy and powerful. Another popular vendor is the Atmel AVR. There may be a few other posts here regarding these various products and vendors.

A word of caution: many eager people have been overwhelmed by trying to accomplish too much too quickly when it comes to learning assembler and embedded topologies. Each is a comprehensive and disciplined field in itself, and some significant electronics knowledge is also required. My advice would be, if you really want to learn to design and program embedded processors, to start off gradually, with the smallest and simplest hardware and code first, then master each aspect sequentially. There is a tremendous amount of material to cover, and if approached too quickly, it can rapidly overwhelm.

Regards,
Mark

P.S. Bert van Dam at one time had a wonderful website showcasing many advanced topics using the simple JAL language and low-end PIC microcontrollers, but it seems that he's sold all these to a publisher. Darn! His work is all top-notch though. Anyone looking for a hands-on way of getting into PICs from scratch could start here.

[psault]

Thank you all for your responses.  This has been good information for me.

I think I shall heed Mark Jones' caution about trying to learn too much too quickly.  An on-line programmer friend of mine has shared with me a saying: "More haste, less speed."  It may be a while before I know enough about assembler to be able to share ideas or suggestions.  In the mean time, I plan to pick up what I can from the discussions and my textbook exercises. 

~psault

[mitchi]

Learning assembly was my big step in the programming world. Before that, I knew some Java and printf functions taught at school and that was all. When I started learning assembly, I learned about a lot of things at the same time since assembly leads to many things , and so it took more time than I thought. But now all is good and I'm glad I didn't give up halfway and become a Python guy   :lol
x86 assembly also improved my C...