Re: Teaching Assembly Language Programming
- From: "randyhyde@xxxxxxxxxxxxx" <randyhyde@xxxxxxxxxxxxx>
- Date: Wed, 20 Jun 2007 17:53:54 -0700
On Jun 20, 5:08 pm, "T.M. Sommers" <t...@xxxxxx> wrote:
randyh...@xxxxxxxxxxxxx wrote:
Oh, and let us not forget that the students are
taking three other courses concurrently with the
assembly course. Not only does this eat up a lot of
their time, but those other courses are a huge
distraction that get in the way of the student
focusing on learning assembly language.
You're forgetting another high-priority, time-consuming
distraction for many students: nightly keggers.
And I designed my
programming projects around the things I wanted the
students to learn.
Can you give some examples of these projects, both before and
after you redesigned the course?
It is interesting you ask this immediately after T.M. Sommers' post
about cool LEDs and the like. One of the earlier lab manuals I created
had the students wiring up (low-current) LEDs and switches to the
parallel port on the PC and then writing code to read the switches and
manipulate the LEDs. While it was cool and fun (well, for some of the
students, anyway, some just can't handle any type of wiring at all),
the bottom line is that every moment the students spent wiring up the
LEDs and switches was one minute taken away from learning assembly
language. Ultimately, I made up a set of pre-wired modules that
plugged into the parallel port. But I eventually abandoned that as
well because, once again, while there was a huge "coolness" facter,
there really wasn't any "assembly language" to be learned that
couldn't also be learned with a hexadecimal or binary output routine
(to the console).
The above stuff, of course, was used with MASM under DOS. Clearly,
supporting such projects under Windows would be a major pain.
On this page:
http://webster.cs.ucr.edu/AoA/DOS/Software.html
You can download the ZIP files that used to contain lots of lab
experiments I had the students doing. For example, I wrote a program
to help them compute an optimized logic equation for an arbitrary
equation specified in minterm form. Cool as it was, once again, having
students do Karnaugh maps takes away from having them learn assembly
language. There are other courses in the program where they will learn
about Karnaugh maps (i.e., the digital electronics courses), so there
was no need to waste time on that material in the assembly course.
There was also a simulator for a trivial hypothetical machine (the
"Y86") that provided a Ketman-like environment when studying machine
organization and architecture. I actually carried that over into the
electronic version of AoA/32 (though I redesigned the emulator),
however, I nixed it in the published edition.
In fact, if you compare the published edition of AoA with the
electronic edition, what you'll find is that I dropped *most* of the
non-assembly-language-programming-related material (that is, a lot of
the arcane computer architecture stuff that isn't directly related to
assembly programming). It's not that the stuff wasn't important to
learn, but that it was too much material to use in a single course on
assembly language programming, and you have to draw the line
somewhere.
There is actually *far* too much stuff in AoA to cover in a single
course. This is good for two reasons-- it gives the students something
to read when the course is over, and it allowed me to cherry pick
different material each quarter to help reduce plagiarism.
Looking back at the current published edition, I can tell you what
would get changed for a second edition:
1. Much of the discussion of the HLA stdlib would be consolidated into
a single chapter, rather than being spread out all over the place.
Perhaps this material would be put in an appendix for reference
purposes.
2. The chapter on the MMX instructions would go away (replaced by a
chapter on SSE).
3. The chapter on floating-point instructions would deprecate the use
of the FPU except for the unique instructions it supports and use the
SSE instruction set instead.
4. Most of the chapter on mixed language programming would go away.
I'd probably include an appendix on linking assembly code with C/C++
and leave it at that.
5. I'd probably make the chapter on macros quite a bit smaller.
6. The chapter on bit operations would probably be cut in half and
moved earlier in the book.
7. The chapter on string instructions would probably go away. Most of
the instructions are deprecated, and the important ones could be
explained elsewhere. Almost no one, who is interested in high-
performance string operations, would use those instructions. And if
you don't care about performance, then the HLA stdlib string
operations are pretty good.
8. I would drop appendix D (30 pages) because this appendix simply
replicates Intel's information. I'd just get permission to include
Intel's manuals on the accompanying CD.
Of course, the reason for cutting things out is to make room for new
stuff. As noted, a chapter on SSE should replace the MMX chapter and a
chapter on the HLA stdlib would be useful. I would like to cover more
instructions in the book (AoA probably hits about 30% coverage at this
point -- which might seem like a tiny amount until you consider the
number of SSE instructions that are so special-purpose they wouldn't
belong in an introductory text). I would like to add more examples and
add an oft-requested feature: questions and projects at the end of
each chapter (AoA/16 used to have these, but after a few years on the
internet the answers were all over the place so an instructor could no
longer use them). I would like to add a chapter on using a debugger
(OllyDbg under Windows, GDB under Linux/FreeBSD/MacOS). I would like
to add a chapter on multithreaded programming in assembly language
(obviously, that's becoming a hot topic). Finally, I'd probably add an
appendix that discusses the differences in syntax between HLA, MASM,
FASM, and, possibly, NASM.
hLater,
Randy Hyde
.
- Follow-Ups:
- Re: Teaching Assembly Language Programming
- From: zjrm
- Re: Teaching Assembly Language Programming
- References:
- Teaching Assembly Language Programming
- From: randyhyde@xxxxxxxxxxxxx
- Re: Teaching Assembly Language Programming
- From: T.M. Sommers
- Teaching Assembly Language Programming
- Prev by Date: Re: Teaching Assembly Language Programming
- Next by Date: Re: Teaching Assembly Language Programming
- Previous by thread: Re: Teaching Assembly Language Programming
- Next by thread: Re: Teaching Assembly Language Programming
- Index(es):
Relevant Pages
|