Re: Book on Assembly


Jim Carlock wrote:
<randyhyde@xxxxxxxxxxxxx> wrote:
Let me tell you what happens when you let the students loose
to create their own control structures. Instant spaghetti! It's
amazing how bad they wind up writing code.

Some spaghetti is better than some other spaghetti.

And the spaghetti students write, without having been taught how to
create reasonable control structures in assembly language, is among the
worst.

Not all spa-
ghetti is the same.

That is correct. On one extreme you have an experienced programmer who
makes an informed decision to destructure a part of their program in
order to achieve some goal (and the destructure *only* that part needed
to achieve the goal). At the other extreme, you have students who've
not been taught how to create decent control structures; who just keep
hacking away at the code until they get one path through the program
that seems to work. The result in this latter case is *not* pretty.



Some might have a better noodle. Some might
have a better tomato. It's up to the instructor to point out and
explain the difference in the noodles and tomatoes. And the very
long winding broken noodle isn't always a bad noodle.

And one way instructors point this out is by showing how to create all
the classical control structures in assembly language. IFs, WHILEs,
FORs, REPEAT..UNTILs, etc. Once the students have templates for these
control structures under their belts, the code they produce is improved
by an order of magnitude (or better). Please see the original comment
-- it was that students shouldn't be taught how to write these
classical control structures, that they should be left to create
whatever control structures they feel like. And that's a disaster. I've
seen that in action.


I'll argue with you Randy, not against the structured approach,
and not against teaching the fundamentals, but against the non-
sense about spaghetti. I believe it's a rather poor analogy and
presents spaghetti in a negative demeanor, and I'll attempt to
present the same spaghetti in a positive light.

40 years of software engineering has taught us a couple of things.
Among them, spaghetti coding is bad. Yes, there are a *few* exceptions
to the rule. Generally, those exceptions involve efficiency. Almost
never would those exceptions apply to students taking an assembly
language programming course. The last thing you want to do in a
programming course is teach bad habits. And spaghetti coding is a bad
habit.




Once you have your so called spaghetti from each (and hope-
fully every student, some students will be utterly confused and
might not turn in anything to start, but for the moment we'll
assume that every student turns in something) student, you,
the instructor get an understanding of some things in particular.

(1) You'll spot the students that take the easy way out.

How is that?
More oftent than not, such code is incomprehensible.

And, at the end of all of these, you wind up with a bunch of students
bitching about how bad the instructor is for not teaching them how to
do the task at hand. And such bitching is highly justified in that
case.

(2) You'll spot the students that take a studious approach.

No, all you really do is spot the students who've studied the subject
before, or those few students who seem to figure everything out on
their own. That's not what teaching is all about. Teaching is about
reaching the *average* student.


(3) You'll see those that know little.

Uh, when you walk into the classroom for the first time, you see those
who know little. That's generally the whole class. The point of the
course is to take those students who know little and, by the end of the
course, make sure they know as much as possible. Refusing to teach them
who to implement classical control structures in assembly language is
not part of the route I would recommend if you want to ensure that as
many people as possible learn the subject. Sure, you'll filter out
those few, brilliant, students who can figure things out on their own;
but that's not the purpose of the course. The purpose of the course is
to teach those who *don't* figure it out on their own. After all, those
who can learn it on their own don't really need a course to teach them
the material, eh?


(4) You see those that know quite a bit.

Again, what does this accomplish? By the end of the course it will be
quite obvious who the brilliant students are. Why make the rest of the
class suffer just to make them stand head and shoulders above everyone
else?


At this point, you'll have some starting information about the
skills of the students.

The purpose of the course is not to rank the students on their native
abilities. Rather, the purpose is to teach as many people as possible
the subject at hand. Ranking will come automatically as you grade
assignments, give tests, and so on.


At the end, hopefully the final project
demonstrates that each student advanced and learned.

And one of the things you hope they've learned is how to write
structured, spaghetti-free, assembly code. However, if you don't
emphasize the need to do this, and teach them how to do it, then you
can't really expect to achieve that goal by the end of the course.


The
goal is teaching and you need two items to know that you've
taught well. You need a starting point and a finishing point.

