matloff@iris.ucdavis.edu (Norm Matloff) (02/28/91)
In article <1991Feb22.183040.29689@msuinfo.cl.msu.edu> reid@cpswh.cps.msu.edu (Dr Richard J. Reid) writes: >Over the years, we've shrunk the Assembly Language >coverage to a large portion of a one-quarter course. ... >If there's going to be a following required semester course, >and it has an assembly language component or maybe even theme, >what else is in that same semester course? >Or, is it possible that this type course can disappear >completely, or become an elective? You have hit on my pet project. I have just written a book to serve as a "modernized" version of this old course (_IBM Microcomputer Architecture and Assembly Language_, to appear this Fall, published by Prentice-Hall). I have a feeling that I may swimming against the tide here, i.e. that your word "disappear" above may refer to the current trend. Also, this forum is not the proper place for an advertisement for the book. But the whole point of writing that book was that I felt that the course does need to be modernized, not disappear, so here is my "two cents' worth." :-) The way we teach the course here at UCD is to emphasize that it is NOT a "language course," but rather a concrete, hands-on introduction to computer systems, i.e. architecture, OS and systems software. Most importantly, it is the students' first look "under the hood." The idea is that up to this point, students have only seen computers from the outside, from the point of view of Pascal or C. Now, in this course, they take a look INSIDE. The "engine" being viewed "under the hood" consists of two components, the machine architecture and the OS services. The theme of our course is that any computer professional needs to have an understanding of this "two-component engine." First, it is needed because in some applications we do have to resort to writing at least part of a program in assembly language. Second, even if one always programs in a high-level language, system-related bugs will arise frequently, and these can't be solved without having some understanding of what's "under the hood"; this is especially true for C programming. Third, there are "cultural issues," e.g. every computer professional should have at least some idea as to what makes one computer faster than another (it is amazing how many holders of B.S. degrees in CS can't even explain the PC ads in one's daily metropolitan newspapers), on what applications, etc., and how one can speed up execution if needed. Quite a bit of our course is directed to relate to the students' experience with high-level languages. For example, there is quite a bit, throughout the course, on examining compiled code produced from Pascal or C source, to see how the compiler is making use of the computer's "engine," and whether it is doing so efficiently or not. We have found that under this approach, the students feel that the course relates better to their other CS courses, in which they use only high-level languages. Under this approach, the students do learn assembly language for a particular machine (in our case, the PC family), but that is meant as a means, not an end; the goal is to give a CONCRETE overview of architecture and OS. One illustration of this is that we assign just as many "analytical exercises" as programming exercises, again to emphasize that there is much more to being a computer professional than just programming. Norm Matloff
horne-scott@cs.yale.edu (Scott Horne) (02/28/91)
In article <8455@ucdavis.ucdavis.edu> matloff@iris.ucdavis.edu (Norm Matloff) writes: >In article <1991Feb22.183040.29689@msuinfo.cl.msu.edu> reid@cpswh.cps.msu.edu (Dr Richard J. Reid) writes: < <<Over the years, we've shrunk the Assembly Language <<coverage to a large portion of a one-quarter course. <... <<If there's going to be a following required semester course, <<and it has an assembly language component or maybe even theme, <<what else is in that same semester course? <<Or, is it possible that this type course can disappear <<completely, or become an elective? < <You have hit on my pet project. I have just written a book to <serve as a "modernized" version of this old course (_IBM <Microcomputer Architecture and Assembly Language_, to appear <this Fall, published by Prentice-Hall). I recommend the book. (I've read the manuscript.) No other book I've seen covers the same material: most either present the basics of computer operation or teach 80x86 assembly language, but this is the only one I've read which does both. It's a fine book for students with some programming experience (preferably in C or Pascal). <I have a feeling that I may swimming against the tide here, i.e. <that your word "disappear" above may refer to the current trend. Indeed it is. Yale's computer "science" department doesn't use assembly language in any of its courses (at least not at the undergraduate level). I consider that unfortunate. <Also, this forum is not the proper place for an advertisement <for the book. But the whole point of writing that book was that <I felt that the course does need to be modernized, not disappear, <so here is my "two cents' worth." :-) It's a sorely needed two cents' worth, believe me. <The <"engine" being viewed "under the hood" consists of two <components, the machine architecture and the OS services. Come on, Norm. I thought I told you to get rid of those peculiar "hood" and "engine" metaphors. :-) <Second, even if one always programs in a high-level <language, system-related bugs will arise frequently, and these <can't be solved without having some understanding of what's <"under the hood"; this is especially true for C programming. By "system-related bugs", do you mean bugs in the system or bugs in users' programs that arise because of factors related to the internals of the system? (I'm not disagreeing; I'm just asking for a clarification.) --Scott -- Scott Horne ...!{harvard,cmcl2,decvax}!yale!horne horne@cs.Yale.edu SnailMail: Box 7196 Yale Station, New Haven, CT 06520 203 436-1817 Residence: Rm 1817 Silliman College, Yale Univ Uneasy lies the head that wears the _gao1 mao4zi_.
horne-scott@CS.YALE.EDU (Scott Horne) (02/28/91)
In article <8455@ucdavis.ucdavis.edu> matloff@iris.ucdavis.edu (Norm Matloff) writes: >In article <1991Feb22.183040.29689@msuinfo.cl.msu.edu> reid@cpswh.cps.msu.edu (Dr Richard J. Reid) writes: < <<Over the years, we've shrunk the Assembly Language <<coverage to a large portion of a one-quarter course. <... <<If there's going to be a following required semester course, <<and it has an assembly language component or maybe even theme, <<what else is in that same semester course? <<Or, is it possible that this type course can disappear <<completely, or become an elective? < <You have hit on my pet project. I have just written a book to <serve as a "modernized" version of this old course (_IBM <Microcomputer Architecture and Assembly Language_, to appear <this Fall, published by Prentice-Hall). I recommend the book. (I've read the manuscript.) No other book I've seen covers the same material: most either present the basics of computer operation or teach 80x86 assembly language, but this is the only one I've read which does both. It's a fine book for students with some programming experience (preferably in C or Pascal). <I have a feeling that I may swimming against the tide here, i.e. <that your word "disappear" above may refer to the current trend. Indeed it is. Yale's computer "science" department doesn't use assembly language in any of its courses (at least not at the undergraduate level). I consider that unfortunate. <Also, this forum is not the proper place for an advertisement <for the book. But the whole point of writing that book was that <I felt that the course does need to be modernized, not disappear, <so here is my "two cents' worth." :-) It's a sorely needed two cents' worth, believe me. <The <"engine" being viewed "under the hood" consists of two <components, the machine architecture and the OS services. Come on, Norm. I thought I told you to get rid of those peculiar "hood" and "engine" metaphors. :-) <Second, even if one always programs in a high-level <language, system-related bugs will arise frequently, and these <can't be solved without having some understanding of what's <"under the hood"; this is especially true for C programming. By "system-related bugs", do you mean bugs in the system or bugs in users' programs that arise because of factors related to the internals of the system? (I'm not disagreeing; I'm just asking for a clarification.) --Scott Scott Horne ...!{harvard,cmcl2,decvax}!yale!horne horne@cs.Yale.edu SnailMail: Box 7196 Yale Station, New Haven, CT 06520 203 436-1817 Residence: Rm 1817 Silliman College, Yale Univ Uneasy lies the head that wears the _gao1 mao4zi_.