Assembly vs. Everything Else (was: SemiOT: Mourning for ClassicComputing)

From: Derek Peschel <dpeschel_at_eskimo.com>
Date: Sun Aug 19 00:29:05 2001

On Sat, Aug 18, 2001 at 01:45:07PM -0700, Fred Cisin (XenoSoft) wrote:
> On Sat, 18 Aug 2001, Derek Peschel wrote:
> > I never said that fancy macros were for beginners! I was just pointing out
> > the extreme case of what you can do with a good macro processor. The
> > beginners WILL probably want to use the PRINT macro, however.
>
> I apologize. I was under the [apparently mistaken] impression that we
> were talking about beginners.

We were, but then I changed the subject. :)

> > Also, I mentioned languages with embedded assemblers, and that might be a
> > useful way to teach assembler -- by ignoring it at first and then using it
> > in small pieces.
>
> That might be very interesting.

Acorn designed a 6502-based computer for the BBC, called (natch) the BBC
Microcomputer. Sophie Wilson wrote a fine BASIC for the machine. When
Acorn designed the ARM chip and a line of computers based on that, the BASIC
got ported, but I don't know who did that work. I mentioned BBC BASIC in
another message, but only in passing.

It does all the usual "instant gratification" BASIC things but can
accommodate structured coding (REPEAT/UNTIL, multi-line functions/procedures
that take values and return results, probably other features). The
assembler is tied into the BASIC very nicely. You can access BASIC
variables from assembler and you can use BASIC programming to determine what
to assemble (I guess that would be a kind of macro processing).

It's not a perfect solution. It still allows spaghetti code. If you're
writing pure assembly (as opposed to mixed BASIC/assembly) a full assembler
might be less clumsy. But it's certainly very flexible in that you can
start with simple programs and work up to quite complicated ones.

Disclaimer: I haven't written any programs in the language myself.

> I knew one teacher whose first assignment involved a FOR loop. Her
> students were unable to coherently describe whether difficulties that they
> had were with the compiler or with their programming logic. Virtually
> none of her students made it to a second course.

Sad but occasionally true. I met a student in an intro CS course who
obviously didn't understand the idea of imperative programming (what happens
to variables as the program progresses, the fact _that_ the program
progresses, what WHILE loops do, etc.).

> I once hired one of their graduates. I fired him a few weeks later. He
> was unable to write a trivial program to print 3-up mailing labels from a
> name/address data file, because he couldn't figure out any way to do 3-up
> labels without knowing how to make the printer return to the top of the
> page!

I'm sure I could solve the problem pretty quickly. On the other hand, I
would put that task (or ones like it, but more elaborate) into the class
of "algorithms that look easy, but require more analysis and more weird
special cases than you would think at first". More elaborate tasks might
include:

        - Make the names run alphabetically down the first column
          of a page, then down the second, then down the third,
          then continue with the next page.

        - Make the names run alphabetically down the first columns
          of all pages, then the second, then the third.

        - (I did this recently in AWK) Change a file of the form

                jmp a1
                call a2
                jmp a2
                call a3

          into one of the form

                a1 jmp
                a2 call, jmp
                a3 call

        - If you really generalize things you get report generators
          or page-layout programs. I suspect those require a lot of
          care to get right.

Maybe I'm the only one with this view. Maybe I've gotten lazy after
graduating. Maybe the current programming languages make this sort of thing
harder than it ought to be. But maybe not. :)

-- Derek
Received on Sun Aug 19 2001 - 00:29:05 BST