And you need everything in between. And one of the things inbetween is
teaching them how to implement structured control structures in
assembly language.

The first project and the last project. Never identify the
purpose for the first project as something to demonstrate a
level of advancement, some students will already pick up on
this (as it's such a common thing, that students might come
in expecting such a thing, it must be taught to students training
to be teachers). So the purpose for the first project is for the
instructor to discover the abilities of the students, so tell them
that it will be the ONLY project that is NOT required to get
turned in, just make them write a written statement why they
didn't turn in a project (five paragraphs in length, in standard
scientific writing, with a subject paragraph, three reasons why,
and a conclusion). Have to get them ready for the real world,
whereby if someone doesn't complete a project a written exp-
lanation is required (could even give students a certain amount
of money to start out - fake money, whereby the amount of
money at the end determines their grade).

I strongly recommend that you teach several classes of students. It's
amazing how people's idealogical views change once they're presented
with real-world situations. I sure know mine did. BTW, if you give an
impossible assignment, just to judge the students abilities, all you'll
do is separate those who've learned assembly previously (perhaps by
taking the course already and getting a very low grade in in) from
those who've never seen it before. And by doing so, you'll guarantee a
*very high* drop rate by the drop date for the course. Been there.
Done that. It's not an effective way to teach students.



Expect spaghetti at the start, and expect better spaghetti in the
end, that's the way I see it.

No. Don't expect spaghetti code. Assembly is almost universally taught
at the University level *after* a high-level language programming
course. In HLLs since the late 1970s, students have been taught
structured programming and been explicitly told to avoid spaghetti
coding. Why should we allow it in an assembly course? Despite the fact
that you must synthesize decent control structures from compares and
jumps, you *can* do structured programming in assembly and there is no
excuse for accepting spaghetti coding from students. Teach them the
right way to do it and enforce that in your grading policy.


A great vegetarian spaghetti gets
the applause, perhaps some eggplant, peas and beans mixed in
with the tomato, garlic, basil, cilantro and a couple serrano
peppers.

Nonsense.



From real-world experience, let me suggest that teaching
the students how to implement classical control structures
in assembly language is the best approach. Once they see
how the classical structures are done, *THEN* they can
explore alternative approaches. But without a decent
foundation to build their knowledge upon, the result is
often chaos.

I agree with that. I believe the spaghetti you described offers
more than you acknowledged.

I suspect you really don't know what spaghetti code is. :-)



I. Introduction
(Keep it simple, short and to the point).
II. A common approach. All software development starts off
with a goal or objective or purpose. Then it requires an under-
standing of that objective and options involved...
III. A simple "hello world" demonstration.
IV. A simple real world example of something quite common.
Perhaps something like a booking software for an airline,
to demonstrate saving a file, reading a file, searching through
a file, loading data from disk to a memory structure. Some
one else can add to what this software should do.

That's quite a jump from III to IV. Where do they, for example, learn
about arithmetic, control structures, data structures, and so on? (That
is, the kind of stuff necessary to develop the simple real-world
example?) Trying to teach all of that while presenting an example as
complex as you've chosen is difficult. That's why most books stick to
*trivial* examples during this time period.

V. Another real world sample, whereby a DLL exists and is
already created, and the goal is explain taking apart the DLL.

Though writing a DLL is cool for the sake of writing a DLL (or shared
library, if under Linux), what does this have to do with assembly
language? Yes, it could be yet another example, but what makes the
choice of writing a DLL more "assembly language" than any other example
(such as the "airline reservation" problem)?

Though I applaud your suggestions to provide real-world examples (even
if they would have to be trivialized a bit).
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Book on Assembly
    ... that all code exists as some form of spaghetti. ... then the students produce *bad* ... "spaghetti code" implies that the control structures in a program ... decade+ that I taught assembly language at the University level, ...
    (alt.lang.asm)
  • Re: Book on Assembly
    ... HLL-like control structures with CMP and Jcc, ... The students already know HLL-like control structures. ...
    (alt.lang.asm)
  • Re: Book on Assembly
    ... Some spaghetti is better than some other spaghetti. ... You'll spot the students that take the easy way out. ... this (as it's such a common thing, ... singly linked lists, ...
    (alt.lang.asm)