I am very interested in learning assembly language but I am not sure of the
how marketable I will be as a programmer.  With all the hype about Java,
C++, and the various scripting languages for the web, I am not sure where
assembly language fits in.  Does anyone have any serious input and advice
for me.

Regards,
Joe

> I am very interested in learning assembly language but I am not sure of
the
> how marketable I will be as a programmer.  With all the hype about Java,
> C++, and the various scripting languages for the web, I am not sure where
> assembly language fits in.  Does anyone have any serious input and advice

1. Consider the following: you have to write a program that beeps speaker
under Win9x. How would you do this with C++ or Java (or any other HLL)?
2. Consider another: you have to fix a bug in your program but debugging in
source mode doesn't help you. What shall you do without knowing assembler?
3. Web is NOT the only thing applications a written for. Believe me.
4. Another consideration: you have to optimize a small piece of code that
executes millions and billions times, so every cycle counts. NONE of all the
compilers will do this better than you.
5. How can you even understand deeply what CPU does when your program
executes without knowing assembly?
etc...

Assembler is used rare for writing complete programs. It is used mostly as
inline assembler, for writing small and fast object libraries and for
debugging purposes. You should definitely learn it.

Ivan

"Ivan Korotkov" <korotkov1@ztel.ru> wrote

>> I am very interested in learning assembly language but I am not sure of
>the
>> how marketable I will be as a programmer.  With all the hype about Java,
>> C++, and the various scripting languages for the web, I am not sure where
>> assembly language fits in.  Does anyone have any serious input and advice
>
>1. Consider the following: you have to write a program that beeps speaker
>under Win9x. How would you do this with C++ or Java (or any other HLL)?
Why would you want to do that? Anyway, most HLL compilers come with a
library that will, amongst many other things, allow you to make a
speaker beep.
>2. Consider another: you have to fix a bug in your program but debugging in
>source mode doesn't help you. What shall you do without knowing assembler?
Learn the HLL well and find your bug. There is no point in learning
assembly language just for debugging. If you look at well-written
code, you _know_ what it does, you won't have to look at assembly.
Locating a faulty HLL instruction is quite easy in a source-mode
debugger.
>3. Web is NOT the only thing applications a written for. Believe me.
But the most lucrative one. Believe me. Unless you program
uControllers or pieces of code working close to the hardware, you do
not need assembly language (but even here, you can get around assembly
language... most drivers and even some BIOSen are nowadays mostly
written in C. 
>4. Another consideration: you have to optimize a small piece of code that
>executes millions and billions times, so every cycle counts. NONE of all the
>compilers will do this better than you.
But thousands of unemployed assembly specialists will.
>5. How can you even understand deeply what CPU does when your program
>executes without knowing assembly?
Why would you want to?
>etc...
I'd like to hear more arguments...
>
>Assembler is used rare for writing complete programs. It is used mostly as
>inline assembler, for writing small and fast object libraries and for
>debugging purposes. You should definitely learn it.
Don't waste your time with it. First learn Java and/or C++. Then a
bunch of scripting languages. After that, try to get married and have
3 or 4 children. And then, if you still have the time to learn 
assembly language, do it, but do not wonder if no one asks for it. 

Lukas Reck

On Sat, 13 Dec 2003 21:21:46 +0000 (UTC)
Lukas Reck <luqash@gmx.de> wrote:

:Learn the HLL well and find your bug. There is no point in learning
:assembly language just for debugging. If you look at well-written
:code, you _know_ what it does, you won't have to look at assembly.
:Locating a faulty HLL instruction is quite easy in a source-mode
:debugger.

Until a couple of years ago, I used a closed source shareware mail client
program, which which was written in C. The program had excellent function,
but only so-so reliability. If a user identified a function which
consistently failed under some given circumstances, the author was very
responsive, and usually had a fixed version available within a few days.

However, when the program crashed for no obvious reason, the author didn't
even bother to look at the error reports which the users submitted, because
the machine state at the point of failure, as reported by the OS, meant
nothing to him. As a result, the bugs never got fixed, and many of the
users switched to other programs.

If the author had known even the basics of assembly language programming,
his ability to find and fix those bugs would have been greatly enhanced.

-- Chuck

"Lukas Reck" <luqash@gmx.de> wrote in message
news:c2umtvo6bmr5e2coh1390ovuf4ago612dg@4ax.com...
> "Ivan Korotkov" <korotkov1@ztel.ru> wrote
>
> >> I am very interested in learning assembly language but I am not sure of
> >the
> >> how marketable I will be as a programmer.  With all the hype about
Java,
> >> C++, and the various scripting languages for the web, I am not sure
where
> >> assembly language fits in.  Does anyone have any serious input and
advice
> >
> >1. Consider the following: you have to write a program that beeps speaker
> >under Win9x. How would you do this with C++ or Java (or any other HLL)?
> Why would you want to do that? Anyway, most HLL compilers come with a
> library that will, amongst many other things, allow you to make a
> speaker beep.

And those libraries are written by people who know assembly...

> >2. Consider another: you have to fix a bug in your program but debugging
in
> >source mode doesn't help you. What shall you do without knowing
assembler?
> Learn the HLL well and find your bug. There is no point in learning
> assembly language just for debugging. If you look at well-written
> code, you _know_ what it does, you won't have to look at assembly.
> Locating a faulty HLL instruction is quite easy in a source-mode
> debugger.

void (* foo)(void) = NULL;

foo();

Find bugs like this with a source-level debugger. This is an overly
simplified case, but I have had to debug this scenario a number of times.
The source-level debugger doesn't help at all. Quite a few languages do not
suffer this problem, but C/C++ do, and C/C++ are the most popular.

With assembly I have written a debugger that makes this trivial, but
moreover I can correct the fault and let the application continue executing.
I've never heard of a C/C++ debugger with this capability, although similar
functionality is offered from hardware and from interpreted languages. More
recently Visual C++ has added functionality like this, but it is unreliable.

Furthermore, what do you do if you encounter an optimizer bug? With
knowledge of assembly, I can examine the compiler's output and verify that
the bug is in the optimizer. There is a chance, then, that it will be fixed,
and I can work around it by disabling optimization for that particular file.

> >3. Web is NOT the only thing applications a written for. Believe me.
> But the most lucrative one. Believe me. Unless you program
> uControllers or pieces of code working close to the hardware, you do
> not need assembly language (but even here, you can get around assembly
> language... most drivers and even some BIOSen are nowadays mostly
> written in C.

As in the recent post "Examples of assembly usage in popular software", many
pieces of software are not written exclusively in C. C/C++ and other HLLs
are sufficient for a large amount of code, but compilers cannot completely
replace the assembly language programmer.

Web programming used to be lucrative. Nowadays there are many people who
know HTML, JavaScript, DHTML, ASP, Flash, and the vast array of web-based
tools that have sprouted up. There is not nearly as much demand for these
skills as there was in the past.

> >4. Another consideration: you have to optimize a small piece of code that
> >executes millions and billions times, so every cycle counts. NONE of all
the
> >compilers will do this better than you.
> But thousands of unemployed assembly specialists will.

Not very true. Recently some CS students at my school were complaining about
their lack of assembly knowledge after getting into the field. Here is a
brief comment made by one of them:

"I recently had the occasion to apply for a software engineering position
with a computer game company.  Within an hour or so I received an
acknowledgement back from the corporate HR rep, asking that I complete an
enclosed programming evaluation.  Yup, you guessed it, a take-home exam!
While I don't intend to give away the specifics, I can tell you that two of
the questions requested that I write optimized C code for two different
programs."

There are more niches for this sort of knowledge than you would think.
Embedded systems suffer the worst: they're always equipped with underpowered
CPUs and small memories.

Compilers, operating systems, and device drivers also require architectural
knowledge. They are still written in C, but the people who work on them know
assembly.

Also, I don't know of any general-purpose language that has primitives for
atomic compare-and-swap, atomic exchange, or atomic bit-test-and-set.

> >5. How can you even understand deeply what CPU does when your program
> >executes without knowing assembly?
> Why would you want to?
<snip>

This is just another variation of the infamous question students ask, "Why
do I have to take X in my curriculum?" The answer is always the same,
"Because you need to have a broad understanding of the world in order to
solve new problems." There isn't any single solution to a programming
problem, and understanding why certain solutions are better than others is
an advantage.

Particularly with recent events, security is a very hot field, and it has
many practical applications for assembly programmers. Several of the
projects that we have at work involve the use of assembly in
security-related applications. One tool helps us test the security of DRM
systems. Another involves locating exploitable buffer overruns in machine
code. There are quite a few novel and useful things you can do with
knowledge of assembly.

-Matt

Read "The Great Debate" on Webster:
http://webster.cs.ucr.edu.
Specifically,
http://webster.cs.ucr.edu/Page_asm/GreatDebate/GreatDebate.html
Cheers,
Randy Hyde

"JAB" <jab_1948@hotmail.com> wrote in message news:7ZWdnc_43dmYsUaiRVn-jg@comcast.com...
> I am very interested in learning assembly language but I am not sure of the
> how marketable I will be as a programmer.  With all the hype about Java,
> C++, and the various scripting languages for the web, I am not sure where
> assembly language fits in.  Does anyone have any serious input and advice
> for me.
>
> Regards,
> Joe
>
>
>
>
>

Randall Hyde wrote:

> Read "The Great Debate" on Webster:
> http://webster.cs.ucr.edu.
> Specifically,
> http://webster.cs.ucr.edu/Page_asm/GreatDebate/GreatDebate.html
> Cheers,
> Randy Hyde

>From the essay on speed, you say:
 "Programmers who feel that all they have to do is wait a few years for
hardware technology to catch up with their software forget that three years
down the road they will be writing software that requires the machines to
be faster still."
        It seems that the "great debate" would not exist if programmers had been
programming for the next generation machines.  There would be nothing to
discuss or debate about programmer efficiency, all would be settled
beforehand by the wonderful insight shared among programmers, developers
and machine architects. 
        Rather than assume that a programmers job is to beat the machine by means
of compilers, while considering the rather dubious distinction between
"response time" and "overhead", it would be more reasonable to suggest that
it is all a question of the right algorithm for the job, and since
algorithm improvement depends entirely on a more versatile environment,
nothing can beat assembly.  "Response time" and "overhead" both refer to
the same thing when optimizing an algorithm.
 

-- 
http://www.costarricense.cr/pagina/ernobe

On Sat, 13 Dec 2003 21:21:46 +0000 (UTC) wrote Lukas Reck <luqash@gmx.de> in
comp.lang.asm.x86 with <c2umtvo6bmr5e2coh1390ovuf4ago612dg@4ax.com>

>>1. Consider the following: you have to write a program that beeps speaker
>>under Win9x. How would you do this with C++ or Java (or any other HLL)?
>Why would you want to do that? Anyway, most HLL compilers come with a
>library that will, amongst many other things, allow you to make a
>speaker beep.

And where does such a lib come from? It doesn't emerge by itself, somebody has
to write it.

>Learn the HLL well and find your bug. There is no point in learning
>assembly language just for debugging. If you look at well-written

Believe me there is. I found several bugs in assembly code genenerated by
Visual Studio. The code was perfectly ok in C but the generated assembly code
was simply wrong. Of course I could have rearranged the C code and the it
might have worked, but I would never have known what the actual problem was.
And I found a compileroption which I turned off and the code was correct after
that.

>code, you _know_ what it does, you won't have to look at assembly.
>Locating a faulty HLL instruction is quite easy in a source-mode
>debugger.

Not always. And with a good understanding of the machine it is usually much
easier. It is no coincidence that most beginners have problems with pointers.
In ASM this is a naturally thing to learn.

>But thousands of unemployed assembly specialists will.

And if nobody learns ASM anymore where are the "thousands of unemployed
assmebly specialists" then? :)

I wouldn't recommend learning ASM solely as a career decision, but is is
surely not wrong to learn it anyway.

>>5. How can you even understand deeply what CPU does when your program
>>executes without knowing assembly?
>Why would you want to?

Because it somtimes is neccessary. Of course your average hello world will
work without problem, but I know many programmers who have no clue as to why
their code works in some circumstances. A comment like this is not so uncommon
"Don't touch this code it will break otherwise."

-- 
Gerhard Gruber
Maintainer of
SoftICE for Linux - http://sourceforge.net/projects/pice
Fast application launcher - http://sourceforge.net/projects/launchmenu

Lukas Reck wrote:
> "Ivan Korotkov" <korotkov1@ztel.ru> wrote
[...]
>> 2. Consider another: you have to fix a bug in your program but
>> debugging in source mode doesn't help you. What shall you do without
>> knowing assembler?
>
> Learn the HLL well and find your bug. There is no point in learning
> assembly language just for debugging. If you look at well-written
> code, you _know_ what it does, you won't have to look at assembly.
> Locating a faulty HLL instruction is quite easy in a source-mode
> debugger.

Trouble is that there's this little niggly thing called compiler bugs :)
I've just spent the last 4 hours trying to reproduce an interesting bug. It
goes something like this:

  unsigned int a, b, c;
  // some stuff
  if (a > b)
  {
    if (a - b > c)
    {
      // Do something
    }
  }

Now, the interesting part is that this doesn't work? Why? Essentially the
compiler tweaking the conditional to (a > c + b), which then overflowed on
c+b, causing the expression to be false when it really should be true:
  (0xFFFFFFFF - 0x80000000 > $80000000)
evaluates as
  (0x7FFFFFFF > $80000000)
which is false. However
  (0xFFFFFFFF > $80000000 + 0x80000000)
evaluates as
  (0xFFFFFFFF > 0)
which is true. There is no way to catch this in the HLL debugger. You can
evaluate both sides, and the whole expression, and it will come out right.
Except the code won't do what it should when it's actually run. There's no
way to figure out what is actually going on without knowing assembler.

[...]
> I'd like to hear more arguments...

Who writes the compilers? What about the code in your OS? And graphic card
drivers? And game engines? All of these require an extensive knowledge of
assembler and knowledge of how a computer actually runs your programs. Sure,
it's not a huge market, but it includes some of the most interesting areas
of programming. I'd rather be coding OS's than strapping a PHP front-end
onto a financial package, regardless of the pay.

[...]
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :)
Add michael@ to emboss.co.nz - My inbox is always open

Ivan Korotkov wrote:
> 1. you have to write a program that beeps speaker under Win9x.
> How would you do this with C++ or Java?

#include <iostream>

int main()
{
  cout << '\a';
  return 0;
}

should work on every platform where a C++ compiler is available.

:-)

