Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ptsfa!hoptoad!academ!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.edu
Subject: Re: Need Macro Assembler for ULTRIX/UNIX
Message-ID: <1068@killer.UUCP>
Date: Tue, 30-Jun-87 04:02:36 EDT
Article-I.D.: killer.1068
Posted: Tue Jun 30 04:02:36 1987
Date-Received: Sat, 4-Jul-87 13:18:06 EDT
References: <8935@bu-cs.BU.EDU>
Distribution: na
Organization: Bayou Telecommunications
Lines: 66

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