wdw@aucs.UUCP (Bill Wilder) (05/13/87)
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
BITNET: {wdwvax|wdw}@Acadia
Internet: {wdwvax|wdw}%Acadia.BITNET@WISCVM.WISC.EDUns@maccs.UUCP (Nicholas Solntseff) (05/14/87)
In article <351@aucs.UUCP> wdw@aucs.UUCP (Bill Wilder) writes: >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? 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.
webber@brandx.rutgers.edu.UUCP (05/15/87)
In article <588@maccs.UUCP>, ns@maccs.UUCP (Nicholas Solntseff) writes: > 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. 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. > 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. ------------------ BOB (webber@aramis.rutgers.edu ; rutgers!aramis!webber)
ns@maccs.UUCP (Nicholas Solntseff) (05/17/87)
In article <234@brandx.rutgers.edu> webber@brandx.rutgers.edu (Webber) writes: >In article <588@maccs.UUCP>, ns@maccs.UUCP (Nicholas Solntseff) writes: >> >> There is NO macro assembler available for the VAX (unlike the PDP-11). I > >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 > 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.
chris@mimsy.UUCP (Chris Torek) (05/18/87)
In article <593@maccs.UUCP> ns@maccs.UUCP (Nicholas Solntseff) writes: >I did look at m4, but it is really geared to C 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 :-) .) >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) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
ken@rochester.ARPA (Ken Yap) (05/18/87)
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
bzs@bu-cs.BU.EDU (Barry Shein) (05/18/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) >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
blarson@castor.usc.edu (Bob Larson) (05/18/87)
In article <27848@rochester.ARPA> ken@rochester.UUCP (Ken Yap) writes: >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. 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 Arpa: Blarson@Usc-Ecl.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
dricej@drilex.UUCP (Craig Jackson) (05/19/87)
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: cjacksonchris@mimsy.umd.EDU (Chris Torek) (05/19/87)
From: Root Boy Jim <rbj@icst-cmr.ARPA> I don't have the original article, but maybe he meant "is it" [it being m4, the question being is it tailored to C] rather then "it is". I don't see m4 as being particularly tailored for or against C or assembly or anything else for that matter. m4 is just about maximally untailored. What makes an assembler friendly or unfriendly? I'm surprised you had to ask, Chris, or was that a rhetorical question? No: I have never had much use for fancy macros in assembly. All I want from an assembler is that it assemble, quickly, and that it tell me where something is wrong. There is so little to go wrong that it does not matter *what*: just *where*. I think [an extensive macro facility] is a major requirement for serious asm hacking. As a litmus test, I would say the ability to write a set of macros which implemented if-then-else, while, and the like (in short, a mini compiler), is a pretty good assembler. I had never even considered using macros for higher level constructs. When I wanted higher level contstructs, I used higher level languages. (I thought that was what they were for...? :-) ) In fact, I would rather use cpp for assembly as well. But perhaps m4 can generate multi-line text? It does indeed. Here is something that friend of mine whipped up yesterday while playing with m4: define(for,`define'($1,$2)`ifelse($2,$3,$4 ,$4 undefine(`$1')`for'($1,`incr'($2),$3,$4))') for(i,1,6,xxx(i) + i) define(pushall,`ifelse($1,,,push $1 `pushall'($2,$3,$4,$5,$6,$7,$8,$9))')dnl pushall(a,b,c) define(popall, `ifelse($1,,,`popall'($2,$3,$4,$5,$6,$7,$8,$9)pop $1 )')dnl popall(a,b,c) Run on this, m4 produces the following (adjacent blank lines squished out): xxx(1) + 1 xxx(2) + 2 xxx(3) + 3 xxx(4) + 4 xxx(5) + 5 xxx(6) + 6 push a push b push c pop c pop b pop a Not particularly useful for anything, perhaps, but it does demonstrate that m4 can do at least some of what those other macro facilities can do.
rbj@icst-cmr.arpa (Root Boy Jim) (05/19/87)
>I did look at m4, but it is really geared to C 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 :-) .) I don't have the original article, but maybe he meant "is it" rather then "it is". I don't see m4 as being particularly tailored for or against C or assembly or anything else for that matter. Fortran maybe? >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'm surprised you had to ask, Chris, or was that a rhetorical question? 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). Only M80 and MASM had extensive built-in macro facilities, but I never really missed these with the others. I think this is a major requirement for serious asm hacking. As a litmus test, I would say the ability to write a set of macros which implemented if-then-else, while, and the like (in short, a mini compiler), is a pretty good assembler. Two such beasts are the VMS assembler, basically a descendent of MACRO-11 (um, maybe it's *still* called that), and @ASM or @MASM over on the UNI{VAC,SYS} 1108 (or whatever model). Walk on over to ZBEN's office sometime and ask to see a copy of STRUC$. 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.) In fact, I would rather use cpp for assembly as well. But perhaps m4 can generate multi-line text? So what is /bin/as missing, or what does it do wrong, that makes it user-unfriendly? Of course, the UNIX `as' is not supposed to be friendly, because you're not encouraged to use it. I think any UNIX `as' is probably not very good for teaching purposes. It's main purpose and design is as a back end for compilers. On the other hand, perhaps it is very well suited for teaching, because there are no frills to be distracted by. In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> Yow! I want to mail a bronzed artichoke to Nicaragua!
phil@osiris.UUCP (Philip Kos) (05/19/87)
In article <27848@rochester.ARPA> ken@rochester.UUCP (Ken Yap) writes: >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. I found a bug in an early version of Pyramid's optimizer by looking at the generated assembly-language compiler output. I can't *program* in Pyramid assembly (they're pretty paranoid about keeping their instruction instruction set proprietary) but I can mostly read it, thanks to lots o' work with different machine instruction sets, and it was simple to find where the loop control variable initialization had been elided by the optimizer, right after that 20-way switch... Assembly language is not dead by any means. ...!decvax!decuac!\ Phil Kos ...!seismo!mimsy!aplcen!osiris!phil The Johns Hopkins Hospital ...!allegra!/ Baltimore, MD
terryl@tekcrl.UUCP (05/20/87)
Just thought I'd add my $0.02 worth (it seems everyone else has (-:).
I've been doing heavy systems work in the software realm on various
flavors of 680X0 based workstations (replace X with one of 0, 1, or 2) for
the last 6 years. In doing heavy systems work, I've had to write a lot of
assembler for things that we just couldn't do with a C compiler (any C
compiler). I am fluent in both the so-called "Motorola" assembler format, and
the so-called "MIT" assembler format. I can read (and write)both with absolutley
no problems at all. I know both VAX and PDP 11 assembler, and used to know
IBM 1130 and 360 assembler (thank god I haven't had to work on an IBM system
in over 10 years!!!(-:). I've dabbled in 8080 assembler when I was an undergrad;
I can recognize National 16XXX(or 32XXX, or whatever they've named it recently),
but am not as fluent in it as I am with the 680X0; so in the last 15 years
I've had quite a bit of experience with various assemblers for different
architectures.
Personally, I don't like to use macros in assembler, especially macros
that generate multiple lines of real assembler code. Sure, it makes writing
assembler code much easier, and if the writer choses good mnemonic names, then
conceptually it is easier to understand what the code is trying to do. However,
it is a real pain in the assembly (-: to debug and maintain that code.
Part of the problem is that many Unix[1]-based assemblers have no macro
capability at all, so in order to get at least a semblance of a macro capabil-
ity, cpp is used. The problem with cpp, bless its little heart, is that it
strips out ALL the newlines of multi-line macros. So a listing of the source
(if you're even lucky to be able to get an assembler listing, again a capabil-
ity many Unix-based assemblers don't have), is practically useless for these
multi-line macros. I've seen some assembler macros that have generated 15-20
lines of real code, and even though the names were mnemonic enough that I knew
exactly what the code was supposed to do, I still didn't like it. The code was
just too difficult to debug.
A very good example of the use (and misuse) of macros in assembler is
writing loops. Loops like clearing a block of memory, or loading some hardware
with a regular pattern (usually the index of the loop, maybe with some shif-
ting and or'ing in of some constant bits). These kinds of loops are extremely
common in the system world, with the loop count (and address, if appropriate)
as arguments to the macro. The problem is making sure the arguments to the
macro are correct. You want to make the macros general enough to accept just
about any argument (for example, in clearing memory, in a virtual-memory based
system anyways, you always clear in terms of the hardware page size, but it is
desirable to make the macro general enough so that you can clear any block of
memory that is any size). Since actual code speaks louder than words, let me
use my clear-memory example. For simplicity sakes, let us assume the use of
a 68020 processor(which is what I'm most familiar with, anyways). First, the
general macro to clear a block of memory. Also, let's assume that we'll always
clear 32 bit quantities (known as a long-word in 680X0 jargon), and we'll also
assume that the count is a 32 bit count, but with at most 16 bits of precision
in an UNSIGNED twos-complement format (I know, I'm cheating, but in the systems
world, these are valid assumptions). Let us also assume our assembler has no
macro capability, so we are forced to use cpp (definitely NOT cheating, and
probably true of most Unix-based assemblers). I will use the Motorola assembler
format.
First, the macro:
#define CLEAR(count, address, reg, areg) \
move.l count,reg /* Load count */ \
beq.s 2$ /* Bail out if zero count */ \
movea.l address,areg /* Now get the address */ \
subq.l #1,reg /* Subtract one (for dbra) */ \
1$: \
clr.l (a0)+ /* Clear a long-word */ \
dbra reg,1$ /* Go back and do it again */ \
2$:
For all of you people out there who don't know 680X0 assembler, I'll
(briefly) explain what is happening. The macro loads the count of the number
of long-words to clear into a data register, and if this count is zero, then
do nothing. If the count is non-zero, then get the address of the start of
the block of long-words to clear. Decrement the count of the number of long-
words to clear by one(for an explanation of why this is necessary, wait a few
lines longer....). Clear a long-word of memory, using what is known as the
auto-increment addressing mode (see just about any assembler documentation
on how this particular addressing mode works).
I will give just a brief explanation on the dbra instruction. The dbra
instruction is a specific form of the dbcc instruction on the 680X0, where
the cc part of dbcc can specify one of sixteen conditions for terminating
the loop. Specifically, what the dbra instruction does is take the 16 bit
SIGNED twos-complement value in the first operand (which has to be a data
register), and subtracts 1 from it. Then it takes the new value of the first
operand and compares it -1 (that's a 16 bit SIGNED comparison), and if the new
value is not -1, then branch to the label specified as the second operand. If
the new value is -1, then continue with the next instruction following the dbra
instruction.
To understand my cheating comment, you have to understand how twos-
complement arithmetic works, both in signed and unsigned arithmetic. I'll
assume most of you do, and if you do, then my comment should be clear.
Now, let's see a couple of examples of the use of the CLEAR macro:
First, a routine to clear a page of memory NBPG bytes long:
/*
* Clear a VIRTUAL page of memory NBPG bytes long.
* Called from C by:
*
* pageclear(virt_addr);
*/
pageclear:
CLEAR(#(NBPG/4), 4(sp), d0, a0)
rts
Now, a routine to clear a block of memory:
/*
* Clear a block of memory.
* Called from C by:
*
* bzero(virt_addr, count);
* unsigned count;
*
* NOTE: Count must be greater than 4, and count must be less than
* 262144 (65536*4), and must be a multiple of 4.
*/
bzero:
move.l 8(sp),d0
lsr.l #2,d0
CLEAR(d0, 4(sp), d0, a0)
rts
A little explanation is in order here. First, I am assuming an unsigned
count in a specific range. Second, I have to convert a byte count into a long-
word count. That's what the first two instruction before the CLEAR macro call
are for(done in UNSIGNED arithmetic).
But having a count be in a specific range is not too nice, so let's
provide a routine that can take an arbitrary count.
/*
* Clear a block of memory (arbitrary size).
* Called from C by:
*
* blkclr(virt_addr, count);
* unsigned count;
*
* NOTE: count must be greater than 4 (but no upper limit except for
* the 32-bit architecture limit), and must be a multiple of 4.
*/
blkclr:
move.l 8(sp),d0
lsr.l #2,d0
blkclr1:
CLEAR(d0, 4(sp), d0, a0)
subi.l #0x10000,d0
bge.s blkclr1
rts
So now you've seen an example of a macro in assembler, and a couple of
examples of its use. So why don't I like macros in assembler??? TYPOGRAPHICAL
ERRORS. I am not the world's best typist (probably one of the worst (-:).
If, for example, in the macro call to CLEAR used in pageclear I forgot the #
(which is how you specify an immediate operand in the assembler we use for
the 680X0), then the routine would have been assembled without any errors (it
is syntactically correct according to the assembler), but it would have not
been conceptually correct, and a quick look at the use of the macro could have
very well not revealed any obvious errors (I'm famous for that (-:).
Another reason I don't like using macros is that I just can't remember
the order of the arguments, and then I have to go look at the actual definition
of the macro, which sometimes can take a lot of time (damn, where did I define
that stupid thing??? Which include file did I put it in???). Sometimes, it'll
take me longer to find the actual definition of the macro than it would have
if I had just coded the stupid thing up by hand in the first place.
Another reason I don't like using macros is when it actually comes down
to debug time (If I had a dollar for every time I've had to debug system code
with our own home-grown debugger, using breakpoints, single stepping, etc. I
could probably retire a rich man by now; no (-: here). Again, I have to go
find the definition of the macro, and then find the use of it.
So those are my reasons for not liking macros in assembler. I'm sure I
could come up with more(actually, I can. In my undergrad days, learning PDP
assembler, we had a REAL macro assembler. This macro assembler could do
EVERYTHING, including recursive macros. One of our assignments was to write
something using recursive macros. You want to talk about a nightmare!!!)
Eagerly awaiting your comments (and flames (-:)
Terry Laskodi
of
Tektronixbenson@alcatraz.ksr.com (Benson Margulies) (05/20/87)
In article <201@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: >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. > >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 you went to a school that taught you concepts and approaches instead of cookbooks, you would be prepared for anything your job threw at you, from microcode to Prolog. Caveat Student: those who live by the `current technical relevance' die the same way. PS: The Unix-centrism of some of the posts around here is pretty amusing. "Most of the code should be in C, of course." Only if you have the misfortune to be marooned there. It never ceases to amaze me that people haven't noticed that C was the right thing for a PDP-11 and is the wrong thing for almost bigger, faster, or more sophisticated. On a *real computer*, with a real optimizing compiler, you *can* have datatypes and performance at the same time. C programmers have replaced the assembly language programmers of the 60s and 70s, who could always be heard asserting that you couldn't write a *real* system in anything else without it being far to slow. Those who condemn PL/I are doomed to face ADA. Benson I. Margulies Kendall Square Research Corp. harvard!ksr!benson All comments the responsibility ksr!benson@harvard.harvard.edu of the author, if anyone.
benson@alcatraz.ksr.com (Benson Margulies) (05/20/87)
In article <1111@osiris.UUCP> phil@osiris.UUCP (Philip Kos) writes: >In article <27848@rochester.ARPA> ken@rochester.UUCP (Ken Yap) writes: >I found a bug in an early version of Pyramid's optimizer by looking at >the generated assembly-language compiler output. I can't *program* in >Pyramid assembly (they're pretty paranoid about keeping their instruction >instruction set proprietary) but I can mostly read it, thanks to lots o' >work with different machine instruction sets, and it was simple to find >where the loop control variable initialization had been elided by the >optimizer, right after that 20-way switch... > >Assembly language is not dead by any means. > Reading machine code is \not/ the same thing as programming in assembler. Taking a course in a heavily macro-ified assembler only obscures the kind of machine code produced by a compiler. Learn Architecture. PS: Here is some garbage to force Pnews to accept this article. What is the reason for "article contained more text than new text?" Benson I. Margulies Kendall Square Research Corp. harvard!ksr!benson All comments the responsibility ksr!benson@harvard.harvard.edu of the author, if anyone.
gwyn@brl-smoke.UUCP (05/20/87)
Please don't use /lib/cpp except as part of /bin/cc. It is not intended for use as a general macro processor and may indeed go away some day. If you need a macro processor on UNIX, use m4.
chuck@felix.UUCP (Chuck Vertrees) (05/21/87)
The original posting regarding the availability of an acceptable assembler for use in teaching an assembly language course seems to have sparked a discussion concerning the need to teach assembler at all. Some of the responses I have seen seem to imply that assembler is not needed at all, and doesn't need to be taught. I disagree. I think that is a very short sighted view and one that misses the whole point of a course like this. For the first two years in the real world (what ever that is), I wrote nothing but assembler. Since then I have extensively used many other languages, including C and Pascal. The initial heavy emphasis on assembler has had, I believe, a subtle but beneficial effect on my coding ability and style, regardless of the language I choose to use for a given task. The "unixness" of this forum really shows through in the type of comments that are made here. While unix may indeed be mostly written in C, and assembly is only used sporadically, that does not imply that one should not need to learn assembler. Yes, the computing environment is changing. We are being provided with more and better languages and the need to use assembler is being further reduced. But again, that does not imply that one should not need to learn assembler. In my view, the purpose of an assembler course at a two or four year school should not be to teach a specific assembly language, nor to teach a specific architecture, but to introduce students to yet another type of computer language that they may come across in their careers. The discipline required for proper assembly language programming is not the same as that required for programming in a higher level language. You have to know where your operands are, you have to know how you can operate on them, and you have to understand all the consequences of those operations. (Actually the same for any language, just more operations and consequences in assembler.) Using a macro package to hide some of this from you may be convenient, but if you still don't understand what is really happening, then that is dangerous, regardless of the language you may be using. And I guess this finally gets to the point of this whole message. I believe I am a better programmer for having learned and used assembler. The mind set required for proper assembly language programming has carried over into the other languages I now use. As a result, I feel I produce a better product for it. It doesn't mean that I think everything should be done in assembler. It does mean I think you can be a better (more rounded?) programmer for having been exposed to it.
ron@emcard.UUCP (Ron Saad ) (05/22/87)
In article <588@maccs.UUCP> ns@maccs.UUCP (Nicholas Solntseff) writes: % In article <351@aucs.UUCP> wdw@aucs.UUCP (Bill Wilder) writes: % >... Is the % >default assembler "as" suitable (i.e. friendly enough) for student use? % % There is NO macro assembler available for the VAX (unlike the PDP-11). I % That's true, but with *careful*, sane use of m4 and cpp it's not that bad. We used m4 for a Unix assembler course at PINY (just to see if we could ... and survived!). There's no need to get super fancy - simple macros in m4 will go a long way, and you can either provide them for everyone's use, or have the students write their own ... Ron. -- ------- opinions? what opinions? they don't pay me enough for opinions! ------- UUCP: ..akgua!emcard!ron Ron Saad (AA4WG, 4Z4UY) MAIL: Woodruff Memorial Research Bldg Rm 414, Emory Clinic Cardiovascular 1364 Clifton Rd NE, Atlanta, GA 30322 Epidemiology (404) 727-7198
dparter@ccvaxa.UUCP (05/22/87)
when i was at Wisconsin, we had the same problem. We hacked together a version of as that uses m4 as a front end, produces listings after macro expansion, and a small library of utility routines. contact beebs@wisc.edu to see if you can get a copy --david David W. Parter gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!dparter arpa: dparter@gswd-vms.gould.com
zben@umd5.umd.edu (Ben Cranston) (05/26/87)
This is an issue that touches close to the hearts of many, ergo the
surfeit of heat and deficit of light. When do we move the discussion
of assembly language from the Computer Science undergraduate program
to the "history of technology" curriculum? As an aside, I'd surely
like to know if the Japanese are teaching assembly language.
One thing to keep in mind is that the majority of readers of this net
are using Unix systems, and have (rightly or wrongly) bought into the
canard that assembly language is dead. Thus they are likely to advance
the argument that teaching assembly language is a stupid thing to do,
rather than try to solve the problem as presented.
I may be one of the worst assembler-bigots around, but UMD5 has been
three different machines in the past 5 years (PDP-11, uVax, 750) and
I haven't writen a line of assembly code. I've had a Mac Plus for more
than a year, and haven't written a line of assembly code. It's quite
impressive that Megaroids (an "asteroids" clone for the Mac) is entirely
written in MegaMax C and suffers no lossage due to time constraints
(this kind of real-time environment is where any such lossage should show).
Yes, knowing some assembly languages can really help when dealing with
bogus compilers, and I have found bad code bugs in both the IBM Pascal
and Fortran H compilers by inspecting the machine language output.
I used to write huge gory assembly macros, but stopped because none of
my co-workers could understand them. I still do macros, but simple ones
that only solve the task at hand, rather than huge gory packages that
try to be everything to everybody and end up being nothing to nobody...
Is it possible that the "ultimate dead language" comment on the AS man
page might be a comment on the PDP-11 instruction set itself, rather than
generically condemning all assembly languages? Since some of the wartier
"features" of C (undefined fill on right shift, promotion of float
to double on function call, etc) can be traced directly to the uglyness
of the PDP-11 instruction set, one can certainly sympathize...
--
Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can).
umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92
umd2.BITNET "via HASP with RSCS"ken@rochester.ARPA (Ken Yap) (05/26/87)
Let me just say that I support, nay would promote, the teaching of one assembly language when coupled with a computer architecture course. All of the respondents who pointed out that assembly language is still useful somewhere gave examples that required knowledge of machine innards, e.g. driver hacking, compiler checking, etc. With knowledge of the syntax of a couple of assemblers, you can go on to conquer any machine. Nobody taught me assembler. I started off with a KIM-1, then went on to PDP-11 MACRO and haven't looked back since. Teaching algorithms in assembler is a dead duck. System hacking in assembler is also mostly unnecessary. Even the monster Cyber's utilities could be written in an albeit non-standard Pascal. Ken
chips@usfvax2.UUCP (05/26/87)
In article <2794@felix.UUCP>, chuck@felix.UUCP (Chuck Vertrees) writes: > [] Some of the responses I have seen seem to imply that assembler is not > needed at all, and doesn't need to be taught. I disagree. > [] For the first two years in the real world (what ever that is), I wrote > nothing but assembler. > [Purpose of assembler course] to introduce students to yet another type of > computer language that they may come across in their careers. Amen. Assembler-illiterate programmers become helpless when confronted with compiler bugs and/or adb. (Not to mention MS-DOS CodeView/SymDeb/Debug, which are still in use.) And to understand 80x86 memory models is to know 80x86 assembler. (Please no flames about the 80x86 architecture -- I hate it too! But mechanics have to fix even the badly engineered cars.) > Using a macro package to hide some of this from you may be > convenient, but if you still don't understand what is really happening, > then that is dangerous, regardless of the language you may be using. Right. Perhaps students should only be allowed to use macros that they have written themselves, thus eliminating "I don't know why, but it works". > The mind set required for proper assembly language programming has carried > over into the other languages I now use. This is both a curse and a blessing. I find that at times I must turn off my internal "C to assembler translator" and either (1) let the compiler do the work or (2) decide that this particular program doesn't need it. Assembler -- can't live with it, can't live without it. -- Chip Salzenberg Address: "{gatech,cbatt,akgua}!usfvax2!ateng!chip" AT Engineering, Tampa, FL Redress: "chips@usfvax2.UUCP" "Use the Source, Luke!" My opinions do not necessarily agree with anything.
bsteve@gorgo.UUCP (05/28/87)
BLETCH! This discussion is becomming totally pointless. I would not even consider teaching assembly language with 'as' on the VAX. It is easy enough to recall that in that environment 'C' IS the assembly language for the most part. Nevertheless, I do not believe that assembly language should be omitted from the curriculum. It is an essential part of a student's introduction to machine organization. The VAX is a nice choice for teaching assembly language, but only with the VMS assembler. MACRO32 is probably one of the best assembly language programming environments to be had anywhere. After all, it is still a real programming language under VMS (not that this is good :-). Steve Blasingame (Oklahoma City) ihnp4!gorgo!bsteve
m5@bobkat.UUCP (05/28/87)
In article <1704@umd5.umd.edu> zben@umd5.umd.edu.UUCP (Ben Cranston) writes: > . . . It's quite >impressive that Megaroids (an "asteroids" clone for the Mac) is entirely >written in MegaMax C and suffers no lossage due to time constraints >(this kind of real-time environment is where any such lossage should show). >-- >Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can). Well...Megaroids does in fact contain some assembly language code. The in-line assembly is used to (I think) move the stuff around on the screen. Along the same lines, the Macintosh graphics software (what's it called? it's some cute name ... well whatever) is all assembly language. I taught assembly language (pdp 11) at SMU for four semesters, and at Intel customer training for a couple of years. In the professional field, I regularly encountered engineers in iAPX 86 assembly language classes who were working on projects to be done in a high level language: "my manager thought it would be a good idea for me to know assembly language." The instruction there was very pragmatic, and of course the bizarre 86 architecture had to be taught as if it were perfectly normal (no offense, Intel people -- I don't dislike the 86). We *never* taught the "part II" class (in Dallas, anyway) that included the macro processor for ASM86. The coverage was slight anyway. (What a strange macro processor that is, too. Sort of like m4.) At SMU, on the other hand, there was a tradition of teaching a happy little "dream machine" instruction set before actually doing real work. I noticed that this was a *severe* mistake -- I had students attempting to write pdp 11 programs with the phony instructions right up to the day of the final. Perhaps my students were ill-prepared, or perhaps I screwed up, but in any case I abandoned that technique. At the level I taught the class (second-semester freshmen), macros were unthinkable anyway; they did make it easy to provide I/O routines, but we could have easily used subroutines instead. I am quite sure that I could have taught the same class under unix with little or no modification (probably would have been easier -- calling "write" is a hell of a lot simpler to explain than is the FIRQB and XRB crud under RSTS/E). Well, that's enough from my little brain -- why is this in unix.questions anyway? -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
rbj@icst-cmr.arpa (05/28/87)
This is an issue that touches close to the hearts of many, ergo the
surfeit of heat and deficit of light. When do we move the discussion
of assembly language from the Computer Science undergraduate program
to the "history of technology" curriculum? As an aside, I'd surely
like to know if the Japanese are teaching assembly language.
Yes, this is certainly getting out of hand. I would imagine the Japanese
*do* teach assembly because they are very thorough and rigorous. However,
the one main reason to keep doing so is that assembly language is
*fundamental to what a computer really is*.
One thing to keep in mind is that the majority of readers of this net
are using Unix systems, and have (rightly or wrongly) bought into the
canard that assembly language is dead. Thus they are likely to advance
the argument that teaching assembly language is a stupid thing to do,
rather than try to solve the problem as presented.
I would say that there are still arenas where asm is king, but we have
entered the age where HLL's are both available and sufficient to get
the job done. This was not always true, partially because we were often
programming around the machines' limitations, such as a 16-bit
address space.
Yet, just because assembly is becoming rarer is no grounds for
ignoring it altogether. CS stands for Computer *Science*, not Computer
*Applications*. The purpose of a CS degree or education is to
familiarize the student with an appreciation/overview of all the major
fields that have to do with computers and some of the mathematical
theory behind it. That is what makes us different from say, Cobol
programmers.
I may be one of the worst assembler-bigots around, but UMD5 has been
three different machines in the past 5 years (PDP-11, uVax, 750) and
I haven't writen a line of assembly code. I've had a Mac Plus for more
than a year, and haven't written a line of assembly code. It's quite
impressive that Megaroids (an "asteroids" clone for the Mac) is entirely
written in MegaMax C and suffers no lossage due to time constraints
(this kind of real-time environment is where any such lossage should show).
Bigot? I would say Freak! But, yes, the times, they are a changin'.
Certain machines, such as the 8080 or Z80, don't lend themselves well
to any HLL, and are barely tolerable in assembly. This is becoming
less true.
Yes, knowing some assembly languages can really help when dealing with
bogus compilers, and I have found bad code bugs in both the IBM Pascal
and Fortran H compilers by inspecting the machine language output.
True, but mostly all that stuff works. And so should any macros.
I used to write huge gory assembly macros, but stopped because none of
my co-workers could understand them. I still do macros, but simple ones
that only solve the task at hand, rather than huge gory packages that
try to be everything to everybody and end up being nothing to nobody...
Eventually we all mellow out. However, I see no distinction between
macros and functions/subroutines conceptually. Wanting to see the
generated code is not an argument against macros, as a good assembler
will do given an optional flag. As Ben points out, these macros should
be fool-proof, so as to be taken at face value.
Likewise, fear of typographical errors is not a valid concern. With that
kind of attitude, how would you ever type the expansion correctly. Yes,
confusion between pointers to objects and their actual contents is a concern,
but macros, as well as higher level languages, are more likely to be able
to check that they are invoked reasonably than the underlying instructions
which will often work with any mode operands.
In short, macros are there, so use them, but use them wisely.
Is it possible that the "ultimate dead language" comment on the AS man
page might be a comment on the PDP-11 instruction set itself, rather than
generically condemning all assembly languages? Since some of the wartier
"features" of C (undefined fill on right shift, promotion of float
to double on function call, etc) can be traced directly to the uglyness
of the PDP-11 instruction set, one can certainly sympathize...
I beg to differ. The PDP-11 has a BEAUTIFUL instruction set. How could
you possibly think otherwise? The PDP-11, more than any other machine,
has defined the essence of todays instruction sets. Sure it had some
warts, but everything does.
The ambiguity of C is more related to the differences *between*
machines than to any one particular droid.
umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92
umd2.BITNET "via HASP with RSCS"
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
While you're chewing, think of STEVEN SPIELBERG'S
bank account.. This will have the same effect as
two ``STARCH BLOCKERS''!doug@edge.UUCP (Doug Pardee) (05/28/87)
> The original posting regarding the availability of an acceptable assembler > for use in teaching an assembly language course seems to have sparked a > discussion concerning the need to teach assembler at all. Some of the > responses I have seen seem to imply that assembler is not needed at all, > and doesn't need to be taught. >... > The "unixness" of this forum really shows through in the type of comments > that are made here. Boy is that right. Look guys, just because there's not much use for assembler under *nix doesn't mean that assembler is unimportant in the outside world. There are a lot of non-*nix applications that absolutely /have/ to be done in assembler, and a good many more that /should/ be done in assembler. What gets my goat is the notion of teaching CS students that nothing exists in the computer world except C programming in *nix. You don't necessarily have to teach them assembler (or any other language), but they should be taught that there are lots of computer languages including assembler, and how to tell which language is appropriate for a given application. -- Doug Pardee -- Edge Computer Corp., Scottsdale, AZ -- ...!ihnp4!mot!edge!doug
mouse@mcgill-vision.UUCP (der Mouse) (05/31/87)
In article <5874@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > Please don't use /lib/cpp except as part of /bin/cc. > It is not intended for use as a general macro processor and may > indeed go away some day. A long way off. Too many things use /lib/cpp for it to disappear soon. Of course you are correct; one *should* use the -E option to cc, which is documented. I suspect the reason for using /lib/cpp is that cc -E won't work unless you have a file with a name ending in .c (no pipe input, no .s files....). > If you need a macro processor on UNIX, use m4. Except that m4 and cpp address things rather differently. Until you write a macro package for m4 that makes it behave like cpp (and I mean exactly like cpp), people will continue to use cpp. Existing code and existing skills ensure this. der Mouse (mouse@mcgill-vision.uucp)
jack@cwi.nl (Jack Jansen) (05/31/87)
In article <786@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >What gets my goat is the notion of teaching CS students that nothing exists >in the computer world except C programming in *nix. You don't necessarily >have to teach them assembler (or any other language), but they should be >taught that there are lots of computer languages including assembler, and >how to tell which language is appropriate for a given application. The point I (and a lot of others) tried to make is that you should *not* use assembler for an introduction course. The original posting gave the impression that the author wanted to use assembler to teach programming in general. This should not be done in assembler, but in some higher level language like Pascal or M2 (or, given unix, perhaps in C). As soon as students know about trees, hashtables and all that stuff, *then* you could start teaching assembler. This doesn't have to be a very extensive course, though. You should be able to assume that the students already know how to solve the problems presented, and the only thing they still have to is learn assembler (i.e. learn that, on every computer, there is a funny, all-powerful language, that can do everything, albeit rather difficult to use). Features that were asked for in the original (predefined macros, unified add instructions) are *bad* for this. They obscure the actual machine, which is exactly what you *don't* want in assembler. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
rbj@icst-cmr.arpa (Root Boy Jim) (06/01/87)
From: Doug Gwyn <gwyn@brl-smoke.arpa> Date: 20 May 87 19:34:41 GMT Please don't use /lib/cpp except as part of /bin/cc. It is not intended for use as a general macro processor and may indeed go away some day. Like much of `unix' in System V, dump, tar, nroff, ... Oh yes, tar is still there, altho deprecated, and you *can* get nroff, if you want to spend more money... If you need a macro processor on UNIX, use m4. I was going to ask if anyone *really* used m4 for anything besides sendmail config files, but I should have known: TPC actually *does* use m4 rather than cpp on its assembler files. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
shaffer@operations.dccs.upenn.edu (Earl Shaffer) (06/01/87)
In article <58900011@gorgo.UUCP> bsteve@gorgo.UUCP writes: > >BLETCH! > >This discussion is becomming totally pointless. I would not even consider >teaching assembly language with 'as' on the VAX. It is easy enough to recall >that in that environment 'C' IS the assembly language for the most part. > >Nevertheless, I do not believe that assembly language should be omitted from >the curriculum. It is an essential part of a student's introduction to >machine organization. > >The VAX is a nice choice for teaching assembly language, but only with the >VMS assembler. MACRO32 is probably one of the best assembly language >programming environments to be had anywhere. After all, it is still a real >programming language under VMS (not that this is good :-). > > Steve Blasingame (Oklahoma City) > ihnp4!gorgo!bsteve ****** I included the whole text because I had to ************ I AGREE!! Please, cant we drop the subject! It started as 'looking for an assembler' and then it got way out of hand. If you are a UNIX school, why teach assember at all. Teach C. If you have VMS (yea, I am not afraid to say I perfer VMS :-) then you use MACRO32. I believe that after careful inspection MACRO32 is a great language. But please, lets move on to something else. ============================================================================== Earl Shaffer - University of Pennsylvania - Data Communications Department "Time was invented so that everything wouldn't happen at once." Steven Wright ==============================================================================
mitch@stride1.UUCP (Thomas P. Mitchell) (06/02/87)
In article <238@emcard.UUCP> ron@emcard.UUCP (Ron Saad (Sys Admin)) writes: >In article <588@maccs.UUCP> ns@maccs.UUCP (Nicholas Solntseff) writes: >% In article <351@aucs.UUCP> wdw@aucs.UUCP (Bill Wilder) writes: >% >default assembler "as" suitable (i.e. friendly enough) for student use? >% There is NO macro assembler available for the VAX (unlike the PDP-11). I >There's no need to get super fancy - simple macros in m4 will go a VERY LONG WAY. In most cases the class would (should) be structured or layered. At the first students would work at the lowest layer 'raw machine language'. At this level binary, octal or hex input might be considered depending on the 'dues value'. After this simple "Assembly Language" without frills. Then the use of Macros and a preprocessor would be introduced to help with the building of data structures and other abstractions. What they will need is a very powerful debugging tool to see what their code does.. So the question may become: Are 'adb' and 'sdb' simple enough for a given class? Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably or hs.
gregg@okstate.UUCP (06/02/87)
in article <7401@boring.cwi.nl>, jack@cwi.nl (Jack Jansen) says: > Xref: okstate comp.unix.questions:2266 comp.edu:393 comp.lang.misc:398 > > In article <786@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >>What gets my goat is the notion of teaching CS students that nothing exists >>in the computer world except C programming in *nix. You don't necessarily >>have to teach them assembler (or any other language), but they should be >>taught that there are lots of computer languages including assembler, and >>how to tell which language is appropriate for a given application. > > The point I (and a lot of others) tried to make is that you should > *not* use assembler for an introduction course. The original posting > gave the impression that the author wanted to use assembler to > teach programming in general. > There are many different opinions on the values of assembly language. I for one favor having some sort of low level introduction to computers very early on. Several folks that I know that did not have this experience to this day still have problems coping with basic debugging. C can really give a person who has only used Pascal or PL/I fits. Esspecially things like comparing strings and copying strings. The most notable problems have to do with the 0 byte at the end of C strings, as well as overwriting other storage locations because not enough storage was allocated. An assembly language class in the early stages can really help to clarify what a compiler must generate, and how much work goes into moving data around. > > This should not be done in assembler, but in some higher level > language like Pascal or M2 (or, given unix, perhaps in C). > I for one do not favor the use of Pascal, unless lexical scoping is not used. While sometimes handy, lexical scoping can encourage folks to go crazy with using similar names for things, which can make programs entirely unreadable. Pascal (as well as PL/I) does provide array bounds checking, as well as other diagnostics that may help encourage better programming habits. > > As soon as students know about trees, hashtables and all that stuff, > *then* you could start teaching assembler. > As I said above, by this time, many folks may have problems seeing the machine as anything but magic. > > This doesn't have to be a very extensive course, though. > You should be able to assume that the students already know how to > solve the problems presented, and the only thing they still have to > is learn assembler (i.e. learn that, on every computer, there > is a funny, all-powerful language, that can do everything, albeit > rather difficult to use). > The last phrase, "albeit rather difficult to use", would seem to indicate why you do not favor teaching assembler early on. Given the proper setting, and instructor, wonderful things can happen. I taught myself Z80 assembler 6 months after I first touched a computer. Knowing that much about how computers worked when I started my COMSCI degree (1 year later), helped me more that anything I could have learned. I had a completely different view of things because I could visualize what a compiler might be doing that would cause a program to behave strangely. More than anything else, it has caused me to be extremely conscience about the execution time of all the code that I write. I know that each line of code is not just magic, but rather one or more machine instructions that take TIME to execute. > > Features that were asked for in the original (predefined macros, > unified add instructions) are *bad* for this. They obscure the > actual machine, which is exactly what you *don't* want in > assembler. > But, macros should be introduced at some point to show that it is possible to ease the use of the language. > -- > Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) > The shell is my oyster. ----- Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg ARPA: gregg@A.CS.OKSTATE.EDU
djfiander@watmath.UUCP (06/03/87)
> If you need a macro processor on UNIX, use m4. > > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> > National Bureau of Standards > Flamer's Hotline: (301) 975-5688 I would love to use m4. Unfortunately I've only seen one paper on its use by Kernighan and Ritchie. It was not the most introductory of texts. Could someone point me at a slightly more readable work. -- "Are you police officers?" "No ma'am, we're musicians." UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!djfiander CSNET : djfiander%watmath@waterloo.CSNET
elg@killer.UUCP (Eric Green) (06/07/87)
in article <2046@a.cs.okstate.edu>, gregg@a.cs.okstate.edu (Gregg Wonderly) says: > in article <7401@boring.cwi.nl>, jack@cwi.nl (Jack Jansen) says: >> In article <786@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >>>What gets my goat is the notion of teaching CS students that nothing exists >>>in the computer world except C programming in *nix. You don't necessarily >> >> The point I (and a lot of others) tried to make is that you should >> *not* use assembler for an introduction course. The original posting >> gave the impression that the author wanted to use assembler to >> teach programming in general. >> > > There are many different opinions on the values of assembly language. I > for one favor having some sort of low level introduction to computers very > early on. [...] > An assembly language class in the early stages can really help to clarify what > a compiler must generate, and how much work goes into moving data around. >> As soon as students know about trees, hashtables and all that stuff, >> *then* you could start teaching assembler. >> > > As I said above, by this time, many folks may have problems seeing the > machine as anything but magic. I don't see what trees, hashtables, and "all that stuff" has to do with assembly language. I, too, have seen the "magic black box" syndrome in action. I've seen juniors in CS who program in PL/1 or "C" (depending on machine used), who don't know the fogiest thing about what goes on at a lower level. Most of them have a VERY hard time figuring out what an operating system is, because while they've READ about computer architecture, they've never EXPERIENCED computer architecture. Experience which programming in assembly language gives you, real quick. The undergrad curriculum at USL doesn't even attempt to have the compiler class generate actual code for a real machine.... too few would be able to do it, I guess. When I first saw a computer in action (a TRS-80 running BASIC), I said "Wow, that's neat, I wonder what's inside it that makes it do that?". It's a shame that most of the people graduating from our college wouldn't be able to answer that question. It's an even bigger shame that most of them don't even CARE what's inside that "black box". My original major was Electrical Engineering precisely BECAUSE I wanted to see what was going on in there. Once I learned a little digital logic and played around with a little Z-80-powered trainer thingy, I switched to CS, but I still think that was a very productive experience and would recommend teaching digital logic and using primitive machines as a co-course with the usual freshman "squashing-semicolons" garbage. As for assembly language being hard... bah. I taught myself 6502 assembly language long before the Z-80 trainer, through the simple expedient of buying a VIC-20 and a monitor/mini-assembler (GAK! My age is showing!). The secret is to teach it on a simple machine where you can play with the hardware directly, rather than try teaching it on something like a Vax where you have to go through 50 levels of operating system just to print "Hello, world!". Alas, I've noticed that most CS professors have "microphobia"... they get nervous jitters when dealing with anything smaller than a Sun, and would probably go into fatal shock at the unpleasant thought of dealing with a simple, crude machine like a Commodore 64 or an Atari 130XE. A whole roomfull of which would cost less than a single Sun, and would be perfect for teaching assembly language and ELEMENTARY machine organization (have to crawl before walking, after all... expecting someone to understand the organization of an IBM 370 without understanding simple things like "what is memory? What is I/O?" is ridiculous). BTW, be great for the EE guys to do hardware experiments without fear of burning up a $5,000 development system, too.... -- Eric Green elg%usl.CSNET CS student, University of SW Louisiana {cbosgd,ihnp4}!killer!elg Apprentice Haquer, Bayou Telecommunications Snail Mail P.O. Box 92191 BBS phone #: 318-984-3854 300/1200 baud Lafayette, LA 70509 I disclaim my existence, and yours, too.
dhesi@rb442.UUCP (06/10/87)
In article <787@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <5874@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> Please don't use /lib/cpp except as part of /bin/cc. >> It is not intended for use as a general macro processor and may >> indeed go away some day. ... >> If you need a macro processor on UNIX, use m4. > >Except that m4 and cpp address things rather differently. Until you >write a macro package for m4 that makes it behave like cpp (and I mean >exactly like cpp), people will continue to use cpp. The simultaneous existence of /lib/cpp and m4, both of which do the same thing a little differently, has always perplexed me. The UNIX philosophy of different tools for different things makes sense. Here we have an aberration: Different things for the same purpose done a little differently. And though m4 is the more powerful package, it is also the one with the more convoluted syntax. I mean, really, look at this: define(compare,'ifelse($1, $2, yes, no)'). Most people would rather stick with the familiar #if..#else..#endif. Thus, although m4 is more than you need to teach assembly programming, it is also more than you deserve to have to cope with. I note with some interest that AT&T's new make utility includes a mechanism for decision-making using the syntax of /lib/cpp. One wonders (but not for very long) why m4 simply wasn't made a default macro processor for makefiles. I think /lib/cpp should be made an official part of UNIX and extended to cover the cases that only m4 can currently deal with. Then m4 should be gracefully moved to a resting place with a nice name like /usr/bin/obsolete until it fades away. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
debray@arizona.edu (Saumya Debray) (06/11/87)
In article <965@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: > I've seen juniors in CS who program in PL/1 or "C" (depending on machine > used), who don't know the fogiest thing about what goes on at a lower level. > Most of them have a VERY hard time figuring out what an operating system > is, because while they've READ about computer architecture, they've never > EXPERIENCED computer architecture. Experience which programming in assembly > language gives you, real quick. I agree that many CS majors are woefully unaware of the machines they're working with: I've seen many like that, too. But I'm not sure that assembly hacking is a panacea for this. The problem is that when tinkering with assembly language, it's all too easy to miss the forest for the trees. When I was an undergrad (back in India, in 1980), we first studied p-n junctions by solving (very approximately:-) the Schroedinger equation for a semiconductor lattice; then used this to derive an RC model of a transistor; and finally, used this, and standard circuit analysis, to derive the characteristics of a 7400 NAND gate, and matched our predictions with the data sheet of the chip ... One might argue that solving the electron flow equations for a p-n junction would give me a lot of insight into the workings of a VLSI chip, but I'm afraid most of us were too overwhelmed by the level of detail to get a feel for the big picture. The first computer I played with was an old PDP-11 that you booted by keying switches on the front panel. A lot of fun, and I got to memorise the machine code for the loader fairly quickly, but I doubt it gave me any great insight into PDP-11 architecture. -- Saumya Debray CS Department, University of Arizona, Tucson internet: debray@arizona.edu uucp: {allegra, cmcl2, ihnp4} !arizona!debray
roy@phri.UUCP (06/14/87)
In <1762@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes: about how he first solved p-n junctions, then transistors, then logic gates, then VLSI, but thinks the forest gets lost for the trees when you do it that way. I don't know about that. My education took roughly the same route (as a EE, not a CS major). It really helps sometimes to know what is going on at the really low levels. When configuring an ethernet, for example, you have to deal with very high level concepts such as IP routing and very low level concepts such as transmission line delays and impedence mismatch reflections. If you're getting double echos on a tty line, are you dealing with a mis-set tty driver mode or capacitive coupling in the cable? > The first computer I played with was an old PDP-11 that you booted by > keying switches on the front panel. A lot of fun, and I got to memorise > the machine code for the loader fairly quickly, but I doubt it gave me any > great insight into PDP-11 architecture. Again, I disagree. My first real intro to computer architecture came through learning machine language on a M6800 (I'd love to get my hands on a D2 kit again -- anybody have one laying around that they don't want?). The 6800 isn't too different from a pdp-11 (or a Vax or 68020 for that matter) and a lot of what I learned there still helps. I don't think you can really understand memory mapped I/O until you do a "sta $40A3" (or whatever the address was) and see an LED segment light up. Everytime I do a "stty", I can still see the bits being stuffed into the ACIA CSR. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
elg@killer.UUCP (Eric Green) (06/16/87)
in article <1762@megaron.arizona.edu>, debray@arizona.edu (Saumya Debray) says: > In article <965@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: >> I've seen juniors in CS who program in PL/1 or "C" (depending on machine >> used), who don't know the fogiest thing about what goes on at a lower level. >> Most of them have a VERY hard time figuring out what an operating system >> is, because while they've READ about computer architecture, they've never >> EXPERIENCED computer architecture. Experience which programming in assembly >> language gives you, real quick. >. The problem is that when tinkering > with assembly language, it's all too easy to miss the forest for the trees. > >. One might argue that solving the electron flow > equations for a p-n junction would give me a lot of insight into the > workings of a VLSI chip, but I'm afraid most of us were too overwhelmed by > the level of detail to get a feel for the big picture. So do it on a machine on which there IS no level of detail.... Programming a Commodore 64 in assembly language is hardly "immersing the person in details"... there just ain't much there to be called a detail! The point is for people to learn what basic architecture such as "what is memory?", "what is a machine language instruction", and "what is an operating system". On a machine with memory-mapped screen, for example, you might tell the students to "write our own chrout routine to print a character to the screen", just to let'em know that the "chrout" routine isn't magic... it's something that some programmer, somewhere, wrote. -- Eric Green elg%usl.CSNET CS student, University of SW Louisiana {cbosgd,ihnp4}!killer!elg Apprentice Haquer, Bayou Telecommunications Snail Mail P.O. Box 92191 BBS phone #: 318-984-3854 300/1200 baud Lafayette, LA 70509 I disclaim my existence, and yours, too.
markv@uoregon.UUCP (Mark VandeWettering) (06/24/87)
In article <1005@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >in article <1762@megaron.arizona.edu>, debray@arizona.edu (Saumya Debray) says: >> In article <965@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: >>> I've seen juniors in CS who program in PL/1 or "C" (depending on machine >>> used), who don't know the fogiest thing about what goes on at a lower level. >>> Most of them have a VERY hard time figuring out what an operating system >>> is, because while they've READ about computer architecture, they've never >>> EXPERIENCED computer architecture. Experience which programming in assembly >>> language gives you, real quick. There is no question in my mind that most CIS students don't have a clear perception about what happens on a computer at the lowest level. Then again, it is not immediately apparent that they need to. Programming is a task which can be done at many different levels. While programming in LISP, i don't have to worry about memory reclamation, and that is nice. While programming in C, I can use floating point easily, as well as generate moderately efficient code for real applications such as operating systems. >>. The problem is that when tinkering >> with assembly language, it's all too easy to miss the forest for the trees. Agreed. Programs are meant to solve problems. If you can concentrate on the problem, rather the program, you are winning big. Assembler often decays into a long sequence of "gee, okay, the carry is set now and lets add that to this thingy over here" sessions. >So do it on a machine on which there IS no level of detail.... > >Programming a Commodore 64 in assembly language is hardly "immersing the >person in details"... there just ain't much there to be called a detail! > Excuse me for a moment, fetching the Pepto-Bismol... :-) Actually, I think that programming the 6502 is a BAD and HARMFUL idea, mainly because it is such a pathetic processor. It can't even keep an address in a register. If I were to choose a processor to study, it would be the PDP-11 or the 68000. Both posess highly regular instruction sets which makes them easy to learn, and are high level enough so that you can write reasonable assembler programs. But I am still confused as to why we should use assembler. Very few of us will write operating systems in our lives. If we do, most of it should be written in some higher level language, with a few select (probably less than 10) routines written in assembler. I have done systems programming for two years on VAXEN, and have had no need whatsoever for assembler. It wasn't that I was afraid of it, just that it wasn't necessary. >The point is for people to learn what basic architecture such as "what is >memory?", "what is a machine language instruction", and "what is an operating >system". If they can answer any of these questions satisfactorily, they should have their doctorate already :-) Seriously, I think a great many people hinder their "natural brilliance" by parroting back preconcieved notions about what a computer is. To a LISP programmer, memory is this bunch of little cons cells. To a C programmer, it is bytes. To a programmer of the 80286 (bleh) it is segments and offsets. To a programmer of the iaxp432, it is a bunch of objects. Take your pick. What is a machine instruction? Well, it could be three address code like the vax. It could be stack machine instruction (P-code? Bourroughs 5500) It could even be RISC instructions. What is an operating system? To quote a student in a class here at the U of O: An operating system is a brain that can solve every kind of problem... I guess I have harangued long enough... ======================================================================== /////// ////// ******// ******/ "The original MTV since 1964" *******/*******/ ***********TTTV/ V Mark Terrence VandeWettering *****/*** **T*V/V (markv@uoregon.edu) *****/ * **T*VV "No matter where you go.. *****/ *****/ There you are!" *****/ *****/