"ernobe" <ernobe@yahoo.com> wrote in message news:brgiff$366o0$1@ID-82761.news.uni-berlin.de...
>         Rather than assume that a programmers job is to beat the machine by means
> of compilers, while considering the rather dubious distinction between
> "response time" and "overhead", it would be more reasonable to suggest that
> it is all a question of the right algorithm for the job, and since
> algorithm improvement depends entirely on a more versatile environment,
> nothing can beat assembly.  "Response time" and "overhead" both refer to
> the same thing when optimizing an algorithm.

See the reponse over in alt.lang.asm...
Cheers,
Randy Hyde

> > 1. you have to write a program that beeps speaker under Win9x.
> > How would you do this with C++ or Java?
>
> #include <iostream>
>
> int main()
> {
>   cout << '\a';
>   return 0;
> }
>
> should work on every platform where a C++ compiler is available.

Play the beginning of the Beethoven's 5th with this, please. :)
I meant playing DIFFERENT tones. On WinNT, you can use Beep(Freq, Dur)
function. But how about Win98?

Ivan

> Why would you want to do that? Anyway, most HLL compilers come with a
> library that will, amongst many other things, allow you to make a
> speaker beep.

Week argument. In assembly, you will do this in five minutes and in ten
lines rather then searching for this library. But looking through MSDN, I
didn't find any library function that produces various speaker tones at all.
Only beep() in different variations, but this produces a predefined tone.

