Microport System V/AT Assembly Language not documented

[A. Lester Buck]

In article <750 at cgch.UUCP>, whna at cgcha.uucp (Heinz Naef) writes:
> The assembly language processed by the as(1) command of Microport System V/AT
> has a completely different semantics, different instruction mnemonics and a
> different assembler control (macro) language than usual assemblers for the
> 80x86 personal computers.
> 
> When writing a device driver at the lowest level (i. e. not on top of another
> device driver) then there is a need to develop certain parts in assembly
> language. With the documentation supplied by Microport for the System V/AT
> program development and runtime system, it is *impossible* to even attempt to
> write a minimum assembler program. Compared to the excellent documentation of
> the linkkit, it is strange that there is no chapter on usage of the assembler
> and on coding guidelines.

I was asking Microport for as(1) documentation over two years ago.
Guess they still haven't found it. ;-)  They claimed that AT&T
did not supply any, and that was that.

There are several obvious ways to get a handle on as(1) syntax.
The linkkit includes gdt.s as an example.  You can also get
.s output from cc(1).  And sdb can be coerced into disassembling
pieces of working code.  The C User's Group has some public
domain assemblers for various 8- and 16-bit chips, and the author
picked a uniform assembler syntax based on the Unix System V
assembler.  These disks must (?) come with some documentation
on the syntax, but I haven't seen it.  I guess the same author
is now selling versions of the code, as the Feb 89 issue of
Embedded Systems Programming magazine has a review of ten
cross assemblers and mentions PseudoCode distributed by KORE
at (616)791-933 based on the same System V as(1) syntax.

But the real question is why do you need to write large
amounts of as(1)?  The table of contents for 7th Edition
Unix, dated Jan 10, 1979, has the entry

UNIX Assembler Reference Manual.  D. M. Richie.
	The ultimate dead language.

[It describes the PDP-11 Unix assembler in 12 pages, might
help you as a last resort]

Make your first pass in C, profile your _working_ driver
to find its bottlenecks, and only then think of tweaking those
routines by hand.  

Didn't Knuth say something like

"Premature optimization is the root of all programming evil."


-- 
A. Lester Buck		...!texbell!moray!siswat!buck