Why people perceive ASM to be hard to read


hutch-- wrote:
> Randy,
>
> Its much the same comment as I made to Robert, horses for courses,
> there is no point setting up the synchronisation suitable for an apache
> web server to do someting as trivial as shelling to another
> application.

Here's the code I use for "HowLong" synchronization:

w.WaitForSingleObject
(
pi.hProcess,
w.INFINITE
);

I call this immediately after the create process call (see the full
code posted elsewhere in this thread). It waits until the process is
finished, and then unblocks. What is so complex about this? The create
process already sets up the event you wait on (pi.hProcess). This is a
single API call. It's less work than your polling loop and uses *no*
system resources until the process it's waiting on terminates.

It's easy. It's efficient. It works on all versions of Win32. It's the
correct way to do things. Why would you want to do it any other way?

>
> I am sure you know enough to see that "blocking" is another term for
> getting the results of polling from somewhere else. Again, you get
> noting for nothing.

Well, having taking both undergraduate and graduate OS courses, and
having taught undergraduate OS courses as well, I'd argue that I *do*
know a *tiny* bit about the subject. And, no, "blocking" is not another
term for getting the results of polling from somewhere else. There is
no polling going on. When the other process terminates and the OS
removes it from the run queue (and all the process queues in general),
the OS moves all processes waiting on the terminated process from a
blocked event queue to the "ready to run queue". There is no constant
awakening of the process to test whether it can do its job; nor is the
OS (or anyone else) constantly
"polling" in order to determine that the process has completed and the
blocked task can run.

You can be "Wolfganian" here, and claim that I must not know what I'm
talking about because "I'm a professor" (which isn't true, I am not and
never *was* a "professor") or that this is all just "academic
nonsense". But the fact is that everyone else is telling the same thing
should be a clue that your understanding of the problem is a bit off
here.

>
> Exactly the reason for writing the 1000 thread test was to demonstrate
> that function beats fashion every time. With the sum total fitting into
> about 5% of processor time, the figure was 0.005% for each running
> process and that included te thread overhead.

Time saved has nothing to do with it. Using sleep is a *very* poor
synchronization tool, using sleep to synchronize objects is very bad
design. Especially when doing it right is actually *less* work.


>
> I have heard a lot of opinion but the tests speak differently and its
> testing I listen to, not opinion or anything as mindless as peer
> pressure.

The fact that the difference in performance is down at the noise level
is irrelevant. It wouldn't matter even if WaitForSingleObject was
actually *slower*. There's a right way to do something and a wrong way
to do it. And your method is a hack (the wrong way). The fact that it
only wastes several thousand cycles per time slice, and the Windows
performance monitoring tools cannot track this, is really not
important.

As for "peer pressure," well, what you're doing is a hack. It's not the
correct way to do this. But you take the Betovian attitude of "hey,
this was the first thing I came up with, on my own, so I'm sticking
with it no matter how bad it turns out to be." Better to just learn the
right way to do things, correct your old code so it's less embarassing,
and move on.


>
> I wrote assembler when you used to get ridiculed for it, I used generic
> asm data types when fashion dictated C++ types and I use JUMPS all the
> time so peer pressure means very little to me.

This is where I have a *fundamental* problem with the attitudes of many
assembly language programmers. One of the primary reasons assembly
language has nearly died off as a practical programming language is
because most people perceive that assembly language programs are *hard*
to read.

Now as many people around here can attest, a *well-written* assembly
language program is not all that hard to read. Particularly if you take
advantage of high-level assembly features like those found in MASM,
TASM, and HLA or use one of the various macro facilities in the other
assemblers that attempt to simulate these features. However, it takes
real effort on the part of a programmer to produce a truly readable
assembly language source file (more work than many other languages, in
fact).

Carefully written assembly language source code *can* be used as a
model to counter claims that assembly language is fundamentally
unreadable. However, people who pull stunts like using JUMPS (producing
spaghetti code), accessing memory as byte sequences rather than using
abstract data types, and pulling stunts like

mov eax, byteVar ;In assemblers with no type checking

