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)
dhesi@bsu-cs.UUCP (05/16/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). How about just using the m4 macro processor or /lib/cpp? Given the UNIX philosophy of making separate tools work together, I'm not surprised that a built-in macro facility isn't considered something essential to an assembler. Besides, I see little educational value in students writing humungous assembly language programs with huge macros. I see greater value in their writing C programs and linking them with selected functions coded in assembly language. I even see value in giving them the assembled output of the C compiler and telling them to speed it up by 50% (or flunk). Assembly language is just one aspect of the big picture and ought to be treated as such. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
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: cjacksonphil@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
benson@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.
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
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.
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
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.
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
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.
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!" *****/ *****/