gus@gatech.UUCP (06/17/87)
We're changing the computer support for the assembler-language programming
part of Ga. Tech's Computer Science School's first course in computer
organization and assembler programming.
Next fall I'll have DEC VAX Workstations. A problem is that we'll run ULTRIX.
Its assembler, "as", is not suitable for a first assembler course where an
objective is to acquaint students with the general notions and techniques of
assembler programming. I'm told there are no macro-instructions, no generated
code listings, no good textbooks. I want to use DEC's MACRO assembler for
VAX-11, but it's for VMS!
Does anyone have or know of a macro assembler after MACRO-11's pattern that
will run under ULTRIX or UNIX? There are good textbooks available for it,
and I coded macro-ll on PDP-11 minis some years ago and would enjoy teaching
its descendant.
--
gus Baird office: (404)894-3183 message: (404)894-3152
School of ICS, Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gusbzs@bu-cs.BU.EDU (Barry Shein) (06/22/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) From: gus@gatech.edu (gus Baird) >Next fall I'll have DEC VAX Workstations. A problem is that we'll run ULTRIX. >Its assembler, "as", is not suitable for a first assembler course where an >objective is to acquaint students with the general notions and techniques of >assembler programming. I'm told there are no macro-instructions, no generated >code listings, no good textbooks. I want to use DEC's MACRO assembler for >VAX-11, but it's for VMS! One more time...(this just went round and round, but I'd like to crystallize a few thoughts here.) First: Yes, I am fully cognizant of the fact that behind this request may be political and historical issues which the following begs, but there's nothing very interesting to say about such things. Second: I have taught assembler courses since the late 70's, first on large IBM mainframes (ASMG, ASMH) and later on Vaxes and Encores under Unix. This was all at Boston University's Computer Science Dept. The first thing that needs to be defined in such a course is what exactly is the goal of the instruction? For example: 1. Assemblers, linkers, loaders and their structure. 2. Machine language programming. 3. Machine architecture. 4. Software engineering and/or large-scale project development using machine language assembler as a development environment. 5. Something mildly vaguer, like enough machine language to understand what compilers do, or "cultural suntan". 6. A blast from the past, "I had to learn how to keypunch, now you have to also". Any topic in computer science must be viewed within the perspective of the finite resource of time allowed to an undergraduate curriculum. Anyone can list dozens of topics which an undergraduate "absolutely must" have studied before graduating. Fitting these into about 8 14-week courses is quite another matter (particularly when at least a few of those eight courses are likely already "taken" by things like discrete math.) Reality forces one to view the curriculum in terms of priorities and trade-offs rather than ideals. It is a zero-sum game, if a student becomes knowledgeable in, say, assembler language programming they probably have traded off the chance to study some other topic such as expert systems or graphics programming, you just cannot beat the game and cover everything that seems to need covering. Ok, given that I'll briefly describe one way I have covered the topic of machine language programming under Unix in recent years. We did it within the context of a low-level (sophomore) systems programming course where the goal was to learn how to write some of the more common structures (eg. loops) as subroutines called from C programs. We used a handout I prepared overviewing machine architecture (registers, PCs, instructions, addressing etc.) and detailing enough instructions to work through some examples and assignments (eg. a bubble-sort subroutine). Machine language programming constituted about 4 weeks of the course. The goals were (from the above list) 1, 2, 3 and 5. What was omitted was: 1. I/O - just get the data back to the higher level mainline and do the I/O in C. Regardless of what happened in the 60's there's hardly any reason to do I/O in assembler anymore, just learn how to call higher level language routines or do it when you return to main. Even years ago when I taught advanced IBM/ASM I used this approach for floating point I/O using Fortran routines. 2. Software engineering - Again, very few of the people in the room will ever need to know how to do large-scale project organization in asm. A lot of the wonderful structure such as "structured macros", file includes etc that old-time programmers pine for in modern systems is by and large superfluous for all but very, very few of the students except as a historical note. Do you pine for sequence numbers in column 72 just in case they get a card deck and drop it? Similar. 3. Stand-alone asm programs, for similar reasons as 1. above, it's just become trivia for the bulk of the students. Now for an epilogue. I realize that this will prompt all sorts of flames about how critical it is that today's undergraduates become master asm programmers and learn all the tools of that trade in exquisite detail. I only ask that you try to understand (if you do not deal with such issues first-hand) how tight an undergraduate's curriculum in Computer Science is. You cannot teach an entire course in assembler programming without NOT teaching something else, the burden is on you to detail exactly what will be omitted from your curriculum to support your point of view, it is not sufficient to simply argue your case for concentration on assembler programming beyond what I have outlined above. Anyhow, be that as it may, the upshot is that there is no problem teaching a course as I have outlined using Unix assemblers. Never forget that the point is to serve the student's needs in a broader context, not the nostalgia of the instructors. -Barry Shein, Boston University
elg@killer.UUCP (Eric Green) (06/30/87)
in article <8935@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) says: >>Next fall I'll have DEC VAX Workstations. A problem is that we'll run ULTRIX. >>Its assembler, "as", is not suitable for a first assembler course where an >>objective is to acquaint students with the general notions and techniques of >>assembler programming. I'm told there are no macro-instructions, no generated >>code listings, no good textbooks. I want to use DEC's MACRO assembler for >>VAX-11, but it's for VMS! > > Ok, given that I'll briefly describe one way I have covered the topic > of machine language programming under Unix in recent years. We did it > within the context of a low-level (sophomore) systems programming > course where the goal was to learn how to write some of the more > common structures (eg. loops) as subroutines called from C programs. > We used a handout I prepared overviewing machine architecture > (registers, PCs, instructions, addressing etc.) and detailing enough > instructions to work through some examples and assignments (eg. > a bubble-sort subroutine). I agree somewhat with your reasoning. I don't think that heavy-duty assembly language programming is necessary or adventageous for your average undergrad. I do think that some introduction to assembly language is necessary in order to get the "feel" of a typical computer architecture (please, no flames about non-Von Neuman architectures, most CS undergrads will go to work for General Motors and write The Ultimate Automobile Simulator on an IBM, or ignition contrul system with a 6809, and otherwise use "conventional" systems). Your approach seems to be adequate for that purpose, except perhaps I/O (but doing I/O from assembly language on a Unix system is an excercise in futility insofar as teaching about the I/O system, so I see the point in omitting it). > 2. Software engineering - Again, very few of the people in the > room will ever need to know how to do large-scale project > organization in asm. A lot of the wonderful structure such as > "structured macros", file includes etc that old-time programmers > pine for in modern systems is by and large superfluous for all > but very, very few of the students except as a historical note. Again, I see the point. Personally, I've only used macros a few times in my assembly language experience, and usually end up having to expand them by hand when I move my code to a different assembler (in The Search for the Ultimate Assembler, see a theater near you). In fact, about the only "advanced" feature that my current assembler has is the ability to do "C"-style IFDEF's and #INCLUDEs. More just isn't necessary when the bulk of the program is written in another language, such as "C" (even I'm not THAT masochistic.... the biggest assembly language stuff I've written is about 5,000 lines of support routines for a much larger program on a Commodore 64). > 3. Stand-alone asm programs, for similar reasons as 1. above, > it's just become trivia for the bulk of the students. > > Now for an epilogue. I realize that this will prompt all sorts of > flames about how critical it is that today's undergraduates become > master asm programmers and learn all the tools of that trade in > exquisite detail. I only ask that you try to understand (if you do not > deal with such issues first-hand) how tight an undergraduate's > curriculum in Computer Science is. Frankly, I'd rather see them learn how to write decent programs in a high level language than learn the "tricks of the trade". Most assembly language programs nowadays will be replacements for parts of a "C" program that were too slow, or otherwise something of that nature, where the structure is already laid out by the "C" program... learning how to write "structured" assembly language under those circumstances is as much an oxymoron as "structured Fortran" :-). Let the EE guys program the microwave oven microcontrollers, right? Eric Green {ihnp4,cbosgd}!killer!elg, elg@usl.CSNET
john@xanth.UUCP (John Owens) (07/05/87)
> Frankly, I'd rather see them learn how to write decent programs in a high > level language than learn the "tricks of the trade". Most assembly language > programs nowadays will be replacements for parts of a "C" program that were > too slow, or otherwise something of that nature, where the structure is > already laid out by the "C" program... learning how to write "structured" > assembly language under those circumstances is as much an oxymoron as > "structured Fortran" :-). > Let the EE guys program the microwave oven microcontrollers, right? Please, no! I'd rather not have my food overcooked when I change power levels in the midst of cooking, or have a timed sequence I programmed earlier kick in while I'm defrosting something manually, etc. It gets much more serious when you start to talk about industrial arc-welding robots instead of microwave ovens. I agree that teaching high level languages and principles is most important, but let's not forget that there are people that will use assembler, and not as support routines for a C program either. There are times when the requirements just won't let you. Unfortunately, these are the times when its most critical for the program always to be in a well-defined state, to not blow up on boundary conditions, etc. Structured assembly programming can be quite important. So, for anyone who is teaching assembly programming, be sure to stress modular top-down coding, single-entry-single-exit blocks, and all those wonderful things. At the least, make sure that your students code in procedures, with documented names, entry and exit conditions, registers and global variables modified, etc. Students should realize that the principles they are taught do not just apply to one class of languages, but can be used anywhere. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john