Newsgroups: comp.edu,comp.lang.ada,comp.lang.c++,comp.lang.modula2,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.sprintlink.net!demon!uknet!gdt!uwe-bristol!sister!lr-lang
From: lr-lang@csm.uwe.ac.uk (Bob Lang 3P21 x3172)
Subject: Re: Comparison of languages for CS1 and CS2
Message-ID: <1995Jun28.124338@sister>
Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster)
Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster)
Organization: University of the West of England
X-Newsreader: xrn 7.03
References: <3pdnsi$i2v@urvile.MSUS.EDU> <EACHUS.95Jun19140040@spectre.mitre.org> <AST.346.2FE6B407@postman.hibo.no> <3s75k7$cji@news.ccit.arizona.edu> <DAs6GK.1D8@inmet.camb.inmet.com>
Date: Wed, 28 Jun 1995 11:43:38 GMT
Lines: 89
Xref: glinda.oz.cs.cmu.edu comp.edu:13025 comp.lang.ada:31836 comp.lang.c++:135598 comp.lang.modula2:11873 comp.lang.scheme:12966

In article <DAs6GK.1D8@inmet.camb.inmet.com>, arra@harp.camb.inmet.com (Arra Avakian) writes:
> In article <3s75k7$cji@news.ccit.arizona.edu>,
> Frank Manning <frank@bigdog.engr.arizona.edu> wrote:
> > [...]
> >After I picked up my jaw from the floor, I thought about it awhile, and I
> >was intrigued. Assembler would give the students a peek at what actually
> >happens in the guts of the machine, and maybe a higher-level language
> >wouldn't be such a mystery after that. Maybe that approach makes sense.
> >
> >Hmmmm...
> >
> >-- Frank Manning
> 
> I found this worked for me 35 years ago (SPS for IBM 1620 + Fortran
> II).  The SPS assembly language was believably dumb, revealing that the
> machine was not mysteriously "smart". The Fortran II mystified me,
> until I got to understand what a compiler was. By the way, this was
> between my freshman and sophomore years in high school, at an MIT
> summer course taught by Eliot Bird. (Is he listening?)
> 
> The Fortran compiler was quite literally awkward, consisting of
> several boxes of cards. You fed your source deck following the first
> pass of the compiler. It would punch out the object deck, which you
> would feed back into the card reader along with what I think was the
> linker/load/run time library. No disk or OS back then.
> 
With all this talk about assembler programming, I wondered if you might be
interested in our experiences with a second semester assignment we give to
first year computing students here at UWE.

The assignment consists of implementing a simulator/emulator for a very simple
micro-processor.  They have to simulate the Accumulator, Index Register,
Program Counter and Memory.  The machine can perform instructions like LDA,
ADD, SUB, conditional branches, and subroutine jumps.  They are given a list
of hexadecimal machine codes and a sample program to execute on the simulator.
To make it easier for them, we provide a library of useful utilities to handle
bit manipulation.  They are also given a lot of documentation and strong 
guidance.

We make the students work in small teams of mixed ability and tell them that
they will be marked on how well they all pull together.  Each team must first
produce a design which is checked by the tutor to find any obvious blunders.
Once the design is okayed, each team then goes on to implement their program.
As part of the marking process, we check that the implementation is a true
reflection of the design.  They can change the design retrospectively so
that bugs can be corrected.

Now, this sounds incredibly complex for first year students, but our
experience is they love it.  Although they all look worried when they first
consider the depth of the problem, by the time they have finished it, the
overwhelming response is great enthusiasm. Many students told me they wished
they had done it in the first (rather than the second) semester.

By the time the students have finished the simulator, their Modula-2 skills
have improved and they have gained a lot of knowledge about: Computer
Architecture and Machine code programming, Table driven software, Software
engineering methodologies and Team work.  Their confidence is also boosted
for the second year.

This year (and for the first time) we tried the same assignment with degree
level and HND level computing students (about 200 students).  There was no
appreciable difference between the work of the two groups, and both were
equally enthusiastic about it.  

There are two obvious questions:
1)  Did the teams delegate all the work to a small number of strong students,
    with the weak then getting the benefit?  It might have happened in a small
    number of cases, but we supervised quite closely to prevent this from 
    happening.

2)  Were there any teams that produced nothing?  
    No!  Even teams of weaker students produced gratifyingly good results.

Bob Lang
University of the West of England, Bristol

PS: An interesting extension would be to modify the program so that it
simulates input/output interrupts!  We've never taken it that far, however.

-- 
~    ~~~  ~~~~	    ~~   ~~~  ~~ ~~   ~~  ~~~~~  ~~~	 __	~~  ~~  ~~  ~
                                   		       _<Zx\	  _ -/
     Bob Lang			              		   ||  _-  -/  	_ 
     lr-lang@csm.uwe.ac.uk		                  // _- -_ -/_- /    
     University of the West Of England	               	 //_- _ - _/- =/     
					~~~~~  ~~~~~~~~ (_-_-_- =_-===_/ ~~~~~
~~~ ~~~~~~~~~~ ~~~~~~  ~~~~~~~~~   ~~~~~~~ ~~~~~~~ ~~~~~~~  ~~~~~  ~~~~~~~ ~~
  ~~~~~~~~  ~~~~~~~~~~~~  ~~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~      ~~~~~~~~ ~~

