Xref: utzoo comp.lang.c++:2205 comp.lang.c:14572 comp.lang.forth:726 comp.lang.fortran:1597 comp.lang.misc:2301 Path: utzoo!utgpu!watmath!clyde!att!ucbvax!hplabs!sri-unix!garth!tom From: tom@garth.UUCP (Tom Granvold) Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc Subject: Re: Assembly or .... Summary: Assembly language used for speed. Keywords: Assembly Message-ID: <2107@garth.UUCP> Date: 5 Dec 88 17:16:53 GMT References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <2025@garth.UUCP> <2005@crete.cs.glasgow.ac.uk> Reply-To: tom@garth.UUCP (Tom Granvold) Followup-To: comp.lang.forth Distribution: comp.lang.forth Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 49 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