[misc.wanted] Need Macro Assembler for ULTRIX/UNIX

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!gus

bzs@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