Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!ukma!rutgers!att!cbnewsc!gregg From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly) Newsgroups: comp.sys.amiga Subject: Re: Lies, lies, they're telling us lies... Message-ID: <5160@cbnewsc.ATT.COM> Date: 30 Nov 89 18:55:34 GMT References: Organization: AT&T Bell Laboratories Lines: 84 From article , by limonce@pilot.njin.net (Tom Limoncelli): > In article <5003@nigel.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: > >> Well, according to the IBM rep, there *is*. And this is one place where I >> couldn't figure out if he was giving me a line of crap or not. But he said >> that segmented architecture makes multi-tasking more efficient, because to >> change context you merely reload the code, data, and stack segments. Instead >> of copying the entire contents of page zero, out and in, etc. etc. Of > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> course, whe I pressed him as to why 8 Mhz Amiga 1000's with 512K can >> multi-task better than his 33Mhz PS/2's he had no satisfactory answer, >> but still... for future reference, I'd like to know, is this a legitimate >> issue? Originally, way back when, UN*X used to move things around so that the current processes U structure was located at an absolute location in the kernels address space. This may have been something like what he as alluding to. The 80[23]86 processors segment registers contain what is actually an index (segment selector) into the segment descriptor table. Whenever the segment registers are reloaded, the contents of the segment descriptor table entry indexed by the loaded value is loaded into the processor (expensive 8-16 byte read). The 80[23]86 solution to the task switching problem is the TSS (Task State Segment). This is a segment with a descriptor in the GDT (Global Descriptor Table) which has a special attribute (read special bit set). Any time that the selector for this segment is loaded into CS via a JMPI or CALLI instruction, the state of the current task (registers etc) is saved in the area of memory described by the contents of the GDT descriptor indexed by the current value in the TSR (Task State Register, another segment register if you will). The registers are then loaded from the area of memory described by the destination segment selector (the offset is ignored) which is then loaded into the TSR. We ported XINU to the 80286 in school, and used this mechanism to context switch. It provided a very clean mechanism. Each task had a TSS in its proc[] entry with a descriptor for that segment in the GDT. Task switching still involves saving and restoring some number of hardware registers. The cheapest task switch comes from processors which support mulitple register sets. The TMS9900 has only 3 hardware registers, the PC (program counter), ST (status) and WP (Workspace Pointer). WP points into memory where the next 32 bytes are used as 16 general purpose registers. Of course this is expensive in terms of memory access, but a well designed 9900 based application would use ultra fast RAM for the register area of memory. The BLWP (Branch and Link with Workspace Pointer, bullwhip for short) instruction of the 9900 places the previous WP in R13, the the previous PC in R14 and the previous ST in R15. Thus you had complete access to the calling procedures environment (and as far back in the chain of calls as you wanted to go). The resulting RAM based applications were generally pretty nasty because people got into the habit of passing arguments relative to the PC as in ... BLWP @foobar DEFW parm1,parm2,parm3 ABS R0,R0 BEQ badcall ... regs2 DEFS 32 FOOBAR DEFW regs2,$+2 MOVL (R14)+,R1 Get the parameters MOVL (R14)+,R2 MOVL (R14)+,R3 ... RTWP Return to caller The other neat thing is that you could use BLWP with the target being the registers as in "BLWP R1". The register are address would then be taken from R1 and the new PC value from R2. Oh well, enough of the past... -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)