Assembly or ....

[Fraser Orr]

In article <2025 at garth.UUCP> tom at garth.UUCP (Tom Granvold) writes:
>    I write diagnostics that test the hardware in computer systems which
>makes me a member of very small minorty of programers.  While reasonable
>memory tests can be written in languages such as C or Forth, many other
>tests require assembly language.  For example in the newer CPU's, especially
>RISC chips, it is becomming common to have pipelining of instruction
>execution and register scoreboarding.  In order to reasonably test these
>features, one must be able to specify exactly whe sequence of instructions
>that are to be executed.

I agree, in some very isolated cases asm is necessary, testing hardware is
one such case. Not many of us have to do that though, and again, this is
not using asm for "speed" and "code compactness", neither of which is,
in my ever so humble opinion, a good or valid reason for writting asm.

>     The second need for assembly is in real time control.  In my previous
>job we were using a Z80 to control several stepper motors.  The critical
>timing restrictions accured in the interrupt routines.  While there were
>high level languages available for the Z80 none, that we were aware of,
>were optimizing compilers.  Therefore we were able to produce much faster
>code in assembler.  This was a case where every machine cycle was of
>importance.  The most importent comment in the source code was the number
>of machine cycles each instruction took.  Yes we could have used a newer
>faster CPU that has  optimizing complier available for it, but Z80's are
>cheap!

Sorry I don't entirely grasp what you are saying. Firstly you say speed
is crucial here, I don't agree that programming in asm necessarily gives
significant improvments in speed, but then you seem to imply that what your
interested in is exact timing information. I used to write programs in asm
and spent a lot of time "optimising" them (in fact I once spent about 2 months
on and off improving one critical subroutine, sutting it down from something
like 35 micro secs to 26) these made little difference to the final product.
Moreover it meant that the software was always behind schedule. Anyway see
the above comments.
I would also say that if you ever try to do this on more complicated processors
like the 68k and RISCs, then good luck to you, the timing is unbelievably
complicated, with caches and pipelines and all that.

>Thomas Granvold


==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK)
UseNet: {uk}!cs.glasgow.ac.uk!orr       JANET: orr at uk.ac.glasgow.cs
ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk at nss.cs.ucl.ac.uk