pkahn@meridian.ads.com (Phil Kahn) (10/01/88)
I love the Mac. It has a world-class interface, a powerful CPU, fast and large memory, it's full 32-bit, it has a floating point coprocessor, etc. But the bad news for me and everyone else oout there doing large system development (e.g., research, engineering, etc) is that MacOS does not have virtual memory. A/UX is not a currently viable alternative since it doesn't yet have access to the toolbox (though that is soon to change :-) ). Anyway, I want MacOS so that I can use its interface and large assortment of public domain software. Bottom line is that the MacII with MacOS is not a "real" workstation until virtual memory is incorporated into the system. OK. So when is Apple going to put virtual memory into the MacOS? We're at version 6.0.2 . Is it slated to be in by version 7? or 8? I understand that virtual memory will likely blow away at least 1/3 of the software commercially available (due to hooks, etc), but it is required to do any serious workstation development. In an important sense, virtual memory is more important than multiprogramming, since it is generally a prequisite. Anyone in Apple who actually knows that will let us in on the secret? phil... "My, aren't we a happy little camper?"
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/01/88)
In article <5624@zodiac.UUCP> pkahn@ads.com (Phil Kahn) writes: >But the bad news for me and everyone else oout there doing large >system development (e.g., research, engineering, etc) is that MacOS >does not have virtual memory. Agreed! >I understand that virtual memory will likely blow away at least 1/3 >of the software commercially available (due to hooks, etc), but it is >required to do any serious workstation development. This needn't be so. It would be easy to build a page map that would in effect leave the old applications seeing exactly what they see now. One way to differentiate would be to introduce an ABTS (Address BiTS) resource into the newer software that indicates that 32 bit mode is okay. In many regards, a more serious problem to large software developers is the format of the CODE resource jump table.. For historical reasons (the 68000 only had 16 bit indirection for branch indirect), CODE segments are limited to 64K. More important, the global data segment is limited to 64K. Both of these facts introduce hassles that are solved by either 1. Allocating the big stuff dynamically - loses if you have to initialize it. 2. Compiling the program to live at a fixed address - loses on compatibility. In my opinion, it would be desirable to introduce a COD2 resource whose jump table permits 32 bit offsets (which are supported by the 68020 and 68030). Granted such software would be runnable only on the Mac II, but that is fundamental - programs that big won't run in 1M. This imposes a big limitation on things like TeX, LISP, and lots of other things. I have looked at it, and ever since the 64K resource bug was fixed I think it may even be doable compatibly. Any takers, Apple? If I can find a way to do it and persuade my bosses to let it go will you adopt it? Jon Shapiro AT&T Bell Laboratories
wetter@tybalt.caltech.edu (Pierce T. Wetter) (10/01/88)
>In my opinion, it would be desirable to introduce a COD2 resource >whose jump table permits 32 bit offsets (which are supported by the >68020 and 68030). Granted such software would be runnable only on the >Mac II, but that is fundamental - programs that big won't run in 1M. ok so far but the Mac+and the SE can have up to 4 Meg, not just one. Pierce ---------------------------------------------------------------- wetter@tybalt.caltech.edu pwetter@caltech.bitnet pwetter@caltech.edu ----------------------------------------------------------------- Weird theory #47: Islamic women can do kinky things with their ankles, that's why the Koran says they aren't supposed to reveal them in public.
gillies@p.cs.uiuc.edu (10/03/88)
The sad thing is, the vast majority of Macintoshes in this world
cannot support virtual memory. This is because the 68000 chip has a
design flaw that doesn't allow virtual memory to be implemented.
I guess if Apple really intended to support virtual memory soon in all
macintoshes, then it would have put a 68020 or at least a 68010 in the
Mac SE. But since most machines (SE's, Plus's) have the 68000, these
machines will not have virtual memory any time soon.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gilliesralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (10/03/88)
In article <4201@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: >In my opinion, it would be desirable to introduce a COD2 resource >whose jump table permits 32 bit offsets (which are supported by the >68020 and 68030). Granted such software would be runnable only on the >Mac II, but that is fundamental - programs that big won't run in 1M. Given that a new MacOS is coming (presumably only for machines with MMU's from the rumors I've heard), this probably won't even be a limitation. Many developers seem to be producing Mac and Mac ][ version of things, so there will be a split like that between 64K Apple ][ and Apple // GS software. Too bad that the price is usually proportional to the prices of the machines :-( I predict that the new operating system will be named MacOS 32. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)"
tomj@oakhill.UUCP (Tom Johnson) (10/04/88)
In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >The sad thing is, the vast majority of Macintoshes in this world >cannot support virtual memory. This is because the 68000 chip has a >design flaw that doesn't allow virtual memory to be implemented. ---- >.... > >Don Gillies, Dept. of Computer Science, University of Illinois >ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies I have to take exception to this statement. This is like saying that Henry Ford's Model T was flawed since it didn't have an 8 cylinder engine and mechanical air conditioning (opening the windows doesn't count :>)). In 1979 when the 68000 was first introduced, it was the largest commercially produced die ever attempted by man. For the first time, we were given internal 32-bit MPU features while the rest of the world was still thinking 8-bits. We were given a large number of general purpose registers while the rest of the world still had to struggle with dedicated registers. After Motorola **sucessfully** began producing the 68000, the designers went back to the drawing tables and started adding extra features: full virtaul memory and virtual machine suport and loop mode in the 68010; 32-bit ALU's, on-chip instruction cache, and full 32-bit external bus support in the 68020; on-chip data cache, on-chip paged MMU, synchronous bus, burst mode, and on-chip Harvard architecture in the 68030. The Motorola High End design team has spent the last 9 years carefully executing a plan to give the user community the highest possible performance given a moving fabrication technology target. I don't know why Apple chose to use the 68000 in the original toaster Mac's rather than the 68010, but I would assume that it had a lot to do with pricing. Motorola took a huge gamble introducing a microprocessor which broke with the industry convention (set by Intel) of always introducing MPUs that were completely compatible with existing families (8080-->80188-->80186-->80286--> 80386-->... vs 6800-->6801-->6805-->68HC11 ||| 68000-->68010-->68020-->68030 -->680x0-->...). I think most readers of this group would agree that Motorola made the right choice in this respect. Let's quit talking about the "flawed" 68000 (or 67999 as one poster stated a few months ago), and just be glad that Motorola has given us what we all wanted...a very high performance, orthogonal, easy to program, upward compatible MPU family that is STILL the metric by which most, if not all, other microprocessors are judged. _____________________________________________________________________________ |Disclaimer: The views stated above are my own and do not necessarily | | reflect the views of Motorola. | | | |tomj@oakhill.UUCP Tom Johnson | |(512)440-2143 Motorola High-End Marketing | | Austin, TX | |_____________________________________________________________________________|
jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (10/05/88)
In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >The sad thing is, the vast majority of Macintoshes in this world >cannot support virtual memory. This is because the 68000 chip has a >design flaw that doesn't allow virtual memory to be implemented. Someone really should tell Sun or Apollo. They've produced many workstations with 68000's running UNIX, which DOES support virtual memory and page swapping. Gosh, wonder how they do it? >I guess if Apple really intended to support virtual memory soon in all >macintoshes, then it would have put a 68020 or at least a 68010 in the >Mac SE. But since most machines (SE's, Plus's) have the 68000, these >machines will not have virtual memory any time soon. Virtual memory doesn't REQUIRE hardware memory management. It's a lot easier if you have the PMMU, but it's not impossible to do on a 68000. Apple, though, probably won't bother to write its new OS for anything less than a 68020/68851 combo... gotta keep pushing into the future, ya know! >Don Gillies, Dept. of Computer Science, University of Illinois >1304 W. Springfield, Urbana, Ill 61801 >ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies (Sanity check... this guy's in the CS dept. He may be a professor. And I'm just a lowly undergrad... did I just shoot my mouth off?) Rob Jellinghaus | "SINGAPORE?!? You're supposed to be a jellinghaus-robert@CS.Yale.EDU | COWBOY! What kind of cowboy song is ROBERTJ@{yalecs,yalevm}.BITNET | THAT??!! Singapore, I oughta--" {everyone}!decvax!yale!robertj | -- Eddie Foy, _The Cowboy Wally Story_
jherr@umbio.MIAMI.EDU (Jack Herrington) (10/05/88)
in article <1526@oakhill.UUCP>, tomj@oakhill.UUCP (Tom Johnson) says: > ...and just be glad > that Motorola has given us what we all wanted...a very high performance, > orthogonal, easy to program, upward compatible MPU family that is STILL the > metric by which most, if not all, other microprocessors are judged. Now I have to admit I will agree with that, and the 88000 series is very impressive, both lines beat Intel architecture hands down, but... > Motorola High-End Marketing ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Look, ma, no bias here! -Jack University of Miami "My opions reflect me."
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (10/05/88)
In article <39513@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes: >In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>The sad thing is, the vast majority of Macintoshes in this world >>cannot support virtual memory. This is because the 68000 chip has a >>design flaw that doesn't allow virtual memory to be implemented. > >Someone really should tell Sun or Apollo. They've produced many workstations >with 68000's running UNIX, which DOES support virtual memory and page swapping. >Gosh, wonder how they do it? > With 68000s? No, I don't think so. I'm pretty sure they used to use 68010 & custom memory management chips (sets) before the 68851 came out, and for the most part, they now use 68020 & 68851s. I believe the 68000 has a problem with restarting instructions after a trap, such as would occur on a page fault. >>I guess if Apple really intended to support virtual memory soon in all >>macintoshes, then it would have put a 68020 or at least a 68010 in the >>Mac SE. But since most machines (SE's, Plus's) have the 68000, these >>machines will not have virtual memory any time soon. > >Virtual memory doesn't REQUIRE hardware memory management. It's a lot easier >if you have the PMMU, but it's not impossible to do on a 68000. Apple, though, >probably won't bother to write its new OS for anything less than a 68020/68851 >combo... gotta keep pushing into the future, ya know! > Short of interpreting every instruction, just how do _you_ propose to do virtual memory without hardware memory management on a 68000? Suppose I want a nice big chunk of memory to do some casual geophysical modeling on my Mac 128k: a = NewHandle(10000000L); What do you do? I guess, that in some sense, purgable resources are somewhat like "virtual memory" (stuff stays on disk until needed), but there, you have to give an explicit command to load it in before you use anything, and then an explicit command to tell it that you're done with it. >>Don Gillies, Dept. of Computer Science, University of Illinois >(Sanity check... this guy's in the CS dept. He may be a professor. And I'm >just a lowly undergrad... did I just shoot my mouth off?) > >Rob Jellinghaus | "SINGAPORE?!? You're supposed to be a possibly. But I'm just a lowly undergrad too.
tim@hoptoad.uucp (Tim Maroney) (10/05/88)
C'mon, Tom, let's admit that the 68000 non-recoverable bus error is a serious screw-up. Just 'cause you work for Motorola doesn't mean you have to say everything they did is perfect; a non-recoverable exception is a bad idea. And it will still be a bad idea no matter how many Motorola employees say there's nothing wrong with it. Why'd you fix it if it wasn't broken? On the other hand, the original message was also wrong. So what that the 68000 can't be rigged for virtual memory without horrible external logic (I believe the Sun-1 did something like that)? It takes more than a CPU to do virtual memory. The Mac I motherboard (128K through SE versions) is not socketed for a memory management chip or daughterboard, so just having a 68010 in there would make no difference. You still need a motherboard upgrade, either a straight swap or an add-on that takes over the whole address bus. Many upgrades that take over the whole address bus clip on the 68000 and disable it, replacing it with one on the add-on board for simplicity. It would be just as easy for the add-on board to have its own 68010. There's no way the simple swap of a 68010 for the 68000 would make the Mac I any more suited for virtual memory. VM's a lot more than handling a bus fault. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The time is gone, the song is over. Thought I'd something more to say." - Roger Waters, Time
tim@hoptoad.uucp (Tim Maroney) (10/05/88)
The quote is "Virtual memory doesn't REQUIRE hardware memory management."
You can fake it in software. That requires a special compiler, so existing
programs can't use it (and probably can't run in the new environment). It's
also pretty slow. A loss all around. If you're going to fake virtual memory,
it's best to do it explicitly, and that's what the Resource Manager is for.
(See the new tech note on "Managerial Abuse".)
--
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"I wrapped a newspaper round my head, so I'd look like I was deep.
I said some mumbo-jumbos then: I told him he was going to sleep.
I robbed his ring, his pocket watch, and everything else I found.
I had that sucker hypnotized; he didn't even make a sound!"
- Frank Zappa, "Kozmik Debris"gillies@p.cs.uiuc.edu (10/05/88)
/* Written 1:11 pm Oct 4, 1988 by jellinghaus-robe@CS.YALE.EDU */ >In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>The sad thing is, the vast majority of Macintoshes in this world >>cannot support virtual memory. This is because the 68000 chip has a >>design flaw that doesn't allow virtual memory to be implemented. > >Someone really should tell Sun or Apollo. They've produced many workstations >with 68000's running UNIX, which DOES support virtual memory and page >swapping. Gosh, wonder how they do it? I believe that a microcode bug leaves the CPU in a corrupt state if you take a page fault on a certain memory reference by the 68000 CPU. All the paging Sun's I know of use the 68010 or 68020, not the 68000 CPU. I think this is the main reason why Motorola designed the 68010 -- to fix this microcode bug. I once heard that someone implemented VM on the 68000 by using two CPU's, one executing a few cycles behind the other. This way, if one takes a page fault & is corrupted, the other can be stopped early, and the corrupted CPU can be reinitialized from the "trailing" CPU's registers. I wasn't trying to malign the 68000, which I have a lot of respect for. Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies
tomj@oakhill.UUCP (Tom Johnson) (10/05/88)
In article <703@umbio.MIAMI.EDU> jherr@umbio.MIAMI.EDU (Jack Herrington) writes: > Now I have to admit I will agree with that, and the 88000 series is very > impressive, both lines beat Intel architecture hands down, but... > >> Motorola High-End Marketing > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Look, ma, no bias here! > -Jack > University of Miami In my own defense, I didn't work for Motorola in 1979, I worked for Signetics. At that time, Sig was preparing to enter the 16-bit MPU wars with a proprietary microprocessor based on the Philips P-800 minicomputer architecture (the MPU was to be called the SP16/10). When Motorola came out with the 68K my department was given the task of comparing the two architectures and deciding which we thought would be "better" for Sig to manufacture. We didn't have any say in the final decision however. I wrote the Sig training course on the 68000, and in the process became quite enamoured with the part. I didn't come to work for Motorola until about 2 years later, and then as a field Systems Engineer in the San Jose Sales office. I moved to Austin with the High-End group in December of 1983, after the introduction of the 68020. My job has NOTHING to do with reading email and defending Motorola or the 68000 family, but I still like the part, and am still amazed when I realize the history surrounding its development. Am I biased...YOU BET, but it's because I firmly believe that the 68K family is the best thing that ever happened to microprocessing (to coin a term). In article <5537@hoptoad.uucp> Tim Maroney writes: > C'mon, Tom, let's admit that the 68000 non-recoverable bus error is a serious > screw-up. Just 'cause you work for Motorola doesn't mean you have to say > everything they did is perfect; a non-recoverable exception is a bad idea. > ... Why'd you fix it if it wasn't broken? > Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim In 1979 when the 68000 was introduced, the whole concept of exception processing was new to the microprocessor community. The 68000 was one of the first (if not THE first) microprocessor to completely trap ALL unused op codes (those things that made using HP calculators so much fun :>)). The fact that the 68000 even tries to save some information about non-recoverable external faults was innovative in microprocessors at the time. Remember that the term "workstation" had yet to be coined, virtual memory had NEVER been attempted in microprocessor-based systems, and most MPUs were still being used as logic replacements or embedded controllers rather than computing elements per se. The 68000 changed all of that. On a bus error, the 68000 didn't just die, but allowed the user to attempt to continue...maybe by trashing the offending task and returning to the system, but continue nonetheless. Prior MPU-based systems usually performed a cold-start or went off to try to execute bad data when an external error was encountered. The 68000 saves a substantial amount of information on a bus error: the PC, status register, instruction register, access address, and some basic information about the state of the processor; whether or not the error occured on a read or write cycle, whether or not the processor was in the middle of instruction processing, and the function codes; all at the moment of the error. The major difficulty in attempting FULL recovery stems from the fact the the PC value is advanced between 2 and 10 bytes from the start of the instruction in which the error occured. This is because the PC value saved is actually the ScanPC (an internal PC used to increment through the extension words of instructions). Theoretically, it is possible to implement FULL recovery given this information using instruction RESTART rather than INSTRUCTION CONTINUATION (like the '010). Instruction RESTART is the fault handling method used on the Intel 80[1-3]86. One needs to look backward in the instruction stream for 2 to 10 bytes for the value contained in the saved instruction register. This points you directly at the start of the offending instruction. Once external memory has been "fixed" (no simple task), the instruction can be restarted by pushing the saved status register and the address of the offending instruction on the stack and issuing an RTE instruction. The kicker here is that it is possible for the extension words of the offending instruction (i.e. those between the actual instruction address and the saved PC value) to be the same hex value as that of the instruction itself. Thus, you **might** start executing in the middle of an instruction. Additionally, the post-increment and pre-decrement addressing modes on the 68000 mean that it is possible that address registers have been modified. The bus error handler would have to determine whether or not one of these modes was being used and correct the appropriate address register prior to restarting the instruction. It is for these reasons that the 68000 is not recommended as a processor in a virtual memory system. The 68010 added the features to allow for full support of virtual memory/ virtual machine environments. Note I said **ADDED** not **FIXED**. The major changes required were 1) saving more state information on bus errors, 2) adding microcode to allow instruction continuation, and 3) making the "MOVE SR,<ea>" instruction priveleged. These changes required additional control points in the hardware, additional microrom space, and additional nanorom space, none of which were available in the 68000 due to die size limitations. Refering to my Model-T metaphore from yesterday: you can race a model-T, but you'll probably get better results with a Lotus, yet BOTH use a 4-cylinder engine! The Model-T was the epitome of technology for its time, and can STILL provide reliable transportation depending on your needs. ___________________________________________________________________________ | Disclaimer: The views presented above are my own, and do not necessarily | | reflect the views or policies of Motorola. | | | | tomj@oakhill.UUCP Tom Johnson | | Motorola High End Marketing | | Austin, TX | |___________________________________________________________________________|
wetter@tybalt.caltech.edu (Pierce T. Wetter) (10/06/88)
> >Someone really should tell Sun or Apollo. They've produced many workstations >with 68000's running UNIX, which DOES support virtual memory and page swapping. >Gosh, wonder how they do it? Supervisor mode/User Mode >>I guess if Apple really intended to support virtual memory soon in all >>macintoshes, then it would have put a 68020 or at least a 68010 in the >>Mac SE. But since most machines (SE's, Plus's) have the 68000, these >>machines will not have virtual memory any time soon. > >Virtual memory doesn't REQUIRE hardware memory management. It's a lot easier >if you have the PMMU, but it's not impossible to do on a 68000. Apple, though, >probably won't bother to write its new OS for anything less than a 68020/68851 >combo... gotta keep pushing into the future, ya know! Nah. Supervisor mode. Read the apple list of Dont's. Such as, DON"T USE SUPERVISOR MODE INSTRUCTIONS. The new OS will undoubtably force applications to run in user mode. Unfortunately, there are a fair number of apps which do use them. Unfortunately, Apple probably won't seed the compiler writers with new OS versions before the app developers. (After all, what are you going to do if your application was written in LSC, and LSC goes off and tweaks the status register? Wait until LSC gets you an update.) Pierce ---------------------------------------------------------------- wetter@tybalt.caltech.edu pwetter@caltech.bitnet pwetter@caltech.edu ----------------------------------------------------------------- Weird theory #47: Islamic women can do kinky things with their ankles, that's why the Koran says they aren't supposed to reveal them in public.
tomj@oakhill.UUCP (Tom Johnson) (10/06/88)
In article <76000293@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >/* Written 1:11 pm Oct 4, 1988 by jellinghaus-robe@CS.YALE.EDU */ >>In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>>The sad thing is, the vast majority of Macintoshes in this world >>>cannot support virtual memory. This is because the 68000 chip has a >>>design flaw that doesn't allow virtual memory to be implemented. >> >>Someone really should tell Sun or Apollo. They've produced many workstations >>with 68000's running UNIX, which DOES support virtual memory and page >>swapping. Gosh, wonder how they do it? > >I believe that a microcode bug leaves the CPU in a corrupt state if ^^^^^^^^^^^^^ >you take a page fault on a certain memory reference by the 68000 CPU. >... I think this is the main reason why Motorola designed the 68010 >-- to fix this microcode bug. > >I once heard that someone implemented VM on the 68000 by using two >CPU's, one executing a few cycles behind the other... > >I wasn't trying to malign the 68000, which I have a lot of respect for. > >Don Gillies, Dept. of Computer Science, University of Illinois >1304 W. Springfield, Urbana, Ill 61801 >ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies One and for all...there is NOT A MICROCODE BUG IN THE 68000. The processor was not DESIGNED to allow for virtual memory!!! As far as the two processor support, you are more or less correct. Actually, the "2nd" processor (called the "fault" processor) simply waits for page faults. The bus error line from memory is tied to its interrupt lines and NOT to the "main" processor's bus error line. When a page fault (or any other memory fault for that matter) occurs, the main processor is in the midst of a bus cycle, awaiting a DTACK or BUS ERROR (or VPA). The fault processor, by intercepting Bus Error leaves the main processor STILL awaiting termination of the bus cycle. The fault processor then issues a RELINQUISH and RETRY (by asserting BUS ERROR, HALT, and BUS REQUEST simultaneously). This terminates the main processor's bus cycle, but assures us that 1) the fault processor will get control of the bus for as long as needed, and 2) the next bus cycle the main processor will run will be that SAME cycle that was "faulted". The fault processor fixes memory and releases BUS REQUEST and waits for another fault. The main processor re-runs the EXACT bus cycle that "faulted". QED virtual memory on a 68000. |Disclaimer: The views presented above are my own, and do not necessarily | reflect the views of Motorola. | | tomj@oakhill.UUCP Tom Johnson, High End Technical Marketing | Motorola, Austin, TX
albaugh@dms.UUCP (Mike Albaugh) (10/07/88)
From article <1526@oakhill.UUCP>, by tomj@oakhill.UUCP (Tom Johnson): > In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >> >>The sad thing is, the vast majority of Macintoshes in this world >>cannot support virtual memory. This is because the 68000 chip has a >>design flaw that doesn't allow virtual memory to be implemented. > ---- > I have to take exception to this statement. This is like saying that Henry > Ford's Model T was flawed since it didn't have an 8 cylinder engine and Only if Henry had provided 8 cylinders and only put pistons in four of them :-). Seriously, If the 68000 had not `tried' to do virtual memory, by saving almost_but_not_quite enough information on a bus_err, would I accept this analogy > [much horn-tooting deleted] > technology target. I don't know why Apple chose to use the 68000 in the > original toaster Mac's rather than the 68010, but I would assume that it > had a lot to do with pricing. Maybe they were smarter than me, and didn't believe the moto salesman's swear_on_a_stack_of_bibles (did I forget to mention I'm an atheist) spiel that the the 010 would always be a SMALL (no, I'm not gonna state it publicly) increment more expensive than the 000. > Motorola took a huge gamble introducing a microprocessor which broke with > the industry convention (set by Intel) of always introducing MPUs that were > completely compatible with existing families (8080-->80188-->80186-->80286--> > 80386-->... vs 6800-->6801-->6805-->68HC11 ||| 68000-->68010-->68020-->68030 > -->680x0-->...). I think most readers of this group would agree that Motorola > made the right choice in this respect. Let's quit talking about the "flawed" Maybe it had something to do with lack of installed base? Sure, I'll agree they made the right choice moving _from_ the 6800. I may wish to reserve judgement on moving _to_ the 68000. > 68000 (or 67999 as one poster stated a few months ago), and just be glad > that Motorola has given us what we all wanted...a very high performance ^^^^^^1^^^^^^^^ > orthogonal, easy to program, upward compatible MPU family that is STILL the ^^^^2^^^ ^^^^^^3^^^^^^^^ ^^^^^^^^4^^^^^^^ > metric by which most, if not all, other microprocessors are judged. That's what I wanted, all right, but anyone who uses 2 & 3 above with a straight face must be a sales-rep, not a programmer, 1 is open to discussion, and 4 can be readily refuted by anyone who has had to move code they didn't write from 68000->68010 (traps and MOVE xxx,SR come immediately to mind) > _____________________________________________________________________________ > |Disclaimer: The views stated above are my own and do not necessarily | > | reflect the views of Motorola. | > | | > |tomj@oakhill.UUCP Tom Johnson | > |(512)440-2143 Motorola High-End Marketing | > | Austin, TX | > |_____________________________________________________________________________| Disclaimer: I use 68010's and 68000's all the time, in embedded systems. (I use a 68020 in my accelerated Mac SE). I do so because they are cheap and fast, not because I have any delusions about technological superiority. The `cheap' part has more to do with Apple and Atari (the other one) using them than anything else. | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
wetter@tybalt.caltech.edu (Pierce T. Wetter) (10/08/88)
It seems to me that the whether the '68000' is a good chip or not
debate is missing a point or two.
The 68000 is a very 'old' chip. When the 68000 was introduced, it was
the state of the art in microprocessors. You could buy a 68000 microcomputer
since what, 1976 or so?
Criticizing the 68000 for not having support for various "modern" features
is like criticizing Newton for not knowing Quantum Physics. The 68000 made
small, powerful computers available to a lot of people. These people went on
to invent better ways to do things. OF COURSE THE 68000 doesn't support them
they weren't invented yet. The 68000, by allowing you to address 16 Meg of
memory was ahead of its time. Remember, people used to build MAINFRAMES with
64k of memory and 10 meg of disk space (and lots and lots of tape drives.)
The state of the art is NOT the 68000 ANYMORE. Don't lambaste the 68000 for
not having various features. It didn't need them. Now that microcomputers need
more power, we have the 68020, 030 and the 88000 series. They're the future,
not the 68000.
Of course, if you want to talk about brain-damaged microprocessors, what
about the 68008. The 8-bit version of the 68000. 32/16 I can understand, but
32/8?
Pierce
----------------------------------------------------------------
wetter@tybalt.caltech.edu pwetter@caltech.bitnet pwetter@caltech.edu
-----------------------------------------------------------------
Weird theory #47: Islamic women can do kinky things with their ankles,
that's why the Koran says they aren't supposed to
reveal them in public. pkahn@deimos.ads.com (Phil Kahn) (10/10/88)
Though I have greatly enjoyed the informative geneological and functional tracings of the 680XX, I am still left with my original question: When will Apple release MacOS with virtual memory?!! I KNOW that Apple is working on this. Note that I work several miles away from Apple and I know several current AC employees that unfortunately do not know the precise answer but know that projects are underway. In fact, two separate AC people I know told me that they have heard that a VM MacOS has been built and is running! Now I understand that a company has to 'protect' its developer base and secrecy builds a mystique that gets free PR, but geez, we sometimes have a hell of a time convincing some people to buy Macs when VM does not appear to have any real support within Apple (except for the 'Oh, gee, then you should buy A/UX crowd (and build Rome from scratch).' Sometimes it seems that the power in Apple is controlled by evangelists and relatively lay users rather than computer scientists. I mean, Multics had virtual memory in the 60s! Pretty basic stuff here. Does anyone out there know? Can't anything be said? Isn't it about TIME?!!! phil...
bga@raspail.UUCP (Bruce Albrecht) (10/11/88)
In article <8253@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu (Pierce T. Wetter) writes: > Criticizing the 68000 for not having support for various "modern" features > is like criticizing Newton for not knowing Quantum Physics. The 68000 made > small, powerful computers available to a lot of people. These people went on > to invent better ways to do things. OF COURSE THE 68000 doesn't support them > they weren't invented yet. The 68000, by allowing you to address 16 Meg of > memory was ahead of its time. Remember, people used to build MAINFRAMES with > 64k of memory and 10 meg of disk space (and lots and lots of tape drives.) Memory Management is not a "modern" feature. It was around then. Motorola originally planned to support it on the 68000, and National did support it on the 16032. The real problem has always been to figure out how to put all of that circuitry onto the space available. Motorola and National certainly planned on supporting a full 32 bit address space, but didn't have the room on the first generation 16 bit processors. In the 1960's, mainframes may have only had 64k memory, and 10 meg disk drives, but by the late 1970's, most mainframes had 1 meg or more of memory, and 150+ meg drives, and only entry level minicomputers and mainframes were that small. > The state of the art is NOT the 68000 ANYMORE. Don't lambaste the 68000 for > not having various features. It didn't need them. Now that microcomputers need > more power, we have the 68020, 030 and the 88000 series. They're the future, > not the 68000. Even though the 68000 isn't state of the art, there's a lot of them being put into newly manufactured machines (Mac+, Mac SE, etc.). Market economics prevent you from ignoring them when you develop products for only state of the art computers that are mostly compatible with earlier generations of the microprocessor family. > Of course, if you want to talk about brain-damaged microprocessors, what > about the 68008. The 8-bit version of the 68000. 32/16 I can understand, but > 32/8? This isn't as stupid as you think. The 68008 was meant to be used for controlling devices on an 8-bit bus, not for general purpose computers. By using the 68008, designers got the speed of the 68000 (mostly), and the lower cost of a 8 bit bus. Of course, if you ever needed to upgrade to the 16 bit bus, reprogramming would be negligble. I missed the discussion leading up to Wetter's article, but as someone who avidly followed the introductions of the first generation of 16 bit micro- processors, I felt that his article lacked historical perspective. Bruce
kh@s1.sys.uea.ac.uk (Kevin Hammond CMP) (10/12/88)
Having had some experience of working with VM operating systems, I'm not sure that they really are that wonderful. Demand Paging perhaps, to avoid writing overlays (you have something a bit like this on the Mac with the segment loader, I suppose), but VM? The problem is that if you really need more memory than you've got, you will always thrash (we have this problem with our Sun workstations, it makes them very slow), and if you don't you don't really have a problem. Buying more memory (or writing more efficient programs) usually seems the better option if you have the choice. Paging from a floppy or slow hard disk isn't my idea of fun either. -- Wot? No Signature? UUCP: ...!mcvax!ukc!uea-sys!kh JANET: kh@sys.uea.ac.uk
kehr@felix.UUCP (Shirley Kehr) (10/12/88)
In article <271@cvbnet2.UUCP> pcolby@robbie.UUCP (Peter Colby) writes: >And in fact, I have seen UNIX running >on pure 68000 machines (UNIX *IS* a multiuser virtual-memory system). The >machine was a COSMOS, dated sometime in the vicinity of 1980-1981. > And at my former job with Pertec Computer, I wrote documentation for a proprietary operating system that was multiuser multitasking. You can start up to 256 tasks on a simple 68000 using that OS. The machine also runs Unix and Pick (take your pick - pun intended). While the Pertec machine is a business machine that doesn't do graphics, it supported around 64 terminals. Those terminals could be intelligent (64k Z80 processors) running CP/M and any of its applications. So, while I don't pretend to understand most of this discussion, I know that it is quite possible to have multiuser multitasking on a 68000. Don't ask me if they use virtual memory; I wouldn't know. (And when I bought the SE's, I had more memory than many of our customers who ran with only 1 meg.
landman%hanami@Sun.COM (Howard A. Landman) (10/13/88)
>In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>cannot support virtual memory. This is because the 68000 chip has a >>design flaw that doesn't allow virtual memory to be implemented. In article <39513@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes: >Someone really should tell Sun or Apollo. They've produced many workstations >with 68000's running UNIX, which DOES support virtual memory and page swapping. >Gosh, wonder how they do it? I can't speak for Sun or Apollo (what? I work at Sun!), but when I was at Metheus we did it too. It took *2* 68000s. I suppose a big wad of external logic would also work. Either way, the problem is COST! >Virtual memory doesn't REQUIRE hardware memory management. It's a lot easier >if you have the PMMU, but it's not impossible to do on a 68000. Computer users don't REQUIRE price/performance either. Perhaps I could interest you in a TRS-80 Model I ? Although, it actually draws characters on its screen faster than a Mac does. Hardware character generation isn't REQUIRED, but it sure speeds things up! (Of course, you lose some flexibility there ... :-) Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (10/13/88)
In article <157@s1.sys.uea.ac.uk> kh@s1.sys.uea.ac.uk (Kevin Hammond CMP) writes: >Having had some experience of working with VM operating systems, I'm >not sure that they really are that wonderful. Demand Paging perhaps, >to avoid writing overlays (you have something a bit like this on the >Mac with the segment loader, I suppose), but VM? The problem is that >if you really need more memory than you've got, you will always thrash >(we have this problem with our Sun workstations, it makes them very >slow), and if you don't you don't really have a problem. Buying more >memory (or writing more efficient programs) usually seems the better >option if you have the choice. Paging from a floppy or slow hard disk >isn't my idea of fun either. Here's a circumstance that often comes up in which paging is useful: Suppose you're running some typical multi-tasking "big" operating systems with many quiescent daemon processes, such as mail servers, print servers or network servers. Individually these programs do not take up enormous amounts of memory, but together, the total amount of memory can be quite significant. But, 99% of the time these programs don't run!!--they just sit there waiting for some event to happen. In that case I'd want their memory to get paged out onto disk so that my ray-tracing software can crunch with all the memory it can get. Of course, if on of the daemons should wake up, there would be some paging delay and slowdown, but most of the time they don't need all their memory, and they only use only 5ms of time anyway, so it's OK. I'd rather have VM so that if I need "just a little bit extra memory" for a little while I can get it, instead of getting a crash. Also, many programs don't use alot of their memory (whether in program code or data) for significant portions of the time. By paging out this temporarily unused memory, you can let other backround processes get some RAM. For very large compute-intensive jobs, however, VM cannot replace real live chips. BTW I believe that some models of Cray supercomputers do not have virtual memory. But I believe all ETA supercompters do. Matt Kennel mbkennel@phoenix.princeton.edu
tim@hoptoad.uucp (Tim Maroney) (10/14/88)
In article <39513@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes: >Someone really should tell Sun or Apollo. They've produced many workstations >with 68000's running UNIX, which DOES support virtual memory and page swapping. >Gosh, wonder how they do it? They don't, or at least Sun doesn't. The Sun 1 used a 68000 and ran only a swapping UNIX, not a page faulting (virtual memory) UNIX. The Sun 1.5 was a motherboard-swap upgrade to the Sun 1, using a 68010; it was the first Sun to run vmunix. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I was brought up in the other service; but I knew from the first that the Devil was my natural master and captain and friend. I saw that he was in the right, and that the world cringed to his conqueror only from fear." - Shaw, "The Devil's Disciple"
ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (10/22/88)
Interesting that timesharing and virtual memory are becoming popular again. Even though there are time proven techniques for managing scarce resources, resources shouldn't be that scarce anymore. Anyway, any plain vanilla 68000 can do multiuser & multitasking stuff. AmigaDOS, Microware systems OS-9, and many early Unix vendors have pretty effectively shown that. What you want on a machine like a Mac where most of the applications are programmed in 'unsafe' implementations of languages, and compilers generate code which can trash anything is memory PROTECTION. This strongly encourages the use of an MMU. And once you have a MMU, you can easily do Virtual memory (which I consider sort of a last resort, for those who want a certain set of applications, but don't have enough memory for them, is an MMU. The Mac memory management system is nifty enough that I suspect even multifinder could be patched up to provide for a swapping MacOS, where whole application code resources (and maybe even their data spaces) can be put on a disk when they aren't in the foreground. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)"