acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) (11/24/89)
Since people seem to be posting their favourite lies from computer
reps, I thought I'd add this one I heard from an IBM demo guy at the
Northeast Computer Show. We were discussing the virtues of the
Motorola 68020 vs. the Intel '386, and he came out with this beauty:
"Well, of course segmented architecture enables you to produce tighter,
more modular code."
Craig.
///
///
\\\///
\XX/ acm131@eric.ccs.northeastern.edumike@ames.arc.nasa.gov (Mike Smithwick) (11/26/89)
In article <4737@nigel.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: > > >Since people seem to be posting their favourite lies from computer >reps, I thought I'd add this one I heard from an IBM demo guy at the >Northeast Computer Show. We were discussing the virtues of the >Motorola 68020 vs. the Intel '386, and he came out with this beauty: > >"Well, of course segmented architecture enables you to produce tighter, >more modular code." > > > Craig. Hey, that's nothing. Check out the December issue of Compute's "Amiga Resource" magazine, page 13. Arlan Levitan went "under cover" to a number of PeeCee/EssTee/Mack dealers playing dumb and asked about the Amiga. In the writeup he gives 10 responses he received, some bordering on slander. A must read if you need your blood pressure raised. (Example : "The Amiga is an overpriced, modified C64", or "Amiga 500 power supplies are dangerous and had started fires in people's homes by shorting out. . .") happy reading! mike *** mike smithwick *** "When I was 18 I joined the centrifigal Air-force" [disclaimer : nope, I don't work for NASA, I take full blame for my ideas]
doug@xdos.UUCP (Doug Merritt) (11/29/89)
In article <4737@nigel.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: > >Since people seem to be posting their favourite lies from computer >reps, I thought I'd add this one I heard from an IBM demo guy [...] >Motorola 68020 vs. the Intel '386, and he came out with this beauty: > >"Well, of course segmented architecture enables you to produce tighter, >more modular code." Devil's advocate coming up. But first: I *HATE* segmented architectures! Ok, that said, he's not altogether wrong. But it should be rephrased: "...*forces* you to write more modular code". Mostly :-) about that part. There's nothing wonderful about being forced to break huge data structures into smaller 64K chunks. Nor for code, for that matter. But. He's (partially) right on target about tighter code. Granted segments are a pain in the ass, but code written using 16 bit pointers plus pain-in-the-ass workarounds for dealing with other 64K segments *IS* often tighter than code that uses purely 32 bit pointers. Such code can maybe a third smaller on the 68000, and smaller yet on 80x86's (due to sometimes more compact instruction coding). My usual rebuttal to *that* argument is: sure, but you *can* use 16 bit offsets rather than 32 bit pointers on the 68000, too, and for small programs, people often tell the C compiler to use small model to do exactly that. But there's a counter-rebuttal: it's much, much harder to do this for *large* programs on the 68000, due in part to the 68000's architecture (16 bit offsets are not supported by all instructions that allow 32 bit pointers), and in part due to limited support by C compilers, and even in part by the definition of the C language (i.e. it's more feasible to do this for large programs in assembler than in C). And more to the point, people usually don't try to use "small model" constructs/compiler modes with large programs, whether written in C or not. But then it gets complex, because if someone *does* make the attempt, then you can counter-argue that the result will be tighter on the 68000 than on the 80x86 due to the larger register set and more orthogonal architecture. And in my experience, this tends to be the last word. The Intel architecture *forces* people to use more compact constructs than does the 68000, but when people try to be compact on the 68000, it's an even bigger win than it is on the 80x86. It's a really big win to have lots of registers. This is part of the reason that RISC machines do well on benchmarks (not the only reason, but look at the kludgy Clipper processor...it's very slow for a RISC in part because of its small register set). So back to the salesman: he's right, and he's wrong. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
rehrauer@apollo.HP.COM (Steve Rehrauer) (11/29/89)
In article <4737@nigel.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: >Since people seem to be posting their favourite lies from computer >reps, I thought I'd add this one I heard from an IBM demo guy at the >Northeast Computer Show. We were discussing the virtues of the >Motorola 68020 vs. the Intel '386, and he came out with this beauty: > >"Well, of course segmented architecture enables you to produce tighter, >more modular code." Well, the "tighter" portion of that statement can be true, IF you can live within a segment for whatever you're doing (code or data). But the headache of handling segment-spanning cases more than makes up for it, in my opinion -- give me a flat address-space any day! -- >>"Aaiiyeeee! Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com "Flee, lest we be trod upon!" | The Apollo System Division of H.P.
acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) (11/30/89)
In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> writes: > Ok, that said, he's not altogether wrong. But it should be rephrased: > "...*forces* you to write more modular code". Mostly :-) about that part. > There's nothing wonderful about being forced to break huge data structures > into smaller 64K chunks. Nor for code, for that matter. 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? > So back to the salesman: he's right, and he's wrong. > Doug > -- > Doug Merritt {pyramid,apple}!xdos!doug > Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary Craig. /// /// "Hey OS/2, wanna race???" \\\/// \XX/ acm131@eric.ccs.northestern.edu
rogers@iris.ucdavis.edu (Brewski Rogers) (11/30/89)
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? > > /// "Hey OS/2, wanna race???" > \XX/ acm131@eric.ccs.northestern.edu page zero? I thought only 6502's had zero page stuff to worry about? Maybe the IBM salesman thought the Amiga ran on a 6502. Well, maybe the IBM salesman's right, the IBM w/80386 multitasks a little bit better than a commodore 64. Where do these people get these ideas? Its a weird and stupid world we live in. ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "It's better to be the real thing than the right thing." \________/ Quark!
limonce@pilot.njin.net (Tom Limoncelli) (11/30/89)
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? Is there any multitasking OS that swaps between tasks/processes by swapping all of page 0? I can't think of any. Is this the technique that Mac's Switcher (is that what it's called?) or any of the similar programs for the Atari ST do? "Page 0" reminds me of "Zero Page" mode" like on the 6502. I remember Chris Lane (of Yale) published some code that permitted a VIC-20 to multitask. It swapped page 0, 1 and 2 (the stack) and the registers. It was so slow that rather than swapping every quantum, each program would have to SYS to a memory location once in their main loop. ( Now that I'm off the subject... ) He even hacked with the video chip to get a really bad split screen; each with a different program running. It was amazing! Each screen was at a different memory location and there was a interrupt driven routine that would switch which video buffer was being displayed at whichever starting scan-line. You couldn't predict when a IRQ would happen (in relation to the raster) so he did these crazy timeing loops and it flickered horribly. Ugh. But it was great to watch. Later when the Commodore-64 was shipping I was amazed because split-screens could be done as easily as writing a couple bytes of 6502 code. Is Chris net.accessible? Maybe we should have a vote for comp.sys.i.remember.the.vic.20? :-) Ok. I've rambled enough, -Tom -- Tom Limoncelli -- limonce@pilot.njin.net -- tlimonce@drunivac.bitnet rutgers!njin!tlimonce -- Drew University, Madison, NJ -- 201-408-5389 "All's well that ends well... if your a functional rationalist."
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (12/01/89)
From article <Nov.29.22.45.00.1989.15112@pilot.njin.net>, 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)
daveh@cbmvax.UUCP (Dave Haynie) (12/01/89)
in article <5003@nigel.udel.EDU>, acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) says: > In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> > writes: >> There's nothing wonderful about being forced to break huge data structures >> into smaller 64K chunks. Nor for code, for that matter. > Well, according to the IBM rep, there *is*. ... 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. First of all, nothing I've heard of in recent times needs to copy page 0 in and out. Who'd do something that foolish? Multifinder? In any case, that would be multitasking programs never designed to multitask in the first place. Real multitasking on the Amiga doesn't require anything like that for a context swap, and no modern UNIX would either. This guy is obviously a salesman, and I bet he's not a bad comedian either... On the other hand, you might ask him what happens to segmented architectures when you want virtual memory, like under OS/2. It's much the same reason they added paging (though rather primitive compared to the '030's paging) to the '386 and use it under real operating systems like UNIX. He might not know, but based on the lines he's fed you so far, it's a fair question and I'd like to hear the answer he comes up with. >> Doug -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
jtreworgy@eagle.wesleyan.edu (12/01/89)
In article <5003@nigel.udel.EDU>, acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: > In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> > writes: > >> Ok, that said, he's not altogether wrong. But it should be rephrased: >> "...*forces* you to write more modular code". Mostly :-) about that part. >> There's nothing wonderful about being forced to break huge data structures >> into smaller 64K chunks. Nor for code, for that matter. > > 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? > He's full of it... the Amiga doesn't copy code in and out of page 0 (maybe a Macintosh does for task switching)... the Amiga simply uses relocatable code. The 33Mhz PS/2 was not designed with task switching in mind. However, doesn't the '386 fix the 64k chunk problem (in virtual mode)? I think it has something like 2^32 bit chunks instead of 2^16 bit chunks. > > Craig. > > /// > /// "Hey OS/2, wanna race???" > \\\/// > \XX/ acm131@eric.ccs.northestern.edu -- James A. Treworgy -- No quote here for insurance reasons -- jtreworgy@eagle.wesleyan.edu jtreworgy%eagle@WESLEYAN.BITNET
lsr@Apple.COM (Larry Rosenstein) (12/02/89)
In article <Nov.29.22.45.00.1989.15112@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: > Is there any multitasking OS that swaps between tasks/processes by > swapping all of page 0? I can't think of any. Is this the technique > that Mac's Switcher (is that what it's called?) or any of the similar > programs for the Atari ST do? The Macintosh does maintain some global state in low-memory, and MultiFinder has to swap the variables that are task-specific. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
fenske@dfsun1.electro.swri.edu (Robert Fenske Jr) (12/02/89)
In article <4385@eagle.wesleyan.edu> you write: >In article <5003@nigel.udel.EDU>, acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: >> In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> >> writes: >> of copying the entire contents of page zero, out and in, etc. etc. Of ^ ^ Does ANY OS do this sort of thing now days? I thought this stuff went out with the '70's. > >However, doesn't the '386 fix the 64k chunk problem (in virtual mode)? I think >it has something like 2^32 bit chunks instead of 2^16 bit chunks. > Yes, in protected mode the '386 has 32-bit offsets; coupled with the 16-bit selectors makes for a 64TB virtual address space (should be enough for the '90's :-) ). I believe it also has a flat space mechanism where all the selectors are effectively 0, giving a more normal 4GB address space. -- Robert Fenske, Jr. Sw | The Taming the C*sm*s series: Electromagnetics Division /R---\ | Southwest Research Institute | I | | "The Martian canals were the dfsun1.electro.swri.edu 129.162.160.4 \----/ | Martian's last ditch effort."
doug@xdos.UUCP (Doug Merritt) (12/03/89)
In article <1469@dfsun1.electro.swri.edu> fenske@dfsun1.UUCP (Robert Fenske Jr) writes: >>> [ attribution lost: ] >>> of copying the entire contents of page zero, out and in, etc. etc. Of > ^ > ^ >Does ANY OS do this sort of thing now days? I thought this stuff went out >with the '70's. Yes, Minix does this, at least on the Atari and on the semi-mythical Amiga port of it. It's been a long time, but if I recall correctly even on the PC it does task switching by copying the contents of the address space around, to get around the lack of MMU. So it's even worse than just "page zero". Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
a218@mindlink.UUCP (Charlie Gibbs) (12/05/89)
In article <5003@nigel.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: >In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> >writes: > >> Ok, that said, he's not altogether wrong. But it should be rephrased: >> "...*forces* you to write more modular code". Mostly :-) about that part. >> There's nothing wonderful about being forced to break huge data structures >> into smaller 64K chunks. Nor for code, for that matter. > >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? He's giving you crap, whether he realizes it or not. Change context by reloading segment registers? What about the rest of the registers? I know Intel doesn't like having too many registers, but I can't think of very many programs which would appreciate having their registers trashed by a context switch. Of course, a clever Intel salesman could argue that having fewer registers is actually an advantage because there's less to save and restore :-) but unless the 286 or 386 has an equivalent to the 68000's MOVEM instruction I can't see much time being saved. Besides, a 68000 program which accesses things relative to address registers uses those address registers the same way an 80x86 program uses segment registers, except that it's not limited to a 64K segment size. Heck, even Intel realizes that 64K segments suck rocks; the 386 lifts that limitation, although it's too late for MS-DOS victims. And speaking of crap, what's all this about shuffling the contents of page zero? What operating system does that as part of a context switch? Bravo for nailing him on the multitasking capability. Of course, before OS/2 came along, there was always the stock IBM answer: "If we don't have it, you don't need it!" It'll be a while yet before IBM devotees truly appreciate multitasking the way we have been doing for four years now - but eventually they'll come to enjoy it, and will remain forever grateful to IBM and Microsoft for "inventing" it. Flame off. OBJ: Q: What's the difference between a computer salesman and a used car salesman? A: The used car salesman knows when he's lying. Charlie_Gibbs@mindlink.UUCP "I could never get the hang of ideology. I do the rock, myself." -- Tim Curry
acm131%eric.ccs.northeastern.edu@cunyvm.cuny.edu (12/06/89)
In Message-Id: <544@xdos.UUCP> Doug Merritt <doug@xdos.CCS.Northeastern.EDU> writes: > Ok, that said, he's not altogether wrong. But it should be rephrased: > "...*forces* you to write more modular code". Mostly :-) about that part. > There's nothing wonderful about being forced to break huge data structures > into smaller 64K chunks. Nor for code, for that matter. 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? > So back to the salesman: he's right, and he's wrong. > Doug > -- > Doug Merritt {pyramid,apple}!xdos!doug > Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary Craig. /// /// "Hey OS/2, wanna race???" \\\/// \XX/ acm131@eric.ccs.northestern.edu
rogers%iris.ucdavis.edu@cunyvm.cuny.edu (12/07/89)
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? > > /// "Hey OS/2, wanna race???" > \XX/ acm131@eric.ccs.northestern.edu page zero? I thought only 6502's had zero page stuff to worry about? Maybe the IBM salesman thought the Amiga ran on a 6502. Well, maybe the IBM salesman's right, the IBM w/80386 multitasks a little bit better than a commodore 64. Where do these people get these ideas? Its a weird and stupid world we live in. ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "It's better to be the real thing than the right thing." \________/ Quark!
limonce%pilot.njin.net@cunyvm.cuny.edu (12/07/89)
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? Is there any multitasking OS that swaps between tasks/processes by swapping all of page 0? I can't think of any. Is this the technique that Mac's Switcher (is that what it's called?) or any of the similar programs for the Atari ST do? "Page 0" reminds me of "Zero Page" mode" like on the 6502. I remember Chris Lane (of Yale) published some code that permitted a VIC-20 to multitask. It swapped page 0, 1 and 2 (the stack) and the registers. It was so slow that rather than swapping every quantum, each program would have to SYS to a memory location once in their main loop. ( Now that I'm off the subject... ) He even hacked with the video chip to get a really bad split screen; each with a different program running. It was amazing! Each screen was at a different memory location and there was a interrupt driven routine that would switch which video buffer was being displayed at whichever starting scan-line. You couldn't predict when a IRQ would happen (in relation to the raster) so he did these crazy timeing loops and it flickered horribly. Ugh. But it was great to watch. Later when the Commodore-64 was shipping I was amazed because split-screens could be done as easily as writing a couple bytes of 6502 code. Is Chris net.accessible? Maybe we should have a vote for comp.sys.i.remember.the.vic.20? :-) Ok. I've rambled enough, -Tom -- Tom Limoncelli -- limonce@pilot.njin.net -- tlimonce@drunivac.bitnet rutgers!njin!tlimonce -- Drew University, Madison, NJ -- 201-408-5389 "All's well that ends well... if your a functional rationalist."
tron1@tronsbox.UUCP (HIM) (12/21/89)
>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 This IBM rep is not really with it. To do multitasking on a OS that has been DESIGNED for it , you only change contexts by changing stacks and registers. On "single user" OS's , where programs have been written with HARD CODED addresses for DOS cals and all, you would have to load "page 0" and execute from there. THE REASON the Amiga OS doesnt USE any fixed addresses is in part to avoide some of this. (Its late , I know what I am trying to say , but can't say it well. **************************************************************************** "Perfume and leather baby , you and me together baby, what good is living in paradise, if you don't let yourself once or twice." -Tiffany Kenneth J. Jamieson ---- THE BOSS at Xanadu Enterprises Inc. UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, The Penthouse ]I[ BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
cmcmanis@stpeter.Sun.COM (Chuck McManis) (12/22/89)
The original comment was :
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.
And as usual a lot of helpful people gave their interpretation of what he
meant such as this one :
In another article Kenneth J. Jamieson writes:
This IBM rep is not really with it. To do multitasking on a OS
that has been DESIGNED for it , you only change contexts by
changing stacks and registers.
All of the explanations are well and good. As a former Intel employee
I can imagine the information that the sales critter actually heard and
how he translated it.
One of the big "features" of the x86 [x > 2] architecture is that the
processor is _designed_ to multitask. What this means is that there is
a hardware notion of what a task is and the CPU can deal with those as
individual units. One of the ways in which it does this is through 'gates'.
When an important even occurs such as an exception or an interrupt, the
CPU switches tasks and stores all of the context for the previous task
and loads all of the context for the new task.
This can be an advantage or a disadvantage depending on how you look at it.
Take something innocuous like hardware multiply, the M88000 RISC chip has
it and the SPARC RISC chip doesn't. Both can multiply though.
The page zero reference was undoubtedly pointed at the Macintosh which has
some absolute references in the OS but this kind of situation can occur
whenever you build an OS without an MMU unless you are careful.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"