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!!!).bill@ssbn.UUCP (Bill Kennedy) (05/24/87)
I have watched this discussion and just had to toss in my $.02. In my
observation of some bona-fide computer wizards it was not necessarily
the particular language or dialect that was in use that made them fully
understand what the problem and its cause was/were, it was their saavy
of what the compiler would do with a particular piece of source code.
I said the "problem" because that's the only time you get to see bona-fide
wizards. I have also worked with some of the brightest young "rookies"
that education has turned out and if they shared one ignorance it was
what the machine would do when given a particular piece of code. I was
once accused (incorrectly) of being a wizard because I diagnosed an un-
resolved external reference (in FORTRAN) as a missing DIMENSION. I did,
it was. It comes of knowing what the compiler will write, e.g. in the
brain damaged Intel world, char vs unsigned char produce entirely different
results if the MSbit is significant.
The point--- You don't have to know assembler to program but you'd best know
the machine you're working with and assembler is as good a way to learn that
as any I know, short of writing your own compiler (and you'd best know the
assembler for that!). It's far more important to know what "all machines do"
and then figure out how yours does "what they all do" and the idiosyncracies
of the one you're workihg with at the moment. Everybody doesn't have to be
a cybernetic veterinarian but those who carry "computer professional" creden-
tials should have a working understanding of "what they all do". Assembly
language programming (any assembler) is a good way to get that.
--
Bill Kennedy {cbosgd | ihnp4!petro | sun!texsun!rrm}!ssbn!billmarv@ism780.UUCP (05/27/87)
>The point--- You don't have to know assembler to program but you'd best know >the machine you're working with and assembler is as good a way to learn that >as any I know, short of writing your own compiler (and you'd best know the >assembler for that!). >-- >Bill Kennedy {cbosgd | ihnp4!petro | sun!texsun!rrm}!ssbn!bill I must disagree. I just finished implementing a Pascal compiler for an IBM/370 and I don't know any assembly for that machine. Furthermore, I don't even know what half of the instructions of machine do. The compiler does not generate any of the supervisory mode instructions so I did not have to learn them. More to the point, I think there two concepts one is exposed to when learning assembly language. One of them is macro processing. The other is machine architecture. The macro processing concepts can be taught by using any reasonable macro processor for examples. M4 is certainly a reasonable macro processor. As for learning machine architecture, most assembly languages tend to hide to some extent the architecture of the machine. I feel that machine architecture concepts are better taught with out reference to assembly language. Marv Rubinstein -- Interactive Systems
wanner@ethz.UUCP (05/29/87)
In article <687@ism780.UUCP> marv@ISM780.UUCP (Marvin Rubenstein) writes: > >I must disagree. I just finished implementing a Pascal compiler for an >IBM/370 and I don't know any assembly for that machine. Furthermore, I don't >even know what half of the instructions of machine do. The compiler does not How did you pick the right half of the instructions, if you don't know what the other half does?