Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!quiche!opus!peterd From: peterd@opus.cs.mcgill.ca (Peter Deutsch) Newsgroups: comp.software-eng Subject: Re: Assembler and teaching Software engineering Summary: A place for assembler here? Message-ID: <1940@opus.cs.mcgill.ca> Date: 16 Mar 90 02:44:48 GMT References: <891@gistdev.gist.com> <1003@dms.UUCP> Organization: SOCS, McGill University, Montreal, Canada Lines: 199 I missed the follow-up by Flint Pellett to my posting on teaching a first assembler, but caught the subsequent posting by Mike Albaugh, so will buy back into this by responding to points made by both. I think the thread could/should be expanded to a more general discussion about soft-eng training in general. If you find the assembler stuff boring, skip to the end where I throw in another 2 cents worth. For a taste of what I feel, I'd say there is merit in a first software engineering course that contains (at least in part) a large project written in assembler. See below for more. ------------------------------------------------------------ In article <1003@dms.UUCP>, albaugh@dms.UUCP (Mike Albaugh) writes: > From article <891@gistdev.gist.com>, by flint@gistdev.gist.com (Flint Pellett): >> peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: >> >>>BTW, the assembler I teach is the PDP-11 assembler. We >>>don't have any PDP-11's any more, so we use a simulator >>>... >> To each his own I suppose, but I think you're doing your >> students a dis-service. Learning a dead language just because >> that will help you to learn a modern one is only a reasonable >> path if it will take you less time to both learn the dead one and >> then the modern one than it would take to start with the modern >> one and only learn it. I'm afraid I have to disagree (obviously! :-) but it's because you appear to misunderstand my motives. The reason I teach the "dead langauge" is _NOT_ so I can then teach the modern one. I teach it because it better illustrates the general principles I am trying to communicate, without unnecessary special casing, verbose explanations and convoluted justifications. (eg, I don't want my students asking: "So why do we NEED segment registers? Why do we HAVE to use the BX register, I'd rather use AX. Well, can't I copy that from here to there? Oh, what's an ES register?" No prizes for recognizing this incredibly widespread CPU, so popular in industry). And why teach assembler? Not so they can work as programmers, but so students better understand the workings of their machine and their programs. More on this below. >> . . . . . . . . I doubt this is true. Your students >> are going out into the world with PDP11 on their resumes instead >> of something that might help them in the real world: I wonder >> how many of them will support your position a couple years from >> now? One point of course is, "how many will be hired to program in assembler?" but I also wonder how many would be better served if I'd simply taken over the PC lab, where they wouldn't have the UNIX environment, the network, Usenet, ftp to all those archive sites, real email, talk, electronically distributed, submitted, graded and returned assignments, automatic backup by a professional systems admin staff, and so on. After all, there are all those DOS machines out there... Seriously, someone suggested to me that we convert to 68000 a couple of years ago, but now they're suggesting SPARC. I say "Let's teach them what an Execution Cycle is, what addressing modes are, what is the difference between Harvard and Von Neumann architectures, what is a Bus access (and why is it so expensive), what is the difference between Memory-Mapped and Port-Mapped I/O, what are peripherals, what a compiler does to an Assignment Statement, etc, etc. I _DON'T_ want to spend my too short semester on Segment Registers, Page Zero addressing, how to reboot if you crash the machine and gorf your disk, etc. These are _details_, and not germaine to the point of the course. To be fair, noone actually suggested I use 8088 assembler, but it is certainly a popular chip. The newer Intel chips have done away with much of the problems of the early designs, but that's the whole point. I shouldn't be a slave to fashion. I'm suppose to be teaching principles, and as efficiently (and hopefully enjoyably) as possible. [ And Mike Albaugh wrote: ] > I must strenously disagree. The first computer language > a student learns seems to mold a great deal of the student's > attitude and approach to programming. We may choose to quibble > about the "right" first language on theoretical (or religious :-) > grounds. But we should _never_ to pick one on "resume" grounds. Hear Hear! There exist any number of companies that promise to make you a "Systems Analyst/Programmer in only three short months!" (So is that February, April and June? :-) Presumably there is a reason university degrees take a little longer? I might also point out that I don't teach them their first language, just their first assembler. A first Computer Science course is a prerequisite and they learn Pascal there. Of course, Pascal is not the point of that course, either. It's learned so they can implement the ideas presented in class. They are later expected to "pick up" other languages as needed, with only some help from instructors. > It can take a very long time for an employer to "de-train" > an employee in those areas where blind-spots (and unreasoning > phobias) have been induced by commercially expedient training. Or to "fill in the gaps" left by limited exposure to a narrow view of the world. I usually try to spend one lecture on another CPU architecture, just to stress the common ground and areas for legitimate architectural differences. I do _NOT_ try to teach it all in one course. Actually, it's probably time to swing this back into the area of software engineering, so I'll take a stab at it. I have seen earlier discussions on the net (I think it was in comp.edu) along the lines of "but why even teach assembler? Most students wont every use it!" I happen to think assembler in the second semester is a great idea, because it is time to "demystify" the computer and convince students that they really do control EVERYTHING the machine does. _Someone_ wrote the code to write to the disk, get the date and play hack. Once they believe that, you can start to show them how to do it themselves. Now, soft-eng? I would suggest that it is possible to bang on a 500 line Pascal program, and perhaps with sufficient patience, help and luck get it not to crash during the demo for the TA. I would maintain that if you wrote a 500 line assembler program that was not designed along proper engineering principles (eg. structure your tasks, eliminate side-effects, document your code, develop and debug in a methodical manner, changing no more than a single variable in the debugging process to avoid masking problems, etc) then your program just can't be made to work. I have seen too many examples where it wasn't and it didn't. Note, I am NOT advocating that we develop large commercial projects in assembler, but that exposure to a good sized assembler project is a suitable microcosm for some of the classic problems in software engineering for beginners in a first assembler course. I like to think my course serves to "demystify" the computer for novices, gives confidence needed to tackle large projects and, as a bonus serves as a first exposure to some basic software engineering principles. For the record, I structure my programming assignments as a series of progressively more complex specifications, where assignment(n) assumes the availability of assignment(n-1). I deliberately do _NOT_ reveal the purpose of assignment(last) to students until the final specification is released, after the submission of assignment(last-1). Thus students are forced to a) completed each assignment to stay in the running, and b) write each subroutine in a general purpose manner. If you take short-cuts, you will tend to have to reimplement each time. What are the type of projects? Well, one semester students implemented a PDP-11 disassembler (well, a subset), another semester a toy simulator (on the simulator, that threw them a bit) another semester an actual assembler in assembler. I hope each served to make clear the role of the tools they were using in bringing the silicon to a usuable state. How does this work? I would claim it is reasonably successful. I do _NOT_ get a Bell-curve grade distribution, but rather a double-humped curve of A's and D's, weighted towards the A's. Students seem to enjoy the course (which I think actually matters, and not just as a quality of life issue. If you enjoy it, you pay attention, if you pay attention, you tend to learn more) and althought I fail some people each semester, those that pass seem to have "got the point". Anyways, enough about how _I_ do it. I was fortunate to have inherited a course that fits into my own philosophy and which I can teach as I see fit (of course, if I failed 2/3 of a class or got spectacularly bad reviews, that might change! ;-) So what do others think about using such a course as a first exposure to software engineering. And if it is such a bad idea, how _should_ it be done? Enquiring minds want to know.... - peterd