> >2. Consider another: you have to fix a bug in your program but debugging
in
> >source mode doesn't help you. What shall you do without knowing
assembler?
> Learn the HLL well and find your bug. There is no point in learning
> assembly language just for debugging. If you look at well-written
> code, you _know_ what it does, you won't have to look at assembly.
> Locating a faulty HLL instruction is quite easy in a source-mode
> debugger.

Recently, I've written a VD driver for playing with service descriptor
table. It
had a *small* bug, which lead me to BSOD again and again. The bug was that I
had to declare KeServiceDescriptorTable manually (it is not in ntddk.h) and
I and the compiler interpreted it a little bit differently. Only looking at
the assembly listing helped me to solve a problem. But, of course, if one is
writing nothing except javascripts for a lucrative thing called Web, then...

> >3. Web is NOT the only thing applications a written for. Believe me.
> But the most lucrative one. Believe me. Unless you program
> uControllers or pieces of code working close to the hardware, you do
> not need assembly language (but even here, you can get around assembly
> language... most drivers and even some BIOSen are nowadays mostly
> written in C.

But their authors still have to understand assembler well.

> >4. Another consideration: you have to optimize a small piece of code that
> >executes millions and billions times, so every cycle counts. NONE of all
the
> >compilers will do this better than you.
> But thousands of unemployed assembly specialists will.

Knowledge of assembly is only an addition to your general programming
knoweldge, not the main one.

> Don't waste your time with it. First learn Java and/or C++. Then a
> bunch of scripting languages. After that, try to get married and have
> 3 or 4 children. And then, if you still have the time to learn
> assembly language, do it, but do not wonder if no one asks for it.

Learning assembly language took about half a year for me as early as I was a
schoolboy.

Ivan

"Shill" <devnull@kma.eu.org> wrote in message news:3fdcb7dd$0$1177$636a55ce@news.free.fr...
> Ivan Korotkov wrote:
> > 1. you have to write a program that beeps speaker under Win9x.
> > How would you do this with C++ or Java?
>
> #include <iostream>
>
> int main()
> {
>   cout << '\a';
>   return 0;
> }
>
> should work on every platform where a C++ compiler is available.
>

Please! No one post this code to comp.lang.c++. The last
thing we need right now is another example of the thread
"The World's Worst Hello World Program" running through
this newsgroup :-)

