tga@eleazar.dartmouth.edu (Greg Ames) (02/16/90)
In article <1990Feb15.155556.5319@uncecs.edu> dlugose@uncecs.edu (Dan Dlugose) writes:
:Any new low end Mac will be bought by a lot of people who will want to
:upgrade it and do more a year or two later.
:
: [discussion of why the 68000 can't support virtual memory nuked
: to save the net millions in phone costs! :-) ]
:
: "The 68000 lacks the ability to restart an instruction following
:a memory fault, but the 68010 permits the instruction to be continued
:after the condition that caused the fault to be corrected" supporting
:virtual memory. So I believe the minumum chip would be a 68010 AND
:MMU chip, which might use more power than a 68030 with its on board
:memory management.
And I may be going out on a limb saying this, but didn't the original
Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory?
I was under the impression that they came out before the 68010. If so,
how did Sun do it? The MMU could be implemented in custom hardware,
but what about restarting instructions in mid-stream? (I was under
the impression the 1/XX's used 68000's, the 2/XX's used 68010's, and
the 3/XX's used 020's and, later, 030's).
Greg
--
Greg Ames, '90 | tga@eleazar.Dartmouth.EDU
HB 1362 | ...!{harvard,linus,inhp4,etc}!dartvax!eleazar!tga
Dartmouth College |
Hanover NH, 03755 | { This space available for rent! }dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (02/16/90)
tga@eleazar.dartmouth.edu (Greg Ames) writes: >And I may be going out on a limb saying this, but didn't the original >Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory? >I was under the impression that they came out before the 68010. If so, >how did Sun do it? The MMU could be implemented in custom hardware, >but what about restarting instructions in mid-stream? I just might be showing how gullible {sp??} I am here but I seem to remember someone explaining to me that they ran 2 68000's one behind the other, in the case of a page fault they'd use the 2nd one to restart the instruction from the "primary" 68K. Anyone care to confirm or deny this outlandish story. I'd really like to find out if it's correct. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | Graduating in March of 1990, with a BS in Computer Science | |_That should make several people at Poly happy.______________________________|
rgm@sandstorm.Berkeley.EDU (Robert Menke) (02/16/90)
In article <19472@dartvax.Dartmouth.EDU> tga@eleazar.dartmouth.edu (Greg Ames) writes: >And I may be going out on a limb saying this, but didn't the original >Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory? >I was under the impression that they came out before the 68010. If so, >how did Sun do it? The MMU could be implemented in custom hardware, >but what about restarting instructions in mid-stream? (I was under >the impression the 1/XX's used 68000's, the 2/XX's used 68010's, and >the 3/XX's used 020's and, later, 030's). I'm going out on a smaller limb by answering this, but I do know of a method to implement VM with an original 68000. What you do is have TWO processors, with one running just behind the other. When the first one bus-faults, the secondary one is halted, the missing page is loaded in, and the secondary one switches places with the original primary one. Not exactly sure if it was Sun who pulled this rabbit out of a hat or not, though. Can anyone out there confirm? >GIVE COIN TO CHARON | Robert Menke "So educated," giggles the voice in | rgm@OCF.berkeley.edu your ear... | Robert.Menke@bmug.fidonet.org
amanda@mermaid.intercon.com (Amanda Walker) (02/17/90)
In article <22145@pasteur.Berkeley.EDU>, rgm@sandstorm.Berkeley.EDU (Robert Menke) writes: > What you do is have > TWO processors, with one running just behind the other. When the > first one bus-faults, the secondary one is halted, the missing page is > loaded in, and the secondary one switches places with the original > primary one. Not exactly sure if it was Sun who pulled this rabbit > out of a hat or not, though. Can anyone out there confirm? [a moment while I search through my brain's backup tapes...] I think it was Motorola themselves who first suggested this. When the 68000 first came out, they issues a bunch of "application notes" showing things like example memory interface circuitry, use of VPA, and so on. One of these was an example of doing virtual memory with a two-processor system. When a page fault occured, processor A just went into a wait state, processor B woke up, swapped in the page, and then woke up processor A again. Kind of a kluge, but it did work. The 68010 was a big improvement. Trivia quiz: anyone remember the 68012? -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
paul@taniwha.UUCP (Paul Campbell) (02/17/90)
In article <19472@dartvax.Dartmouth.EDU> tga@eleazar.dartmouth.edu (Greg Ames) writes: >And I may be going out on a limb saying this, but didn't the original >Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory? >I was under the impression that they came out before the 68010. If so, >how did Sun do it? The MMU could be implemented in custom hardware, >but what about restarting instructions in mid-stream? (I was under >the impression the 1/XX's used 68000's, the 2/XX's used 68010's, and >the 3/XX's used 020's and, later, 030's). I'm sure a 100 people will answer this but .... I think that the original Suns got around this by having TWO 68000, the primary one never took a bus error for a page fault .... instead it took a long 'wait state' while the secondary one got fired up to handle the page fault .... a number of companies used this scheme ..... Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P You know there's something wrong when 100,000 people marching in Moscow make page 1 and 400,000 in Washington don't .....
cruff@ncar.ucar.edu (Craig Ruff) (02/18/90)
>>And I may be going out on a limb saying this, but didn't the original >>Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory? I'm surprised no one has gotten this correct yet. The Sun-1 didn't have virtual memory. It swapped like a PDP-11. It wasn't until the Sun-1.5 (which led to the Sun-2) that contained a 68010 that demand-paged virtual memory was used. I remember the Sun-1.5 had a version of BSD4.1 running on it. This quickly gave way to the Sun-2 and BSD4.2. That was before the days of SunOS. -- Craig Ruff NCAR cruff@ncar.ucar.edu (303) 497-1211 P.O. Box 3000 Boulder, CO 80307
mo@flash.bellcore.com (Michael O'Dell) (02/18/90)
Sorry folks, but the first Sun-1 cpu board did NOT do demand-paged virtual memory because it had 1 68000. The upgraded board, which became the basis of the Multibus-1 Sun-2 machines had a 68010 on it, which was a 68000 which could fault and restart. I think the first commercial machine I know of using the dual processor trick to do demand paging was an Apollo, but the Masscomp machines also used the trick, and I don't remember who was out first. Masscomp was out early, however, with a demand paged system system running Unix and twin 68Ks. FOr its time, the Masscomp box with all the slick A/D and D/A hardware and software made one hell of a demo! -Mike -Mike O'Dell "I can barely speak for myself, much less anyone else!" ---------------------------------------- The Center for Virtual Reality -- "Solving yesterday's problems tomorrow!"
paul@taniwha.UUCP (Paul Campbell) (02/19/90)
In article <1990Feb16.164414.6377@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Trivia quiz: anyone remember the 68012? Yes, between their higher cost (more pins ment a different package style), the much higher cost of memory in those days, and the brain-damaged MMUs people were building then (24-bit or smaller virtual address spaces mostly because of the high cost of SRAM) did them in. Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P You know there's something wrong when 100,000 people marching in Moscow make page 1 and 400,000 in Washington don't .....
rwa@cs.AthabascaU.CA (Ross Alexander) (02/19/90)
tga@eleazar.dartmouth.edu (Greg Ames) writes: >And I may be going out on a limb saying this, but didn't the original >Sun's (the 1/XX series) use a 68000 to run Unix and virtual memory? >I was under the impression that they came out before the 68010. If so, >how did Sun do it? The MMU could be implemented in custom hardware, >but what about restarting instructions in mid-stream? (I was under >the impression the 1/XX's used 68000's, the 2/XX's used 68010's, and >the 3/XX's used 020's and, later, 030's). Sun 1's indeed use 68K's. They _don't_ do VM. 7th edition doesn't need VM. Ask anyone who runs minix ( obligatory :-) on an Atari ST or a Mac. Or Xenix on a Tandy 6000, to name a more common example. 7th edition requires protection and relocation, nothing more. Restartable instructions aren't needed; PDP-11's didn't have them. An external base-and-limit register (a hardware hack) watching the bus and diddling the addresses visible to memory is all that's needed to do this on the 68K. Maybe 10 chips in MSI. You do need to keep track of what kind of bus cycle you are looking at (User data/instr/stack, intr, Super data/instr/stack, & c.) This is not hard. A trick you can use in a 7th edition environment to _fake_ growable stack segs it to insert a "tst -nnn(sp)" where nnn is the size of the stack frame for the function being entered as the first instruction of every function. If the instr faults, the OS trap handler adjusts the limit register value for the stack segment and finds your process a little more memory. It's easy to restart a tst instruction (it has the nice property of being idempotent :-). This is an optimization, however, and isn't compulsory. -- -- Ross Alexander (403) 675 6311 rwa@aungbad.AthabascaU.CA VE6PDQ
roy@phri.nyu.edu (Roy Smith) (02/19/90)
In <1672@aurora.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: > 7th edition requires protection and relocation, nothing more. > Restartable instructions aren't needed; PDP-11's didn't have them. I fear we're going to degenerate into historical nit-picking, but I don't think that's quite right. Some 11's did indeed have restartable instructions. If you had the full-blown 18-bit memory management unit (like an 11/45) there was a register which kept track of which GP registers had been incremented (or decremented), and by how much, before an instruction faulted. With that information, you could back out any state changes the partially-executed instruction might have caused and restart. I remember mucking around in the 6th edition kernel to get it to run on an 11/34 (which was sort of, but not quite, an 11/45 when it came to memory management). In the code that dealt with growing the stack, there are some comments to the effect that lacking the inc/dec status information (which the 11/34 indeed lacked), you could almost always intuit what registers had been changed by examining the contents of the stack and looking at the instruction that had just been executed. There were some pathalogical cases, however, where it was not possible, and in that case you had no choice but to kill the faulting process. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy "My karma ran over my dogma"
tomj@oakhill.UUCP (Tom Johnson) (02/20/90)
Amanda Walker: >Robert Menke: >> What you do is have >> TWO processors, with one running just behind the other. When the >> first one bus-faults, the secondary one is halted... >[a moment while I search through my brain's backup tapes...] > >I think it was Motorola themselves who first suggested this... >...One of these was an example of doing virtual memory with a two-processor >system. When a page fault occured, processor A just went into a wait state, >processor B woke up, swapped in the page, and then woke up processor A >again. > Very Close...actually, when a memory fault occurs due to the "primary" 68K making a memory access, the bus error was returned to the "secondary" 68K as an interrupt (and no DTACK to the primary). The interrupt handler on the secondary 68K then issues (via external logic) a RELINQUISH & RETRY request (i.e. HALT, BERR, and BR) to the primary processor. The primary would 1) terminate the current bus cycle and prepare to run it over, and 2) give up the bus. The secondary processor then fixed up memory, did an RTE followed by a STOP instruction, and awaited another "interrupt" to wake it up again. This caused the secondary processor to give up the bus, and allowed the primary processor to have the bus back again. It proceeded to run the "faulted" cycle over again, using the same address, data, etc. >Trivia quiz: anyone remember the 68012? > Of course, but as someone pointed out, lifetime buys have already been accepted. The part was originally made especially for a "large customer" who wanted the virtual memory capability AND a large address space. A more interesting trivia question: What address line was missing on the '012, and WHY? >-- >Amanda Walker >InterCon Systems Corporation Tom Johnson Motorola, Inc. Disclaimer (as much as I hate them): Don't take anything I write, speak, dream, or moan as in any way representing anything Motorola might believe.
dwb@archer.apple.com (David W. Berry) (02/22/90)
In article <1990Feb16.164414.6377@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Trivia quiz: anyone remember the 68012? Yup, a 31 bit address 68010. Anybody remember which address bit it didn't have?
ts@cup.portal.com (Tim W Smith) (02/23/90)
I wonder if we have the computing equivalent of an urban legend going here? When I first heard of this, the story said it was a Masscomp machine that did this. But it was always someone who had heard about it who told this, never someone who had used the machine. This was in 1983. Now in 1990 people are saying it was Sun, or even that everyone was doing it. By the way, not all instructions cause problems with bus error on a 68000. If you can arrange your code so that the instructions that have problems never get a fault, you can do VM. For example, most of the 68k Unix systems around 1984 were swapping systems. However, they wanted to dynamically allocate the stack. To allow for this, the C compilers would generate a TST instruction of the form "TST -N(A7)" at the start of functions, with N chosen so that a location deeper on the stack than this function needs for local variables and return addresses will be accessed. If the stack needs to be grown, a bus error will be generated. The bus error handler is able to check and determine that it was this instruction that caused the bus error, and is able to then grow the stack and resume the program. Tim Smith
ts@cup.portal.com (Tim W Smith) (02/23/90)
> Trivia quiz: anyone remember the 68012?
Yes. Anyone remember Callan Data Systems? I worked there and ported
a UniSoft System V for the 68000 port to the 68012 and added demand
paged virtual memory.
That was a lot of fun. Callan was a small company that was in the midst
of going under, but was going ahead with building the new machine.
I managed to convince my boss that we should do our own VM system
rather than wait for UniSoft to do one.
I'm not sure I really convinced him we could do it, but he could see
that the company was going under and so was getting ready to leave
so he said "go ahead".
By the time he left and a replacement was hired, I had started
implementing the system. I was able to convince the new boss
that I knew what I was doing, so I was allowed to continue. Another
programmer was assigned to the project to help code.
Guess what? About five months after I said "Let's do our own VM",
we had a stable system that worked quite well. We even used
copy-on-write fork ( hah! take that, BSD! ).
And then the company went under. This was annoying, because they
were next going to let me design a windowing system for Unix.
That was going to be a lot of fun.
Tim Smithamanda@mermaid.intercon.com (Amanda Walker) (02/27/90)
In article <27247@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: > I wonder if we have the computing equivalent of an urban legend > going here? When I first heard of this, the story said it was > a Masscomp machine that did this. But it was always someone > who had heard about it who told this, never someone who had > used the machine. Well, I haven't been speculating about who actually built any of these, but I have a gen-u-ine application note from Motorola describing the scheme. It's sitting under my engineering sample MC68000L8 (T6E mask). 68K Trivia question #2: T6E was the last pre-production mask set--what was the difference between it and the final production mask (in operational terms--I'm not looking for a description of chip geometry :-))? All this reminiscing... the thing is, it wasn't all that long ago... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
lsr@Apple.COM (Larry Rosenstein) (03/01/90)
In article <1672@aurora.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: > A trick you can use in a 7th edition environment to _fake_ growable > stack segs it to insert a "tst -nnn(sp)" where nnn is the size of the > stack frame for the function being entered as the first instruction of This Lisa did this. It also allowed for demand swapping of code segments. This was done by figuring out how to restart certain JMP and JSR instructions and making sure that these were the only instructions used for cross-segment references. Since youcan restrict how data segments were accessed, data segments were loaded and unloaded under programmer control. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
thomas@uplog.se (Thomas Tornblom) (03/02/90)
In article <1990Feb26.182153.3740@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
68K Trivia question #2: T6E was the last pre-production mask set--what was
the difference between it and the final production mask (in operational
terms--I'm not looking for a description of chip geometry :-))?
The data strobes (UDS & LDS) were asserted on address errors.
The bus arbitration state machine were different.
--
Real life: Thomas Tornblom Email: thomas@uplog.se
Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406
Box 1218 Fax: +46 18 132039
S - 751 42 Uppsala, Sweden