produce the kind of code that make people *fear* assembly language.
Like your aversion to using WaitForSingleObject, there really is no
reason for writing assembly code in this way. There are structured
alternatives (even in the lower-level assemblers) that allow you to
write clear, self-documenting (well, as much as possible) code in
assembly language. In a high-level assembler such as MASM, TASM, or HLA
there are *great* facilities for this kind of stuff. Avoiding "fashion
dictated C++ types" is the fast path to producing unreadable code.

Ten years ago, it was very common to hear people say things like
"Assembly language? How terrible. You have to use numeric offsets to
access fields of structures. Why would anyone want to do something
insane like that?" Even back then, this statement wasn't true (MASM and
TASM fully supported structs back then, of course). But the perception
existed because *most* assembly language programmers weren't using
these facilities in their programs (even when using MASM or TASM).
Those people saw "generic ASM data types" in all their glory and wanted
no part of it. The sad part is that there was no reason an assembly
language programmer would have to drop to that level. Most assemblers
provided a *decent* way to access fields of a structure (even using
equates, if true structs were not available). It is no wonder HLL
programmers wanted nothing to do with assembly. When they see code
written by people who "don't care about their peers" they assume that
this is the way assembly code is written, and get turned off completely
to assembly.

The same is true for sleep vs. WaitForSingleObject. When a C programmer
(or any other Win32 programmer) sees that code, the first thing they're
going to think is "why does assembly language make you do this?"
They're not going to assume it's the programmer's fault. They're going
to assume that it's just not possible to use WaitForSingleObject in
assembly. After all, "assembly programmers really know what they're
doing," right?


>
> > If Sleep is the right way to do it, why is everyone
> > disagreeing with you on this matter?
>
> Would you construct HLA on the basis of consensus in ALA ?

Actually, yes. Several features in HLA today were the result of
comments made in this very newsgroup.

> If you
> practiced what you preach instead of relying on your own testing and
> research, you would have SPASM coded in HEX using 68k opcode macros and
> multiple pre-parsers (loc sic ???) for all and every variation.

You're assuming that the concensus reached would be Rene's, Herbert's,
or Wolfgang's. I serously doubt that would happen :-)

You're confusing design issues with implementation issues, anyway.
If someone wants to argue about whether parentheses belong in HLA, I'll
gladly ignore them based on my own experiences with HLA and other
programming languages. But if someone points out that there is a
problem with the way my lexer works (an example of a complaint from
this newsgroup) or how I should be able to use a procedure as a
template type for procedure variables, I'm willing to listen and make
changes as appropriate. Certainly if someone pointed out to me that I
wasn't properly waiting for HLAPARSE.EXE to complete execution prior to
running MASM (or some other assembler), I'd jump right on that and fix
it.


>
> > You have a very Betovian attitude here --
> > once the facts are pointed out, you continue to claim that your way is
> > the way to go even though the facts suggest otherwise.
>
> If facts do not means "verified by testing" or at least being testable,
> I use Karl Popper's criterion on such information, if it canot be eiter
> verified or falsified, then it is meaningless.

The right way to do it is given in MSDN. Look it up.
Cheers,
Randy Hyde

.

Relevant Pages

  • Structures in Assembly Language
    ... implementation in assembly language. ... Structures, or records, are an abstract data type ... decades, or so), and many assemblers still do not ... "old-timer" assembly language programmers attempt ...
    (alt.lang.asm)
  • Re: MASM Expert needed immediately
    ... RosAsm is GPLed and is the result ... of the efforts of many programmers, even if i am evidently the ... Probably something like 99.9% of the people who use assembly language ... assemblers out there. ...
    (alt.lang.asm)
  • Re: Born again
    ... Indeed, for major application programming, assembly language is dead. ... the fact that most programmers don't want to learn ... and the switch to HLLs began in earnest. ... assemblers makes the competence of programmers sparse; ...
    (alt.lang.asm)
  • Using Structures to write Readable and Maintainable Assembly
    ... bit of crazy replies suggesting that equates are a good substitute ... One of the greatest complaints about assembly language programs ... certain beliefs held by some programmers on the assembly "fringe" ... arguing that "real" assemblers don't have structures and no self-respecting ...
    (alt.lang.asm)
  • Re: Hey Mr. Hyde!
    ... fewer and fewer students get introduced to assembly language ... programming and, in fact, wind up with four years' of instructors telling ... It really isn't Randy Hyde, Universities, OSes, or high-level assemblers ...
    (alt.lang.asm)