MROBINSON@wash-vax.bbn.com (05/24/89)
Is AmigaOS truly a real-time OS? I mean, I know it doesn't have much overhead for context switches, and I know the message passing is designed to be as lean as possible, but real-time? I'm not entirely clear on what Forbid() and Permit() do (if I find a case where I feel I need some synchronization, semaphores will be my first choice, and only in the direst emergency would I ever use these bad boys), but I don't think they automagically create a real-time OS. To me, real-time means that each system call is guaranteed to complete within a *defined* amount of time (which should be small). Like, if the time limit comes along and the call is not done, it unwinds and fails, and still manages to finish trying within the defined time limit. Does AmigaOS have these defined durations for the system calls? Where do I find the durations in print? If AmigaOS is only nearly-realtime, or "real-time if one surrounds the system call that needs to be completed in a stated amount of time with Forbid() and Permit()", please don't call it real-time. That would be as bad as calling MacOS multi-tasking (yes, I know, MultiFinger IS non-preemptively multi-tasking, but that means that sometimes the Mac won't act like its multi-tasking, just like a nearly real-time OS will sometimes not act like its real-time). How about NRT for nearly real-time? Un*x and such are of course NRT (not real-time) -- maybe surreal-time :) --Max Robinson mrobinson@wash-vax.bbn.com
jvkelley@watcgl.waterloo.edu (Jeff Kelley) (05/25/89)
In article <16100@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: > >Is AmigaOS truly a real-time OS? No. >To me, real-time means that each system call is guaranteed to complete >within a *defined* amount of time (which should be small). The definition I use: Real-time: The ability to respond to REAL-world events, such as interrupts, in bounded TIME. The AmigaOS, and in particular Exec, disables interrupts for arbitrarily long periods of time. For example, when a task loses the CPU because a higher priority task becomes ready, interrupts are disabled while the lower priority task is 'Enqueue'd on the task ready list, an operation for which, in general, an upper bound on the time cannot be specified. There are likely other areas, e.g. memory allocation, where similar situations occur (though I've only looked at the code for context switches.) The AmigaOS is not real-time, but it is typically responsive. This is due in part to the fact that it does not support virtual memory but primarily because of well designed system hardware and a kernel designed to be efficient and lightweight (just not real-time...) I still love my Amiga, though. Real-time is nice, but isn't essential unless you're a missile tracking a jet fighter or a control circuit in a nuclear reactor deciding whether or not to shut it down. -- Jeff Kelley National Research Council of Canada, Ottawa uunet!watmath!watcgl!jvkelley tel: (613) 990-5924
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/25/89)
:>To me, real-time means that each system call is guaranteed to complete :>within a *defined* amount of time (which should be small). : :The definition I use: : :Real-time: The ability to respond to REAL-world events, such as interrupts, : in bounded TIME. Heh! Just for the hell of it I'll give you all my definition. A Real-time OS is able to give a process CPU within the upper and lower bounds relative to an event where the bounds are specifiable by the process. An event can be anything from a hardware interrupt to a timer signal to another process's sending of a message, etc... Suddenly, the problem becomes more difficult, eh? :I still love my Amiga, though. Real-time is nice, but isn't essential :unless you're a missile tracking a jet fighter or a control circuit :in a nuclear reactor deciding whether or not to shut it down. Yes, exactly. A *real* real-time OS works by an entirely different set of rules. -Matt
451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) (05/26/89)
In article <16100@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: > Is AmigaOS truly a real-time OS? > To me, real-time means that each system call is guaranteed to complete > within a *defined* amount of time (which should be small). Yes, the Amiga OS is truly real-time. But your definition of real-time is not good. Real-time means that system can respond to an event (or interrupt) within a definite amount of time. The Amiga Exec is quite a standard real-time executive, as you see them in text books. The processing of one or several real-time events is dependent very much of how you set priorities and how and when you wish to mask them. Real-time programming remains the task of highly qualified computer scientists and engineers. If you wish to set time limits on function calls, it is very easy for you to create a new task which is to be awaken after a precise amount of time after it is first signalled. So you can get the exact functionality of that 'other' system you mentioned. Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) (05/26/89)
Jeff Kelley <jvkelley@watcgl.waterloo.edu> writes in Message-ID: <9881@watcgl.waterloo.edu> > The AmigaOS, and in particular Exec, disables interrupts for arbitrarily > long periods of time. For example, when a task loses the CPU because a > higher priority task becomes ready, interrupts are disabled while the lower > priority task is 'Enqueue'd on the task ready list, an operation for which, > in general, an upper bound on the time cannot be specified. > > There are likely other areas, e.g. memory allocation, where similar > situations occur (though I've only looked at the code for context switches.) Ridiculous. I suggest you take a look at Markus Wandel's EXEC disassembly. All Real-time kernels have to disable multitasking while manipulating system lists. Furthermore these manipulations are only a few instructions long. On the Amiga, any task is allowed to disable interrupts for no more than 250 nanoseconds. The EXEC itself abides by this defined limitation, and very loosely. Furthermore, the Amiga's interrupt hardware sets it apart ingeneously. Let me suggest some further reading material to you, it will help you understand greately how the Amiga does what it does so well. These books sure helped me on my project: 1. EXEC reference manual, CBM, Addison-Wesley 1986. Be sure to read all of it. Disregard the part where they tell you to use Forbid() all over the place. Carl was really sick when he instructed that. 2. EXEC disassembly, Markus Wandel, Fred Fish (186?) 1989. Boy this guy sure is good at commenting disassembled programs! 3. Guru's Guide #1: Interrupts, Carl Sassenrath, Sassenrath Research, 1987. Even with the EXEC disassembly, you will still learn a lot from the designer of the EXEC him-self. Includes nice diagrams and examples in C. 4. 68000 User's Guide 6th edition, Motorola, Motorola Inc. 1989. Look at the timing tables. Even at a mere 7.16 MHz, the 68000 can still manipulate those lists within the requires 250 ns. > The AmigaOS is not real-time, but it is typically responsive. This is due > in part to the fact that it does not support virtual memory but primarily > because of well designed system hardware and a kernel designed to be > efficient and lightweight (just not real-time...) Whoa! You are very confused. Virtual memory has *nothing* to do with real-time systems. In fact none of the target (non-devellopment) real-time systems in this world support virtual memory. Your friends at the National Research Council (Canada) are working on Harmony, the ultimate real-time operating system. Ask Dr. Gentleman, he should know better! > I still love my Amiga, though. Real-time is nice, but isn't essential > unless you're a missile tracking a jet fighter or a control circuit > in a nuclear reactor deciding whether or not to shut it down. ...Or a cumputer with a graphical user interface controlling a multi-tasking environment... > Jeff Kelley National Research Council of Canada, Ottawa Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
deven@rpi.edu (Deven Corzine) (05/26/89)
In article <16284@louie.udel.EDU> 451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) writes:
On the Amiga, any task is allowed to disable interrupts for no more
than 250 nanoseconds.
Isn't the suggested maximum time 250 *microseconds*? 250 nanoseconds
is barely enough time for a couple of memory accesses... Think. I
doubt Amigas have faster than 100ns RAM, and the cycle time is double
that. Which would mean two memory accesses within your 250 ns limit.
Not very feasible, eh?
(a nanosecond is a billionth of a second...)
Deven
--
shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America
deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.karl@sugar.hackercorp.com (Karl Lehenbauer) (05/27/89)
In article <8905242302.AA21440@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > :>To me, real-time means that each system call is guaranteed to complete... > :The definition I use: > :Real-time: The ability to respond to REAL-world events, such as interrupts, > : in bounded TIME.... > A Real-time OS is able to give a process CPU within the upper and... By the way, if you are into realtime don't forget to subscribe to the relatively new group, comp.realtime. -- -- uunet!sugar!karl | "Woof!" -- free Usenet access: (713) 438-5018
chad@cup.portal.com (Chad The-Walrus Netzer) (05/28/89)
In a previous article (Max Robinson) writes:
)Is AmigaOS truly a real-time OS?
No, The Amiga is one of the first computers in the world to use an
Imaginary-time operating system. In fact, if you hold an Amiga perpendicular
to a real-time OS computer, you can make Mandelbrot sets...
PS. This is not meant to sound mean... Just a bit of zany, sarcastic humor to
lighten everyone's day and make the world a better place to be. Thank you for
listening...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chad 'The_Walrus' NETzer
"'Cause you know sometimes words have no meaning"
-Led Zep. "Stairway ..."
doug@xdos.UUCP (Doug "It's A Feature" Merritt) (05/29/89)
In article <16284@louie.udel.EDU> 451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) writes: >Furthermore these manipulations are only a few instructions long. On the Amiga, >any task is allowed to disable interrupts for no more than 250 nanoseconds. Wow! Now that's what I call *responsive*. I knew the Amiga was fast, but that's really amazing. >The EXEC itself abides by this defined limitation, and very loosely. Very loosely indeed, I would say. At about a 125 nanosecond clock, that's two cycles. As I recall the fastest instructions take *three* clocks. So either the EXEC accomplishes everything it needs to do in 2/3rds of an instruction, or else it violates this guideline (at least to the extent of executing one whole instruction). I wonder which it is? :-) >1. EXEC reference manual, CBM, Addison-Wesley 1986. > Be sure to read all of it. Disregard the part where they tell you to use > Forbid() all over the place. Carl was really sick when he instructed that. Yes indeed. I, too, am very fond of gurus. >3. Guru's Guide #1: Interrupts, Carl Sassenrath, Sassenrath Research, 1987. > Even with the EXEC disassembly, you will still learn a lot from the designer > of the EXEC him-self. Includes nice diagrams and examples in C. Truly a great book. The book is actually copyright 1988 and only just hit the streets recently. I hope Carl does many more books in the series. >4. 68000 User's Guide 6th edition, Motorola, Motorola Inc. 1989. > Look at the timing tables. Even at a mere 7.16 MHz, the 68000 can still > manipulate those lists within the requires 250 ns. Hmmm. Apparently you really believe this. Must be that newfangled new math. >Whoa! You are very confused. Ah, er, um, no comment. :-) >Virtual memory has *nothing* to do with real-time systems. I'll buy that. >[ comments about what real time systems are good for deleted ] >...Or a cumputer with a graphical user interface controlling a multi-tasking > environment... Excellent point. Sorry I poked a little fun there, it was hard to resist. No offense intended. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
peter@sugar.hackercorp.com (Peter da Silva) (05/29/89)
That depends on what you mean by real time. It's not good enough for an F-16, but it's plenty real-time enough for soft real-time tasks like SCADA or video-games. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
doug@xdos.UUCP (Doug Merritt) (05/31/89)
In article <18874@cup.portal.com> chad@cup.portal.com (Chad The-Walrus Netzer) writes: > No, The Amiga is one of the first computers in the world to use an >Imaginary-time operating system. Are you sure? I'd been told (by People Who Should Know) that the IBM PC had an imaginary operating system. >In fact, if you hold an Amiga perpendicular >to a real-time OS computer, you can make Mandelbrot sets... Ah, a little math humor. Clever; separate the men from the boys, eh? A little in-joke, nudge, nudge, know what I mean? A nod's as good as a wink to a blind bat, eh? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
daveh@cbmvax.UUCP (Dave Haynie) (06/01/89)
in article <16284@louie.udel.EDU>, 451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) says: > On the Amiga, any task is allowed to disable interrupts for no more than > 250 nanoseconds. The EXEC itself abides by this defined limitation, and > very loosely. Umm, perhaps you were thinking microseconds here? Considering that the minimum memory cycle time for a standard 68000 based Amiga is 558ns, that number is clearly absurd. I guess on a 68030 system, you could actually complete an instruction or two in that 250ns :-) > Valentin -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession