CS401 GDB Solution June 2012
Solution:
Assembly language, of course, developed a very bad reputation throughout the 1990s. Advances in compiler technology, improved CPU performance, and the "software crisis" all conspired to suggest that assembly language was a "dead" language that was no longer needed. As assembly language was a bit more difficult to learn than traditional high-level programming languages, students (and instructors!) gladly embraced this brave new high-level world, abandoning difficult-to-learn assembly in favor of higher and higher level languages.
The only problem with the demise of assembly language is that as its popularity waned, so did the percentage of programmers who understood the low-level ramifications of the code they were writing. Those programmers who were claiming that assembly language was dead already knew how to think in assembly language and how to apply that low-level thinking to their high-level code; in effect, enjoying the benefits of assembly language while writing high-level language code. However, as new programmers worked their way into the system, without the benefits of having written several applications in assembly, the efficiency of software applications began to decline.
Though it would be foolish to start claiming that programmers should begin writing commercial applications in assembly language, it is clear today that the demise of assembly language's popularity has had a big impact on the efficiency of modern software. To reverse this trend, one of two things must happen: programmers must once again begin studying assembly language, or they must somehow pick up this low-level programming knowledge some other way.
Learning assembly language still remains the best way to learn the basic organization of the underlying machine. Those programmers who take the effort to master assembly language become some of the very best high-level language programmers around. Their ability to choose appropriate high-level constructs to produce efficient code, their ability to read disassembled high-level language code and detect heinous bugs in a system, and their understanding of how the whole system operates elevates them to near legendary status among their peers. These are the programmers everyone goes to when they have questions how to implement something. These are the engineers who garner the respect of everyone around them. They are the ones other programmers want to emulate. These are the programmers who write great code.
If knowing assembly language helps make programmers great, an obvious question is "Why don't more programmers learn assembly language?" Part of the problem is prejudice: many college and university instructors that teach assembly programming begin their course with a statement like, "No one really needs to know this stuff, and you'll never use it, but it is required by this program so we've got to struggle through the next several weeks studying this material." After four years of this type of attitude from their instructors, it's no surprise that students really want nothing whatsoever at all to do with assembly language programming.
Still, once it becomes obvious to a coder that the truly great programmers are the ones who've mastered assembly language programming, you might ask why more programmers don't pick up this valuable knowledge. The only problem is that, traditionally, most programmers have found it difficult to master assembly language. Assembly is radically different than most high-level languages, so learning assembly language is almost as much work as learning programming from scratch.
To someone attempting to learn assembly, it often seems as though none of their past programming experience is of any help. All too often, an engineer learning assembly becomes frustrated with the fact that they know how to achieve a goal in a high-level language but they cannot figure out how to achieve the same thing in assembly. For many programmers, switching from "thinking in a high-level language" to "thinking in an assembly language" becomes an insurmountable problem.
As an instructor teaching assembly language for over a decade at the University of California, I was quite aware of the problems students have making the transition from the high-level programming paradigm to the low-level programming paradigm.
In the early 1990s, Microsoft provided a solution with the introduction of the Microsoft Macro Assembler (MASM) v6.0 - the inclusion of high-level control structures in an assembly language translator. While these new statements are definitely not true assembly language, they do provide a nice transition path from traditional, imperative, high-level programming languages to assembly. A programmer can continue to use statements like IF, WHILE, and FOR while learning other aspects of assembly language programs. This lets the programmer learn assembly language programming in graduated steps rather than having to make the plunge all at once.
Equally, for IBM's High-Level Assembler (HLASM) various macro libraries that implement the same functionality have been around for many years.
Another Solution
Most high level languages are very slow in comparison to ASM as has already been stated but this is mainly due to the multiple levels of abstraction that separates native binary from the HL language in question.
if you know assembly language, stick with it, it is THE BEST, the compiler does not mess with your code, it does not change any of the ASM code, it simply directly, converts each instruction to machine code, and that’s it. It wont check for extensive errros like VB or others, such as ‘runtime error file not found’ – none of that because the compiler has not messed with your code.
Assembler is still a high level programming language and is the next step up in making code easier to understand or human readable, it is still converted to machine language in order for the computer to understand it which is the lowest level.
Solution:
Assembly language, of course, developed a very bad reputation throughout the 1990s. Advances in compiler technology, improved CPU performance, and the "software crisis" all conspired to suggest that assembly language was a "dead" language that was no longer needed. As assembly language was a bit more difficult to learn than traditional high-level programming languages, students (and instructors!) gladly embraced this brave new high-level world, abandoning difficult-to-learn assembly in favor of higher and higher level languages.
The only problem with the demise of assembly language is that as its popularity waned, so did the percentage of programmers who understood the low-level ramifications of the code they were writing. Those programmers who were claiming that assembly language was dead already knew how to think in assembly language and how to apply that low-level thinking to their high-level code; in effect, enjoying the benefits of assembly language while writing high-level language code. However, as new programmers worked their way into the system, without the benefits of having written several applications in assembly, the efficiency of software applications began to decline.
Though it would be foolish to start claiming that programmers should begin writing commercial applications in assembly language, it is clear today that the demise of assembly language's popularity has had a big impact on the efficiency of modern software. To reverse this trend, one of two things must happen: programmers must once again begin studying assembly language, or they must somehow pick up this low-level programming knowledge some other way.
Learning assembly language still remains the best way to learn the basic organization of the underlying machine. Those programmers who take the effort to master assembly language become some of the very best high-level language programmers around. Their ability to choose appropriate high-level constructs to produce efficient code, their ability to read disassembled high-level language code and detect heinous bugs in a system, and their understanding of how the whole system operates elevates them to near legendary status among their peers. These are the programmers everyone goes to when they have questions how to implement something. These are the engineers who garner the respect of everyone around them. They are the ones other programmers want to emulate. These are the programmers who write great code.
If knowing assembly language helps make programmers great, an obvious question is "Why don't more programmers learn assembly language?" Part of the problem is prejudice: many college and university instructors that teach assembly programming begin their course with a statement like, "No one really needs to know this stuff, and you'll never use it, but it is required by this program so we've got to struggle through the next several weeks studying this material." After four years of this type of attitude from their instructors, it's no surprise that students really want nothing whatsoever at all to do with assembly language programming.
Still, once it becomes obvious to a coder that the truly great programmers are the ones who've mastered assembly language programming, you might ask why more programmers don't pick up this valuable knowledge. The only problem is that, traditionally, most programmers have found it difficult to master assembly language. Assembly is radically different than most high-level languages, so learning assembly language is almost as much work as learning programming from scratch.
To someone attempting to learn assembly, it often seems as though none of their past programming experience is of any help. All too often, an engineer learning assembly becomes frustrated with the fact that they know how to achieve a goal in a high-level language but they cannot figure out how to achieve the same thing in assembly. For many programmers, switching from "thinking in a high-level language" to "thinking in an assembly language" becomes an insurmountable problem.
As an instructor teaching assembly language for over a decade at the University of California, I was quite aware of the problems students have making the transition from the high-level programming paradigm to the low-level programming paradigm.
In the early 1990s, Microsoft provided a solution with the introduction of the Microsoft Macro Assembler (MASM) v6.0 - the inclusion of high-level control structures in an assembly language translator. While these new statements are definitely not true assembly language, they do provide a nice transition path from traditional, imperative, high-level programming languages to assembly. A programmer can continue to use statements like IF, WHILE, and FOR while learning other aspects of assembly language programs. This lets the programmer learn assembly language programming in graduated steps rather than having to make the plunge all at once.
Equally, for IBM's High-Level Assembler (HLASM) various macro libraries that implement the same functionality have been around for many years.
Another Solution
Assembly language is very useful for routines that require high speed and highly optimized code. It is also required for Boot Loaders (i.e. LILO, GRUB, etc…) and Operating Systems.
Most high level languages are very slow in comparison to ASM as has already been stated but this is mainly due to the multiple levels of abstraction that separates native binary from the HL language in question.
High Level languages have HUGE run time dependencies, ASM can be optimized to have none whatsoever which is why they are indeed used in bootstrapping and OS installers, it lets you run a program on a completely blank computer.
The other benefits of knowing ASM include gaining a much deeper understanding of how a computer works at the lowest level. Thi definitely affects the way you write code in HLL too.
if you know assembly language, stick with it, it is THE BEST, the compiler does not mess with your code, it does not change any of the ASM code, it simply directly, converts each instruction to machine code, and that’s it. It wont check for extensive errros like VB or others, such as ‘runtime error file not found’ – none of that because the compiler has not messed with your code.
Other advantages…
The programmer has COMPLETE control over how the program works, unlike other high level languages.
The programmer has COMPLETE control over how the program works, unlike other high level languages.
Final advantage, file zise – a program which only displays a message box then quits (including the windows DLLs)
ASM: 3kb
VB6: 16kb
VB6: 16kb
^ that’s a huge difference
Assembly Language is the closest abstract to machine code. In many cases, you might have a processor directive say 0010101001010101010111111111000111, in assembly – instead of remembering all those 1, an 0′s you might have to remember MOV es,ax
Assembly Language is the closest abstract to machine code. In many cases, you might have a processor directive say 0010101001010101010111111111000111, in assembly – instead of remembering all those 1, an 0′s you might have to remember MOV es,ax
(I have no idea, BTW, what that binary sequence means!)
You then use an assembler to convert your instructions into machine code – with no interference or optimization done by the assembler.
Assembler is still a high level programming language and is the next step up in making code easier to understand or human readable, it is still converted to machine language in order for the computer to understand it which is the lowest level.
It’s quicker to develop applications using the latest higher level language tools and the differences in performance these days is hard to notice as most machines tote enough power it doesn’t make much of a real difference.
But in terms of speed, efficiency can easily create your own programming language and re-invent the wheel, and portability assembler stands out a bit.
The downside is there’s a lot missing in terms of all the latest tools and features for using syntax for simplicity and rapid application development.
The programs are small, lightweight, and don’t require bulky run times which need to be downloaded, plus you develop totally for free.
Size and speed isn’t so much an issue as time, money, and ease of development these days, plus, people aren’t as deeply educated and focus is only on working with the IDE more so than how the internal code itself works, this develops false positives and leaves many security exploit possibilities open in the higher level languages.
A big comparison would be this, let’s say you needed an application with moderate to complicated functionality complete for commercial business application for a client, you aren’t well skilled in assembler but could popup something in short amount of time in higher level language, if it takes a few to several years to complete in assembler and you only have a few days to a week your best bet is higher level language to get it done now and get paid.
Either way, it’s all about picking the language that you’re comfortable working with and can understand, don’t be afraid to try something new and keep developing!
