Assembly or ....

[Tom Granvold]

I orginally wrote:

>>     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!

Then Fraser Orr replied:

>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 wasn't too clear in what I was trying to say.  We had several things
that needed to be serviced periodly which included four stepper motors and
a pump.  The timing of events was controled by setting up interrupts to
occur when some action was needed, say when it was time to step one of the
motors.  Therefore the relative timming of events was not the major concern.

    Our concern was that each of the interrupt routines had to execute as
quicly as possible so that it would delay other interrupts as little as
possible.  The number of machine cycles was counted in order to know how
long the interrupt routine took.  Whenever we changed the routine in order
to speed it up, we knew if we made an improvement simply by comparing the
machine cycle totals.  Yes this did take a lot of time, but the improvements
were noticable, for example the motors ran smoother and the positioning
accuracy improved.

>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.

We it becomes very difficult, if not impossible, to count machine cycles
for the processors you mention.  But if the processor is fast enough, the need
to count cycles is no longer needed because it is more than fast enough.

Thomas Granvold