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
new@udel.EDU (Darren New) (05/25/89)
In article <9881@watcgl.waterloo.edu> jvkelley@watcgl.waterloo.edu (Jeff Kelley) writes: >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.) A couple of nits: First, I think memory allocation disables only task switching, not interrupts. Second, a trivial upper bound can be determined by checking how many tasks can be around at once (memsize / TCB size). Also, 1/60 second is a good upper bound, lest you loose the display. Third, I would think that the task switch described above could be done without turning off the interrupts since interrupt code is not allowed to look at such structures, let alone change them. However, I haven't look at the code myself, so I am in no position to argue. But are you sure it is Disable() and not Forbid() that is used? -- Darren
addison@pollux.usc.edu (Richard Addison) (05/26/89)
In article <16182@louie.udel.EDU> new@udel.EDU (Darren New) writes: >A couple of nits: First, I think memory allocation disables only >task switching, not interrupts. Second, a trivial upper bound can >be determined by checking how many tasks can be around at once >(memsize / TCB size). Also, 1/60 second is a good upper bound, >lest you loose the display. Note that the copper takes care of maintaining the display (yes, even interlaced) even when the 68000 doesn't respond to interrupts. Richard Addison "I've got a hole in me pocket." -- Ringo
new@udel.EDU (Darren New) (05/26/89)
In article <17441@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >Note that the copper takes care of maintaining the display (yes, even >interlaced) even when the 68000 doesn't respond to interrupts. I thought you had to re-stuff the start-of-copper-list out to the copper address registers during the vblank. Or can the copper do that to itself? (I don't think so, but it's been a while since I looked at that stuff...) -- Darren
addison@pollux.usc.edu (Richard Addison) (05/27/89)
In article <16286@louie.udel.EDU> new@udel.EDU (Darren New) writes: >In article <17441@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >>Note that the copper takes care of maintaining the display (yes, even >>interlaced) even when the 68000 doesn't respond to interrupts. > >I thought you had to re-stuff the start-of-copper-list out to the >copper address registers during the vblank. Or can the copper >do that to itself? (I don't think so, but it's been a while >since I looked at that stuff...) -- Darren Well, I went and double checked myself, and here's the low down: The copper's "first location register" is set to the copper list startup instructions (which sets the background color and initializes the sprite pointers): Custom.cop1lc = GfxBase->copinit; This copper list startup code strobes Custom.copjmp2 after waiting for the top of the video field in order to jump to the "second location register." Note that this will be either: Custom.cop2lc = GfxBase->LOFlist; or: Custom.cop2lc = GfxBase->SHFlist; The tail end of these two copper lists stuffs Custom.cop2lc with the address of the opposite copper list and then waits for an impossible display position. All is not lost, though, because the vertical sync pulse comes along to trigger a jump to Custom.cop1lc! Thus, once it is set up, the copper takes care of the display for you! PS. In case anyone cares, I ordered custom license plates for my car today: GFXBASE Richard Addison "...and watch out for the Blue Meanies!"
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/29/89)
In article <17463@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >PS. In case anyone cares, I ordered custom license plates for my car >today: GFXBASE > I thought Dale would have grabbed that one already. Hmmm... Well, Dale, what are you going to use now? Schwab
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/30/89)
Leo 'Bols Ewhac' Schwab <ewhac@well.uucp> writes in message <11884@well.UUCP>
> Well, Dale, what (licence plate) are you going to use now?
Probably BOING!
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