#: 8926 S12/OS9/68000 (OSK)
    28-Dec-90  10:27:07
Sb: #8918-#68000 ASM Language
Fm: Ed Gresick 76576,3312
To: Jack Crenshaw 72325,1327 (X)


Hi Jack!

First, you have my vote for a new assembler.

A little background - I probably spend about half of my time programming or
reviewing/testing programs written by others.  Most of this is with data-base
languages.  Occassionally, I have to get into C and/or Assembler.  While I
don't employ full-time programmers, I do employ several part-time programmers
as I need them.  When they work in assembler or C, they all use 'tools' of
various sorts to 'improve' their efficiency.  (I'm not convinced that's
necessarily true.)  When I have work done in C, I insist that the code pass a
'lint' test.  These programmers rely on volumes of libraries of sub-routines
and macros they(?) have previously written.  I doubt I get the most efficient
code possible this way but the way these people have been trained and simple
economics require that I accept the code (so long as it works and meets the
requirements I had specified).

I remember one bit of assembler code that gave me a real fit.  Most of the time
(three or four months), the program worked fine.  Occassionally, it reacted in
a weird fashion.  Took me a long time to find the error - the programmer had
tested the wrong condition code (which really wasn't a test at all in this
case).  The code fragment was -

          .                          (What it might look like under
          .                           your proposed assembler)
          .
          lea table(pc),a6              a6=table
          move.b (a6,d5.w),d7           d7=a6+offset or d7=a6+d5
          bne there                     'if n bit set' goto there
          .                             No, the first line above is wrong.
          .                             that would put the contents in d7
                                        we want the address so - why not
                                        'a6=adr(table)'





There are 2 Replies.