Very Computer

The School of Computer Science at my site wishes to teach undergraduate
assembly language programming on a VAX 11/780 running BSD 4.3. Is the
default assembler "as" suitable (i.e. friendly enough) for student use?
If not, can anyone point me to an alternate VAX assembler that is
friendlier and does operate under Berkeley UNIX?

Many thanks.
--
UUCP:      {seismo|watmath|utai|garfield}!dalcs!aucs!wdw

Two years ago I ran our assembler programming course under BSD4.2 and vowed
never to do it again.

There is NO macro assembler available for the VAX (unlike the PDP-11).  I
scoured the entire planet via USENET, COMPUSERVE, and Telecom -- to no
avail.  

The conclusion was -- for a user-friendly assembler I would have to go VMS!

Good luck to you, Bill.  If you find something suitable, do let me know.

Thanks.

Now that is a real puzzler.  Did you try:  man -k macro
which should have turned up m4.  Granted it isn't as fancy as SAIL
macros, but surely it is good enough for people playing with assembler code.

Quote:> The conclusion was -- for a user-friendly assembler I would have to go VMS!

Sigh.  I think I would write sed scripts before I went to that extreme.
Besides, C was always the default user-friendly assembler on unix machines.

What I meant to say was that there is no equivalent of ms (as opposed to as)
for BSD4.x Unix.

I did look at m4, but it is really geared to C and did not really address the
problem of sophomore students learning a very user-unfriendly assembler.

It is?  Why, then, is someone I know experimenting with using it as
a front end to the Sun assembler?  (Well, then again, he has some some
other pretty dumb things :-) .)

Quote:>and did not really address the problem of sophomore students learning
>a very user-unfriendly assembler.

Okay, here is the *real* question:

What makes an assembler friendly or unfriendly?

I have used:

        EDTASM (Z80);
        two homegrown assemblers (Z80);
        Microsoft's M80 (Z80);
        a rather weird assembler written in FORTRAN (IBM 370);
        4BSD `as' (Vax);
        Sun `as' (680x0);
        GENIX `as' (NS320xx);
        Microsoft's MASM (80x86).

Of all of these, I like the 4BSD and Sun `as' best, for two reasons:
the 4BSD assembler is fast, and the Sun assembler is reasonably fast
except for extremely large (compiler generated) inputs; and both of
them support a form of temporary labels (4BSD has number labels, Sun
has both number labels and short-scope labels).

