Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!van-bc!zaphod.mps.ohio-state.edu!swrinde!kent From: kent@swrinde.nde.swri.edu (Kent D. Polk) Newsgroups: comp.realtime Subject: Re: AmigaDOS as realtime system? Message-ID: <1566@swrinde.nde.swri.edu> Date: 23 Feb 91 05:56:48 GMT References: Sender: news@swrinde.nde.swri.edu Organization: Southwest Research Institute, San Antonio, Texas Lines: 81 In article tims@infidel.lanl.gov (Tim Sullivan) writes: >I just saw a posting in which AmigaDOS was described as a realtime >multitasking operating system. Can anyone shed light on its realtime >abilities? > >Tim Sullivan (tims@infidel.lanl.gov) There have been two other postings which mention features of the Amiga operating system which qualify it as 'real time'. There is only one point which would call this classification into question, and it is that there are no guaranteed response times, and in fact, one process can easily take over the complete system. I believe this to be a very minor point, as in actual use, an Amiga attains typical response times which are easily an order of magnitude quicker that many other realtime OS's using the same processor platform. This is in a loaded configuration. For example, I use Amiga's for research-oriented real-time data acquisition and manipulation in a scheme which you probably have seen before - that of a 'conveyor belt' with typically one 'sampler' process which gathers data (in my case groups of waveforms and other info associated with an 'event') and places it in a shared mem buffer which is of variable size, according to how many 'events' I wish to buffer. A message is popped off of a message stack & associated with that event just placed in the buffer and sent to a message address obtained from a semaphore- controlled, doubly linked list of 'belt' processes. After the process at that message address is finished with the event, it passes the message along to the next in the list, until things get back to the sampler. Each message structure contains several items, including generic commands and intermediate results that are passed from one filter to another. Intermediate results are passed in the message structure to keep the data 'pure' for any filters which may want to take a snapshot of the data or tee off to other process paths. This semaphore-controlled list allows me to insert or delete 'filter' processes to operate on the data in any order at any time. Especially when data is moving through the belt. Individual filters can be controlled using the window/gadget environment extremely easily as I use a generic template which has to be filled out and linked with the main filter program which handles all of the 'belt' system overhead. I use the gadget-oriented approach to controlling my filters, as the very nice programming environment on the Amiga makes gadgets easier to program than any other method. Better get back to the subject. Anyway, some of my samplers pull data from multiple sources as the result of an event generated by an external interrupt. On a 25MHz equipped 68030 Amiga with 8 processes active on the belt and about 65 total tasks running on the system, response times for events with a 7 msec duty cycle as measured with a logic analyser were typically within 25 microseconds. The isr was written in 'C'. Since the external interrupts on the Amiga are shared, the isr first polled the hardware to determine if it generated the interrupt, read the system clock, two environment variables, 10 channels of waveform information, did some housekeeping and sent either 1 or 2 signals off to other processes to inform them of particulars that it found. This executed within 90 microseconds. So far I haven't seen the need to even optimise the C, much less do the isr in assembler. BTW, software interrupts even get a hardware assist, so they operate about an order of mag. faster too. The Amiga is so quick, responsive and easy to program compared to any other real-time system that I have used that I have been adopting it for for use in other low-end data-acq. research projects. It has turned into a very nice real-time lab front-end for our Sun network because of this and it's ease in blending in with the network in general. One thing I would also like to point out is that this system uses OS calls and resources entirely. No assembler is needed and the OS abounds with extremely useful functions such as the system linked-list manager which I use to handle all my lists. This box is easier to program than a unix box since it does use simpler mechanisms for IPC, but it's all there, and lots more fun to program on :^) Even after reading this simple example, wouldn't you agree that Amigas qualify as having a real-time OS? Thumbs up! Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent Brought to you by Super Global Mega Corp .com