(Hint: "true" C++'s can find a lot of things wrong with the code
above; at least main returns an integer and there is a semicolon
after the expression beginning with "cout" :-)  ).
Cheers,
Randy Hyde

Randall Hyde wrote:

> Shill wrote:
> 
>>#include <iostream>
>>
>>int main()
>>{
>>  cout << '\a';
>>  return 0;
>>}
>>
>>should work on every platform where a C++ compiler is available.
> 
> Please! No one post this code to comp.lang.c++. The last
> thing we need right now is another example of the thread
> "The World's Worst Hello World Program" running through
> this newsgroup :-)
> 
> (Hint: "true" C++'s can find a lot of things wrong with the code
> above; at least main returns an integer and there is a semicolon
> after the expression beginning with "cout" :-)  ).

#include <iostream>

int main()
{
   std::cout << "\a\n";
   return 0;
}

I forgot to specify the namespace where cout is defined (I usually 
write "using namespace std;" but it seems I left it out). Also, some 
systems might ignore a line which does not end with newline. Aside 
from these issues, I can't see how you can claim there are "a lot of 
things wrong" with my code.

Unless you were kidding... I cannot quite tell.

BTW, I did post to comp.lang.c++ and got several helpful answers ;-)

"Grumble" <invalid@kma.eu.org> wrote in message news:brpka0$9bq$1@news-rocq.inria.fr...
>
> Unless you were kidding... I cannot quite tell.
>
> BTW, I did post to comp.lang.c++ and got several helpful answers ;-)

Check out the thread "World's Worst 'Hello World' Program" from
alt.lang.asm and comp.lang.c++ to see how things had gone awry.
This isn't the appropriate place to discuss C++, but the newline was
definitely an issue I remembered when I saw your example.
In any case, it's already been beaten to death, no need to repeat
that here (and, unlike "The_Sage", you're probably willing accept
a few minor blemishes and suggestions in the code, which would
lead to a speedy conclusion of the thread).
Cheers,
Randy Hyde
P.S. I was kidding; half-way. One only had to be subjected to the
insanity of that thread only once to be severely damaged for life... :-)

On Thu, 18 Dec 2003 05:08:17 +0000 (UTC), "Randall Hyde"
<randyhyde@earthlink.net> wrote:

[...]

>P.S. I was kidding; half-way. One only had to be subjected to the
>insanity of that thread only once to be severely damaged for life... :-)

LOL!  And people wonder why we need therapists... <g>

Jeff

http://www.jefftturner.com