Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!okstate!gregg
From: gregg@okstate.UUCP
Newsgroups: comp.unix.questions,comp.edu,comp.lang.misc
Subject: Re: Teaching Assembler on VAX (BSD 4.3)
Message-ID: <2046@a.cs.okstate.edu>
Date: Tue, 2-Jun-87 13:43:03 EDT
Article-I.D.: a.2046
Posted: Tue Jun  2 13:43:03 1987
Date-Received: Thu, 4-Jun-87 06:52:58 EDT
References: <7401@boring.cwi.nl>
Organization: Oklahoma State Univ., Stillwater
Lines: 90
Xref: utgpu comp.unix.questions:2357 comp.edu:375 comp.lang.misc:419

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