One of the two homegrown assemblers, `rzasm', uses m4 as a macro
preprocessor.  (The other was something I wrote in BASIC on my old
TRS-80 model I.  It could assemble large programs, as it spilled
labels to disk files, but was rather slow.  It ran at the blinding
speed of 15 lines per minute ... each pass.)

Only M80 and MASM had extensive built-in macro facilities, but I
never really missed these with the others.  In the case of the Vax
and Sun assemblers, I use the C preprocessor, since the assemblers
will accept semicolon-separated statements:

        movl $0,r7; 1: addl2 r9,r7; ashl $1,r9,r9; bbc $12,r9,1b

(/lib/cpp eats newlines in macros, hence something like this is
required.  m4 does not eat newlines.)

So what is /bin/as missing, or what does it do wrong, that makes it
user-unfriendly?
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)

Perhaps the poster referred to the quality of the error messages.  I
like the PDP-11 RT-11 assemblers best in this regard in the bad old
days.  One course I TA'ed used a cross assembler and a simulator for a
PDP-11 architecture. The students managed alright.

Frankly I think teaching more than a smattering of assembler is a
WOMBAT (waste of money, brains and time).  It should only be necessary
for that 1% of bit-twiddling that needs speed or needs to use a special
instruction.  Or to read generated code, if you write compilers.

Does anybody remember KT's (DMR's?) subtitle on the as manual in the V7
docs? "The ultimate dead language".

        Ken

The biggest problem students, especially sophmores, face is that they
need simplicity!!!! That means either some simple system calls like
INCHWL on TOPS-20 assembler (input character, wait for line feed before
returning) or macros (see almost any assembly text book) like read_w to
read in word length integers. Students need to be able to write 20 to 30
line programs that do something reasonably useful. I have taught the
machine organization and/or symbolic language programming course at several
universities for almost 20 years using GE Macro Assembly Processor, Xerox Macro
Assembly Program, TOPS-20 Macro, Vax Macro-11 under VMS, and IBM 360 BAL. I
have also used a home grown processor for MIXAL [knuth, 1969] and several
others. User friendly items include at least:
1. same mnemonic for adding (et. al.) irrespective of whether the operands
   are registers or memory cells
2. being able to give symbolic names (other than Rn) to registers.
3. identical syntax for accessing an address in either a memory cell or a
   register.
4. reasonable vehicles for parameters in macro definitions (an avid hater of
   ampersands here) for both positional and keyword parameters.
5. a reasonable selection of conditional assembly pseudos
6. EXCELLENT error diagnostics because students WILL make errors
7. good literal or remote assembly features so data can be written near the
   code using it (tops 20 was excellent about this) so students can invoke a
   print system call or macro and have what is being printed at the print
   statement rather than in a data block.
8. reasonably free form input (this was a problem way back when)
9. a good selection of pseudos for data generation and storage allocation
   that match the machine architecture. (I seem to recall one from the distant
   past that had an ARRAY pseudo that defined the symbol as 1 word less than
   the next free location so that if you put a 1 in a register and used indexing
   you got to the first reserved space. This was back before PASCAL so it was
   what the fortran programmers wanted to do)
10. A user friendly listing so students can see what is happening.

I could go on a while, but this is getting long enough already.
--

        aka ...nbires!boulder!cdash

Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix)

Quote:>So what is /bin/as missing, or what does it do wrong, that makes it
>user-unfriendly?
>--
>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)

I think a lot of the hand-wringing I see over assemblers come from
people who were bred in old-fashioned O/S environments where most
system code was written in assembler, such as OS/370 or VMS.

In these environments extensive facilities exist (for their era) to
support asm coding. IBM's ASMH is a monument to assembler coding with
macro facilities supporting extensive string processing, arrays and
other arcanum.  Suffice it to say I once wrote a simple lisp compiler
which took lisp statements in-line in asm code and turned it into
machine code in ASMH AT ASSEMBLE-TIME, all the necessary facilities
were there as far as I was concerned. Pretty wierd. You'll hear
similar stories from MIDAS coders, interesting history.

This is not to say that these tools were nearly as powerful as a C
programmer gets on a Unix system, just relatively powerful. For
example, nothing like Lint for the asm programmer, nor SCCS. You
were lucky if you got directories to organize code into.

This causes a lot of carry-over, such folks are astounded at the
"weakness" of Unix assembler environments, they feel like a Unix
programmer might on a Lisp machine (well, something like that.)

Unfortunately there is a tendency for such folks, having left a place
where ASM rules king, to mourn this loss and point an angry finger,
often a machismo finger at a problem that just doesn't exist (lack of
a powerful macro asm under Unix.) They rarely stop and ask themselves
how come none of the people who do all this devpt work under Unix
never seem bothered by the omission.

I think what people (educators) need to ask themselves is; exactly
what am I trying to accomplish with this ASM course? Teach how an
assembler works? Teach machine language? Teach machine architecture?
Teach large-scale software engineering using machine language? Torture
undergraduates?

Unfortunately many of them are, in fact, wishing to teach large-scale
software engineering using machine language, perhaps under the guise
of an architecture course. This is because this former environment was
one with pleasant memories for them, all those wonderful neato keano
macros which almost looked like high-level languages or generated
in-line tables for state machines (gee, we could do everything YACC
does in only 10 times the effort! but it looked kind of impressive...)

They should, however, take a long deep breath and ask themselves
whether it's just possible that their entire world has gone the way of
the Edsel and the village blacksmith. Pleasant memories, perhaps, but
worth re-creating in this day and age?

This is not to say that teaching some machine language is not a good
thing.  I think it is. But teaching large-scale software projects in
machine language (or the tools and techniques that were used to
accomplish this) may be a dead subject.

Sorry.

        -Barry Shein, Boston University

Reading generated code is useful for tracking bugs (both compiler and
user) and undocumented compiler features down also.  (The latter I do
use on a compiler I have NO documentation on.  (It is NOT an illegal
copy.))  I've even found that reading a dissasebled listing of
something written in assembly can help track down inefficancies.  (The
assembler in question made pessimistic assumptions about relitive
addresses.)
--
Bob Larson

Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
                        seismo!cit-vax!usc-oberon!castor.usc.edu!blarson

There is another way to achieve simplicity: use the C library,
and provide the students with a skeleton program.
This is what my professor used to do. He provided us with a simple
calculator (only addition and subtraction), and we had to add * and /,
operator precedence, and one feature of our own choice, I think.

This worked very well, and it had the added benefit that you learned
the C calling sequence. That is what you write assembler for, isn't
it, to use little assembly routines in big C programs....

Quote:> User friendly items include at least:

I'll comment on some of these items. I've left out the ones on
which I agree (or don't have an opinion on, or don't understand:-)

Quote:>1. same mnemonic for adding (et. al.) irrespective of whether the operands
>   are registers or memory cells
and
>3. identical syntax for accessing an address in either a memory cell or a
>   register.

No. This is very dependent on the machine. For instance, if you're
programming assembler on a RISC machine (poor you), you'd better
know where your operands are.

Quote:>4. reasonable vehicles for parameters in macro definitions (an avid hater of
>   ampersands here) for both positional and keyword parameters.
>5. a reasonable selection of conditional assembly pseudos

I'm not sure. I think the C preprocessor should be used here.
Especially since most assembler stuff will be used in a C environment
under unix, and this allows you to use the same header files.
The assembler should know about #line or some such, however, so
that it can point you to the correct line in case of an error.

Of course, if you want to teach students to use assembly for programming
traffic lights using an 8080, you're in a different position altogether.

You shouldn't be teaching them VAX assembler then, however.
--

        The shell is my oyster.

The original poster bemoaned the Unix assembler for teaching assembler.
Many followups said that it was fine for those few things one puts in
assembler, especially if you add m4.
Barry Shein, who posted the followup that this is a followup to, correctly
states that assemblers like ASMH have incredible capabilities, most of which
are supplanted in the Unix world by C.  He also goes on to question whether
it is necessary to teach about such assemblers.

The answer there is *yes*.  If I wanted a course in assembler, and got taught
'as', I would be somewhat lost if my job then required me to know the likes
of ASMH.  There are a number of capabilities that one expects from most
assemblers; 'as' has relatively few of them.  (The local labels are nice,
I hadn't known about them.)

If your attitude is that you should only occasionally need assembler, and
it's mostly there for compilers to emit, I will counter by saying that if
you choose your architecture correctly, you never need assembler.  Don't
forget the B6700, et al, who have got along without an assembler since before
Ken Thompson ever found a PDP-7 sitting in the corner.  (Of course, they have
trouble implementing 'C'; it's too low-level a language.)

--
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson