PETCHER%SVDSD@eg.ti.COM (03/04/88)
uplherc!sp7040!obie!wsccs!wes@gr.utah.edu (Barnacle Wes) replies: > In article <8802202149.AA07429@ajpo.sei.cmu.edu>, PETCHER%SVDSD@eg.ti.COM > writes: > > Mike Linnig asks: > > > My question is... are we losing something here? Is there > > > a value to having multiple priorities even if we don't > > > have preemptive scheduling? > > > > My answer is an emphatic YES. > > [...] > > This means, among other things, a task should not execute > > indefinitely, and in fact should be designed to complete its intended > > function within a predictable period of time. This is consistent with most > > actual embedded applications, where a processor has certain inputs producing > > data at some predictable rate, and each task has some part in processing this > > data and producing the aggregate output of the system at some required rate. > This is a workable, but simplistic viewpoint. The C3 systems I have worked > on tended to be rather large and complicated, both in their scope and > implementation. These systems typically had several background tasks... Keep in mind the original question. I agree, there are systems that have complexities that make multiple priorities meaningless without preemptive scheduling. However, that fact does not prevent multiple priorities with non-preemptive scheduling from having a value, as I attempted to illustrate. > the drum device driver is passed the address of a routine to execute when > the I/O operation has completed. The driver does this by scheduling the > routine in the I/O call at the time when the I/O operation will be > completed. For a variety of reasons, once this routine is scheduled, it > needs to execute ASAP according to the priority scheme used in the system. There are a lot of reasons for using preemptive scheduling, but urgent I/O is not one of them. That's what interrupts are for. Granted, we all get stuck softwaring our way around a stupid hardware design (look at me, I'm trying to juggle interrupts for a real time application in an IBM AT clone!) However, a well designed interrupt structure can make a non-preemptive system work for a fairly complex application. On another issue, Fred Stluka <stluka%software.org@relay.cs.net> writes: > However, the LIB$EMUL and LIB$EDIV routines do no more than the EDIV and > EMUL instructions. That is they do *not* operate on 64 bit operands > returning 64 bit results. To produce true 64 bit operators, you have > to use break up the operation into smaller parts (as mentioned by Sam > Harbaugh). This is not as trivial as it seems but it can be done. It is actually as easy as doing (a+b)*(c+d)=a*c+a*d+b*c+b*d, where a and c are the high order parts and b and d are the low order. If a and c are both nonzero it's an overflow. If a*d+b*c produce a result larger than 32 significant bits it's an overflow. Otherwise shift the last result left 32 bits and add b*d. There are probably some esoteric things to do if one of the numbers is negative, but the whole mess ought not be that complicated. > The biggest problem you encounter is in avoiding spurious integer overflows > caused by intermediate results exceeding 32 bits. Many of the intermediate > results you generate will be 32 bit quantities which you would like to > think of as unsigned because they are to become the low order part of a > signed 64 bit number. However, there is no way to tell the VAX that > a 32 bit quantity is unsigned. Therein lies the only complication, and it only exists if one or both of the operands is negative. A simple solution is to compute the sign first, make both operands positive, do the multiplication, then make the result negative if necessary. Granted, this is not the most efficient way, but if we were going for efficiency we wouldn't be doing LIB$ calls, would we? Of course, I have only addressed multiplication here, not division, which is a bit more complicated, and on computers is usually done using either Booth's algorithm or magic, whichever is easier. Malcolm Petcher