cdash@boulder.Colorado.EDU (Charles Shub) (05/18/87)
In article <6725@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <593@maccs.UUCP> ns@maccs.UUCP (Nicholas Solntseff) writes: >> [ discussion of assembly options in a unix environment portions deleted ] > >>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: > [ list deleted ] >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). > >So what is /bin/as missing, or what does it do wrong, that makes it >user-unfriendly? The biggest problem students, especially sophmores, face is that they need simplicity!!!! That means either some simple system calls like INCHWL on TOPS-20 assembler (input character, wait for line feed before returning) or macros (see almost any assembly text book) like read_w to read in word length integers. Students need to be able to write 20 to 30 line programs that do something reasonably useful. I have taught the machine organization and/or symbolic language programming course at several universities for almost 20 years using GE Macro Assembly Processor, Xerox Macro Assembly Program, TOPS-20 Macro, Vax Macro-11 under VMS, and IBM 360 BAL. I have also used a home grown processor for MIXAL [knuth, 1969] and several others. User friendly items include at least: 1. same mnemonic for adding (et. al.) irrespective of whether the operands are registers or memory cells 2. being able to give symbolic names (other than Rn) to registers. 3. identical syntax for accessing an address in either a memory cell or a register. 4. reasonable vehicles for parameters in macro definitions (an avid hater of ampersands here) for both positional and keyword parameters. 5. a reasonable selection of conditional assembly pseudos 6. EXCELLENT error diagnostics because students WILL make errors 7. good literal or remote assembly features so data can be written near the code using it (tops 20 was excellent about this) so students can invoke a print system call or macro and have what is being printed at the print statement rather than in a data block. 8. reasonably free form input (this was a problem way back when) 9. a good selection of pseudos for data generation and storage allocation that match the machine architecture. (I seem to recall one from the distant past that had an ARRAY pseudo that defined the symbol as 1 word less than the next free location so that if you put a 1 in a register and used indexing you got to the first reserved space. This was back before PASCAL so it was what the fortran programmers wanted to do) 10. A user friendly listing so students can see what is happening. I could go on a while, but this is getting long enough already. -- cdash aka cdash@boulder.colorado.edu aka ...hao!boulder!cdash aka ...nbires!boulder!cdash
jack@mcvax.cwi.nl (Jack Jansen) (05/19/87)
In article <663@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >The biggest problem students, especially sophmores, face is that they >need simplicity!!!! That means either some simple system calls like >INCHWL on TOPS-20 assembler (input character, wait for line feed before >returning) or macros (see almost any assembly text book) like read_w to >read in word length integers. There is another way to achieve simplicity: use the C library, and provide the students with a skeleton program. This is what my professor used to do. He provided us with a simple calculator (only addition and subtraction), and we had to add * and /, operator precedence, and one feature of our own choice, I think. This worked very well, and it had the added benefit that you learned the C calling sequence. That is what you write assembler for, isn't it, to use little assembly routines in big C programs.... > User friendly items include at least: I'll comment on some of these items. I've left out the ones on which I agree (or don't have an opinion on, or don't understand:-) >1. same mnemonic for adding (et. al.) irrespective of whether the operands > are registers or memory cells and >3. identical syntax for accessing an address in either a memory cell or a > register. No. This is very dependent on the machine. For instance, if you're programming assembler on a RISC machine (poor you), you'd better know where your operands are. >4. reasonable vehicles for parameters in macro definitions (an avid hater of > ampersands here) for both positional and keyword parameters. >5. a reasonable selection of conditional assembly pseudos I'm not sure. I think the C preprocessor should be used here. Especially since most assembler stuff will be used in a C environment under unix, and this allows you to use the same header files. The assembler should know about #line or some such, however, so that it can point you to the correct line in case of an error. Of course, if you want to teach students to use assembly for programming traffic lights using an 8080, you're in a different position altogether. You shouldn't be teaching them VAX assembler then, however. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
pdg@ihdev.UUCP (05/20/87)
Here is the solution to your assembler user-friendlyness woes. Get hold of a PDP/11 - a model with the toggle switches in front. Make the students do their first few programmes in machine language by entering them with the toggle swithes, one instruction at a time (of course there is no `editing' of the code, just replacement). Then let them loose on an assembler, *any* assembler. They'll be so happy to use it, they'll even settle for editing with 'ed'. Okay, half a :-). But actually I do agree with the m4 crowd - it works for me! -- Paul Guthrie "Another day, another Jaguar" ihnp4!ihdev!pdg -- Pat Sajak
jlo@elan.UUCP (05/20/87)
in article <1407@ihdev.ATT.COM>, pdg@ihdev.ATT.COM (Joe Isuzu) says: > Xref: elan comp.unix.questions:1931 comp.edu:261 comp.lang.misc:372 > > Here is the solution to your assembler user-friendlyness woes. > > Get hold of a PDP/11 - a model with the toggle switches in front. > Make the students do their first few programmes in machine language by > entering them with the toggle swithes, one instruction at a time (of > course there is no `editing' of the code, just replacement). > > Then let them loose on an assembler, *any* assembler. They'll be so > happy to use it, they'll even settle for editing with 'ed'. > > Okay, half a :-). You may give it half a :-), but that is *EXACTLY* what was done in the assembler class I took at UC Berkeley ~5 years ago. I think they were still teaching it that way about 3 years ago. After doing two assignments by flipping switches on a PDP 11/10 after standing in line for a while to get a chance to use one of the four (usually only two were working) machines, only to find out that the computer had died (literally, they were old machines, no OS to reboot, just bad hardware) we were ecstatic to get to use an assembler on a reliable machine. Jeff Lo ELAN Computer Group ..!{ames,hplabs}!elan!jlo
terryl@tekcrl.TEK.COM (05/21/87)
In article <167@elan.UUCP> tekcrl!tektronix!cae780!amdcad!ames!elan!jlo jlo@elan.UUCP (Jeff Lo) writes:
+in article <1407@ihdev.ATT.COM>, pdg@ihdev.ATT.COM (Joe Isuzu) says:
+> Xref: elan comp.unix.questions:1931 comp.edu:261 comp.lang.misc:372
+>
+> Here is the solution to your assembler user-friendlyness woes.
+>
+> Get hold of a PDP/11 - a model with the toggle switches in front.
+> Make the students do their first few programmes in machine language by
+> entering them with the toggle swithes, one instruction at a time (of
+> course there is no `editing' of the code, just replacement).
+>
+> Then let them loose on an assembler, *any* assembler. They'll be so
+> happy to use it, they'll even settle for editing with 'ed'.
+>
+> Okay, half a :-).
+
+You may give it half a :-), but that is *EXACTLY* what was done in the
+assembler class I took at UC Berkeley ~5 years ago. I think they were
+still teaching it that way about 3 years ago. After doing two assignments
+by flipping switches on a PDP 11/10 after standing in line for a while
+to get a chance to use one of the four (usually only two were working)
+machines, only to find out that the computer had died (literally, they
+were old machines, no OS to reboot, just bad hardware) we were ecstatic
+to get to use an assembler on a reliable machine.
Wow!!! It sure is nice that my good ol` alma mater is really keeping
up with state-of-the-art equiptment for the undergrad classes!!! 10 years
ago, at good ol` UC Berkeley, I was toggling in code to a PDP 11/05. Sure
is nice to know that at least they upgraded to an 11/10 in ~ 5 years (10-5).
And they have more than two, now??? We only had two machines *total* 10
years ago!!! Sounds like Berkeley is springing for the big bucks to finally
get a reasonable level of equiptment to support the class loads!!!!
But, then again, when I left 7 years ago, all of the undergrads were still
using PDP 11/70's (there were a couple of VAXes around, but they were only
for the grads).
(In case you haven't figured it out yet, insert MANY (-: here, but all
numbers quoted in this article are correct!!!).