jdg@elmgate.UUCP (Jeff Gortatowsky) (08/13/86)
With all the talk of the new CoCo's memory management system and the discussions wondering why a 68000 was not used I have the following thoughts (yes I have ONE now and again :^> ) If memory serves me correct the 68000 can not restart/resume a bus faulted instruction. So regardless of what mkind of MMU you try to hang on it, it can not overcome this problem. As I understand it, the 68000 does NOT ensure the address pointed to on the stack, is the address of the fault instruction. Therefore you can't restart the instruction and 68000 does not dump it's micro-state, so you can't resume the faulted instruction. Is this about right? Motorola you out there? Guy Harris, this about the scheme of things? Henry of UTZOO, this acurate? BTW the 68010 fixes this. -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>
daveh@cbmvax.cbm.UUCP (Dave Haynie) (08/14/86)
> Keywords: 68000 atari amiga 68k mmu > Xref: cbmvax net.micro.atari16:1562 net.micro.amiga:2159 net.micro.68k:186 > > If memory serves me correct the 68000 can not restart/resume a bus faulted > instruction. So regardless of what mkind of MMU you try to hang on it, it > can not overcome this problem. As I understand it, the 68000 does NOT > ensure the address pointed to on the stack, is the address of the fault > instruction. Therefore you can't restart the instruction and 68000 does > not dump it's micro-state, so you can't resume the faulted instruction. Is > this about right? Motorola you out there? Guy Harris, this about the > scheme of things? Henry of UTZOO, this acurate? > > BTW the 68010 fixes this. That basically it. The 68010 uses instruction continuation to support virtual memory and/or MMUs. When an exception occurs, some processor internal state information is pushed on the exception stack. This allows a bus error exception handler to do whatever's necessary to get the desired address into physical memory, then RTE, at which point the instruction that caused the bus error will continue, recovering at the cycle that caused the fault. This is more efficient than the method used by some processors, which restart the instruction from its beginning. The 68000 doesn't save enough exception stack information to accomplish this. > > -- > Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg > Eastman Kodak Company > <Kodak won't be responsible for the above comments, only those below> -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
tmb@mit-prep.ARPA (Thomas M. Breuel) (08/14/86)
|With all the talk of the new CoCo's memory management system and the |discussions wondering why a 68000 was not used I have the following |thoughts (yes I have ONE now and again :^> ) | |If memory serves me correct the 68000 can not restart/resume a bus faulted |instruction. So regardless of what mkind of MMU you try to hang on it, it |can not overcome this problem. As I understand it, the 68000 does NOT |ensure the address pointed to on the stack, is the address of the fault |instruction. Therefore you can't restart the instruction and 68000 does |not dump it's micro-state, so you can't resume the faulted instruction. Is |this about right? Motorola you out there? Guy Harris, this about the |scheme of things? Henry of UTZOO, this acurate? The fact that it is difficult to restart an instruction that received a bus fault on the 68000 makes it difficult to implement paging. However, an MMU has other uses besides paging, e.g. to protect processes from one another, to help utilise memory more efficiently, and to allow swapping and process duplication (a la fork(1); you can't implement fork(1), in general, on the 68000 without an MMU). I consider it a grave mistake not to have included even a rudimentary kind of address remapping on the Amiga; even just an adder on the address lines of the 68000 would have simplified the system software and allowed some kind of swapping to be hacked. Thomas.
gijs@ark.UUCP (Gijs Mos) (08/15/86)
In article <508@elmgate.UUCP> jdg@elmgate.UUCP writes: ... >If memory serves me correct the 68000 can not restart/resume a bus faulted >instruction. So regardless of what mkind of MMU you try to hang on it, it >can not overcome this problem. ... The Motorola Programmers Reference Manual (page 45, MC68000/68008): ... Although this information is not sufficient in general to effect full recovery from the bus error, it does allow software diagnosis. ... You cannot do virtual memory, you cannot auto-allocate stack space, but you *can* do multitasking. -- Gijs Mos EUNET: gijs@vu44 ({seismo,philabs,decvax}!mcvax!vu44!gijs) BITNET: u00131@hasara5 MAIL: Gijs Mos Vrije Universiteit Biologisch Lab. De Boelelaan 1087 1081 HV Amsterdam PHONE: +31 20 5485705
jdg@elmgate.UUCP (Jeff Gortatowsky) (08/18/86)
In article <64@mit-prep.ARPA>, tmb@mit-prep.ARPA (Thomas M. Breuel) writes: > The fact that it is difficult to restart an instruction that received > a bus fault on the 68000 makes it difficult to implement paging. > However, an MMU has other uses besides paging, e.g. to protect processes > from one another, to help utilise memory more efficiently, and > to allow swapping and process duplication (a la fork(1); you can't > implement fork(1), in general, on the 68000 without an MMU). > > I consider it a grave mistake not to have included even a rudimentary kind > of address remapping on the Amiga; even just an adder on the address lines > of the 68000 would have simplified the system software and allowed some > kind of swapping to be hacked. > > Thomas. I understand your first paragraph completely. But you lost me on the second. I can see where a MMU that provides protection only would be useful but address mapping is still of no use. Not without a 68010, admittedly an easy upgrade, but not provided. If you mapped a some address block to another would you not HAVE to ensure it was a legal RAM/ROM address? One faulty address and your back to GURU type crashes, yes? I guess it be nice to learn from you what type of paging you could implement with just an adder, etc. Enlighten me. Mail if you must. Post if it seems of general interest to all 68000 based machines. -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>
scott@puff.UUCP (Scott Aschenbach) (08/19/86)
In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes: > In article <508@elmgate.UUCP> jdg@elmgate.UUCP writes: > ... > >If memory serves me correct the 68000 can not restart/resume a bus faulted > >instruction. So regardless of what mkind of MMU you try to hang on it, it > >can not overcome this problem. ... > > You cannot do virtual memory, you cannot auto-allocate stack space, but you > *can* do multitasking. > > -- > Gijs Mos You can auto-allocate stack space if you always allocate it the same way so you know how to recover when you get a fault. For example, always update the stack/frame pointers and then clear a memory location before actually using it. A bit wasteful, but it may be worth the effort. I though I heard of someone using pairs of 68000's before the 68010s came out. One was set to run just a bit ahead of the other, so that the first faulted, and the second was in the state the first one should be in when it was restarted. It may not be cheap, but don't say it can't be done. -- W. Scott Aschenbach (Deputy Directory of Computing Facilities) uwvax!scott scott@rsch.wisc.edu
bass@dmsd.UUCP (John Bass) (08/19/86)
In article <653@cbmvax.cbmvax.cbm.UUCP>, grr@cbmvax.cbm.UUCP (George Robbins) writes: > A reasonable attitute, but remember that both the Amiga and Atari were > intended to be affordable machines. To this end, they contain only those > things that were considered to be needed - no 'it sure would be nice...' > type goodies. Consider that a simple paging mmu is a pal and two highspeed 16k static rams, a production cost of under $10 in ST quantities, furthermore parity is under $5 -- at a 3:1 retail price to parts cost ratio we are talking under $45 at the shelf. This is the difference between the ST being a game machine and having the support for process issolation and error detection for a strong bussiness machine. The additional market share should justify it, except for the mindset of being in the highly competitve game market. If both of these we included in the custom vlsi, the cost would have been cheaper. Sorry ... but Atari just screwed up ... this machine is not just another 400/800 in the market place -- it is big enough to go places, but remains cripled by it's designers. -- John Bass (DBA:DMS Design) DMS Design (System Design, Performance and Arch Consultants) {amdahl,fortune,polyslo}!dmsd!bass
tim@ism780c.UUCP (Tim Smith) (08/20/86)
In article <767@ark.UUCP> gijs@vu44.UUCP (Mos Gijs) writes: > ... > Although this information is not sufficient in general to effect full > recovery from the bus error, it does allow software diagnosis. > ... >You cannot do virtual memory, you cannot auto-allocate stack space, but you >*can* do multitasking. > Actually, with a small compiler hack, you *can* auto-allocate stack space. The trick is that while in general you can't restart, there are specific instructions that can be restarted. tstb is one such instruction. The hack to the compiler is to make it generate a tstb in the function entry code to access the lowest stack address that the function will use. I have heard people claim that there is enough information around after a bus error ( or address error ) to restart most instructions, if the bus error handler is willing to be clever. However, I haven't seen any actual code... Anyone know if this is true? If so, what are the instructions that can't be restarted? -- "I *DO* believe in Mary Worth" Tim Smith USENET: sdcrdcf!ism780c!tim || ima!ism780!tim Compuserve: 72257,3706 Delphi || GEnie: mnementh
grr@cbmvax.cbm.UUCP (George Robbins) (08/20/86)
In article <64@mit-prep.ARPA> tmb@prep.UUCP (Thomas M. Breuel) writes: > >I consider it a grave mistake not to have included even a rudimentary kind >of address remapping on the Amiga; even just an adder on the address lines >of the 68000 would have simplified the system software and allowed some >kind of swapping to be hacked. > Thomas. A reasonable attitute, but remember that both the Amiga and Atari were intended to be affordable machines. To this end, they contain only those things that were considered to be needed - no 'it sure would be nice...' type goodies. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
dyer@atari.UUcp (Landon Dyer) (08/20/86)
In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes: > You cannot do virtual memory, you cannot auto-allocate stack space, but you > *can* do multitasking. You can TOO do auto-allocation of stack space with a vanilla 68000, an MMU, and appropriate compiler support. Sun did this (I think) in the Sun-1. Forgive me if this is pedantic: Part of each procedure setup (along with the LINK) is a "probe" instruction (TST.B, say) that tests to see if enough stack is available to hold the entire local stack frame plus a reasonable number of arguments. If there is enough, the TST.B works. If there isn't enough stack space, the TST.B will generate a bus error which signals the OS to increase the stack. The TST instruction can be thrown away, since nothing else depends on it. _foo: link a6,#8 ; make room for local args tst.b -208(sp) ; ensure enough stack . . . Of course this isn't very transparent if you are programming in assembly language. But in that case you deserve to suffer. :-> -- -Landon Dyer, Atari Corp. {sun,lll-lcc,lll-crg!vecpyr}!atari!dyer /-----------------------------------------------\ | The views represented here do not necessarily | "If Business is War, then | reflect those of Atari Corp., or even my own. | I'm a Prisoner of Business!" \-----------------------------------------------/
jeff@gatech.CSNET (Jeff Lee) (08/20/86)
>> The fact that it is difficult to restart an instruction that received >> a bus fault on the 68000 makes it difficult to implement paging. >I can see where a MMU that provides protection only would be useful but >address mapping is still of no use. Not without a 68010, admittedly an >easy upgrade, but not provided. If you mapped a some address block to >another would you not HAVE to ensure it was a legal RAM/ROM address? One >faulty address and your back to GURU type crashes, yes? Just because you are implementing "paging" does not mean that you must implement "demand paging". The PDP-11 had memory mapping registers but did not allow demand paging. Before a process ran you had to ensure that all the memory they were allowed to access was resident. You could do the same with a 68000. With a couple of 35ns rams and some address decoding (to map them into memory) you can implement a similar type of MMU. For system level access, you bypass the rams and physical and logical memory are the same. The OS loads the memory mapping rams with the appropriate address and dispatches the process. While in user mode, the high order bits are remapped into different physical locations (going through the MMU rams). You access something that you are not supposed to and you take a bus error. The OS kicks you in the butt and drops your process, or gives you a signal with the caveat that you may not return to where you took the signal. Others have already commented that with the appropriate code you really can take bus errors for stack accesses and recover, as long as the access is at the beginning of the routine to "feel out" the size. This is paging, but the pages must essentially be preloaded. During another process, there is nothing that prevents just a portion of your program being swapped out, but it isn't necessary to swap it all out. Enjoy... -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
tomj@oakhill.UUCP (Tom Johnson) (08/20/86)
In article <162@puff.UUCP> scott@puff.UUCP (Scott Aschenbach) writes: >In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes: >> In article <508@elmgate.UUCP> jdg@elmgate.UUCP writes: >> ... >> >If memory serves me correct the 68000 can not restart/resume a bus faulted >> >instruction... >... >I though I heard of someone using pairs of 68000's before the 68010s >came out. One was set to run just a bit ahead of the other, so that >the first faulted, and the second was in the state the first one should >be in when it was restarted. Close. Actually, one of the processors is set-up as the "run" processor, and the other as the "fault" processor. The run processor executes all normal program instructions, and has its bus cycles terminated with a DTACK*. If a bus cycle faults, the BERR* signal goes only to the fault processor. It then issues a "relinquish and retry" (BERR*, HALT*, BR*) to the run processor which immediately terminates the "faulted" bus cycle, saves the access address internally for later use, and issues a BG*. The fault processor, upon receipt of the BG*, issues BGACK*, and releases BERR* and HALT*. Then, with the aid of a little external glue (address latches, etc), the fault processor fixes the memory image at the faulted address, and releases the BGACK* line. The run processor will rerun the faulted cycle using the same address, data, control signals, etc. Actually, with this method, even a very complex management scheme can be designed. And, with the price (1000 pc qtys) of 8 MHz 68K's being about 1/4 that of 68451 MMU's, the price *disadvantage* of using a fault processor is almost non-existant. (remember that all mapping circuitry will have to be added). Also, assuming the mapping can be made sufficiently fast, this method has some neat advantages. ***************************************************************************** Disclaimer: The opinions expressed herein are all mine. Motorola pays me to think, but not to express corporate policy. ***************************************************************************** Tom Johnson
dyer@atari.UUcp (Landon Dyer) (08/21/86)
In article <4374@gatech.CSNET>, jeff@gatech.CSNET (Jeff Lee) writes: > You could do > the same with a 68000. With a couple of 35ns rams and some address > decoding (to map them into memory) you can implement a similar type of > MMU. For system level access, you bypass the rams and physical and logical > memory are the same. The OS loads the memory mapping rams with the > appropriate address and dispatches the process. While in user mode, the > high order bits are remapped into different physical locations (going > through the MMU rams). You access something that you are not supposed > to and you take a bus error. It's a nice idea in general . . . but not on the ST. Address timing is *so* critical that running the address lines through a 35ns RAM would result in missing RAS and/or CAS windows on the DRAMs. Bad things happen. The other gotcha is that by the time the lookup RAM can indicate if a location should generate a bus error, the memory controller is already comitted to the read or write cycle. You'd have to map every unused page to some piece of scratch RAM. We looked at this many months ago, and went a different route.... -- -Landon Dyer, Atari Corp. {sun,lll-lcc,lll-crg!vecpyr}!atari!dyer /-----------------------------------------------\ | The views represented here do not necessarily | "If Business is War, then | reflect those of Atari Corp., or even my own. | I'm a Prisoner of Business!" \-----------------------------------------------/
clewis@spectrix.UUCP (Chris Lewis) (08/22/86)
In article <753@oakhill.UUCP> tomj@oakhill.UUCP (Tom Johnson) writes: >In article <162@puff.UUCP> scott@puff.UUCP (Scott Aschenbach) writes: >>In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes: >>> In article <508@elmgate.UUCP> jdg@elmgate.UUCP writes: >>> ... >>> >If memory serves me correct the 68000 can not restart/resume a bus faulted >>> >instruction... >>... >>I though I heard of someone using pairs of 68000's before the 68010s >>came out. One was set to run just a bit ahead of the other, so that >>the first faulted, and the second was in the state the first one should >>be in when it was restarted. > >Close. Actually, one of the processors is set-up as the "run" processor, >and the other as the "fault" processor. The run processor executes all >normal program instructions, and has its bus cycles terminated with a >DTACK*. If a bus cycle faults, the BERR* signal goes only to the fault >processor. It then issues a "relinquish and retry" (BERR*, HALT*, BR*) to >the run processor which immediately terminates the "faulted" bus cycle, >saves the access address internally for later use, and issues a BG*. The >fault processor, upon receipt of the BG*, issues BGACK*, and releases BERR* >and HALT*. Then, with the aid of a little external glue (address latches, >etc), the fault processor fixes the memory image at the faulted address, and >releases the BGACK* line. The run processor will rerun the faulted cycle >using the same address, data, control signals, etc. As I remember the paper (though it may very well mean the same thing - I'm not an expert on 68k pins - this may be more understandable tho) - when the "run" processor attempts to perform a memory access that will fault, it is HALTED in the midst of the access instead of bus error'd. Then the "fault" processor wakes up, examines the state of the various control signals, and stuffs the proper page "underneath" where the "run" processor is accessing. Then the fault processor turns off HALT to the run processor, and goes back to sleep. The run processor then merely finishes the access (possibly a longggggg time later). The cycle wasn't interrupted at all. >Actually, with this method, even a very complex management scheme can be >designed. And, with the price (1000 pc qtys) of 8 MHz 68K's being about >1/4 that of 68451 MMU's, the price *disadvantage* of using a fault processor >is almost non-existant. (remember that all mapping circuitry will have >to be added). Also, assuming the mapping can be made sufficiently fast, this >method has some neat advantages. As I remember it there are two major disadvantages: 1) the circuitry is likely to use up an awful lot of board real-estate. And if you don't think that's a problem, take a look at a MVME117 or 131 or one of our CPU boards one day.... (talk about stuffed!) 2) During page fault handling, the run processor is hung. That means, for instance, while the fault processor is spending it's 50 some-odd milliseconds trying to read a page in, the run processor is missing all interrupts, unable to task switch, unable to do *anything*... In a paging system, being able to run another task while a page fault is being handled is essential for any reasonable level of performance. If you ever started to thrash, the run processor would hardly ever run. It was a neat idea, and a few machines were built, but I don't think that the result was very useful when compared to a machine with a "real" MMU (that is, *not* a '451). -- Chris Lewis UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis Phone: (416)-474-1955
dhp@ihlpa.UUCP (Douglas H. Price) (08/23/86)
> Just because you are implementing "paging" does not mean that you must > implement "demand paging". The PDP-11 had memory mapping registers but > did not allow demand paging. Before a process ran you had to ensure that > all the memory they were allowed to access was resident. > > Jeff Lee > CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA > uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff Wrongo, Oh Bit Breath! PDP-11s from an 11/44 on up can demand-page quite well, thank you, though rather inefficiently. I used to work for a firm called Datalogics, in Chicago, IL, which had a demand paged operating system called DURESS which had originally been written in about 1977 as a derivative of RT-11 and RSX-11D. This operating system used all three address spaces (USER, SUPERVISOR and KERNEL) and was fully demand paged. In fact, you will find there is a service order available on the PDP-11/44 designed to correct a bug in the memory managment unit that we turned up when we first tried to port DURESS to it. Another comment; DURESS could run proverbial rings around the available UNIX versions of that era. It made a PDP-11 look like a real machine to the user in terms of performance. On the other hand, it had a really grungy programmer interface, and a semi-flat file system (yuck!) PDPs less than an 11/44 (11/23 through the 11/34) had a simplified memory manager which did away with SUPERVISOR space, and split I and D, which in my opinion severely crippled them. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihlpa!dhp
henry@utzoo.UUCP (Henry Spencer) (08/26/86)
> If memory serves me correct the 68000 can not restart/resume a bus faulted > instruction. So regardless of what mkind of MMU you try to hang on it, it > can not overcome this problem. That's right. On the other hand, being unable to restart a faulted instruction (in the general case) only means you can't do demand paging, or similar schemes where you want to pretend memory is always there when it sometimes isn't. The inability to do this is a wart, but it does not preclude doing useful things like running Unix. This message is being typed on a PDP-11/44 running V7, which doesn't do virtual memory but is still a fine system if you don't want to run huge programs. The MMU on the 44 can actually do demand paging, although it's not clear that it's worthwhile given various complications, but V7 doesn't use it that way. Relocation and protection is all you need to run a multiprogramming system simply and well. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (08/26/86)
> I have heard people claim that there is enough information around > after a bus error ( or address error ) to restart most instructions, > if the bus error handler is willing to be clever. However, I haven't > seen any actual code... Anyone know if this is true? If so, what > are the instructions that can't be restarted? Probably true. The 68000 is a sort of mutated PDP-11, and software on the 11 could backtrack well enough to restart most instructions. This is what Unix on the 11/40, 34, 23, 60, et al did/does. The major problem comes when an instruction modifies registers: which registers did it modify before it died? The larger 11s had an MMU which would tell you. The cut-down version of the MMU, which is what the 40 et al had/have, won't. So the software has to guess. It can usually guess right. The fundamentally intractable cases are where the instruction modifies the same register more than once, and you can't tell how many times it did it before the fault. The automatic stack growth on small-11 Unixes would generally fail if you used something like "cmp -(sp), -(sp)" to grow the stack two words; I believe the compiler never did this, and assembler programmers simply had to look out for themselves. On the 68000 it's worse, because important and useful instructions like move-multiple can modify the same register several times. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jans@tekecs.UUCP (Jan Steinman) (08/27/86)
In article <270@dmsd.UUCP> bass@dmsd.UUCP (John Bass) writes: >In article <653@cbmvax.cbmvax.cbm.UUCP>, grr@cbmvax.cbm.UUCP (George Robbins) writes: >> A reasonable attitute, but remember that both the Amiga and Atari were >> intended to be affordable machines... > >Consider that (for) a simple paging mmu... we are talking under $45 at >the shelf. This is the difference between the ST being a game machine and >having the support for process issolation and error detection for a strong >bussiness machine. I don't quite buy that. Look at the #1 business machine -- what kind of MMU does it have? The Atari has just about the same features as the IBM PC -- including lack of reasonable system software. The Amiga at least made an attempt to make up for the lack of an MMU with good system software. -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
bass@dmsd.UUCP (John Bass) (08/28/86)
In article <417@atari.UUcp>, dyer@atari.UUcp (Landon Dyer) writes: > In article <4374@gatech.CSNET>, jeff@gatech.CSNET (Jeff Lee) writes: > > You could do > > the same with a 68000. With a couple of 35ns rams and some address > > decoding (to map them into memory) you can implement a similar type of > > ....... > > It's a nice idea in general . . . but not on the ST. Address > timing is *so* critical that running the address lines through a > 35ns RAM would result in missing RAS and/or CAS windows on the > DRAMs. Bad things happen. By design, this can be a non-problem. Drams have three parts to each cycle: 1) RAS/CAS precharge -- Overlapped with end/begining of M68k cycle 2) RAS/Row address -- taken from M68k address lines after AS asserted 3) CAS/Col address -- taken from MMU result after delay from AS asserted The delay from RAS to CAS required/accepted by most DRAMS is about the same is running the address lines thru a mapping ram or adder/comparator based mmu. Addresses and function codes precede AS by half a clock giving a little more head room. RAS can be started without knowing if the translation will be valid, since witholding CAS is a refresh cycle. > > The other gotcha is that by the time the lookup RAM can indicate > if a location should generate a bus error, the memory controller > is already comitted to the read or write cycle. You'd have to > map every unused page to some piece of scratch RAM. Using a mapping ram, two of the outputs are valid and write-protect allowing: RAS := AS2RAS_DELAY * AS DTACK:= AS2RAS_DELAY * AS * MEM_ACCESS + ROM_DELAY * AS * ROM_ACCESS + IO_DELAY * AS * IO_DTACK CAS := RAS2CAS_DELAY * AS * MEM_ACCESS * VALID * RW + RAS2CAS_DELAY * AS * MEM_ACCESS * VALID * /RW * WPROT BERR := RAS2CAS_DELAY * AS * MEM_ACCESS * /VALID + RAS2CAS_DELAY * AS * MEM_ACCESS * * RW * /WPROT NOTE: the delay terms can be external (delay lines??) or state terms from on-chip counter/sequencer outputs. Since you can determine a fault at CAS time, CAS is withheld to prevent writing. DTACK is given early, and BERR asserted on a fault. Target data is protected during the fault for both reads and writes. It can't be done that way???? We currently run 16mhz 4-CLK memory cycles using 120ns DRAMS and a $15.00 mapping ram based mmu (4-CLK cycles are zero wait state for the M68000, and 1 wait state for the M68020 which uses 3-CLK memory cycles). Stop by next month and we will show you our M68020 UNIX SBC running 3-CLK memory cycles at 16mhz with our mapping ram mmu and 80ns DRAMS. Still not convinced, order now and we will save one from the October build for you to try yourself (starting from $1,800 + tax and shipping). For a 8mhz M68000 the above the timings are all a piece of cake, including cycle-stealing arbitration for display accesses. > > We looked at this many months ago, and went a different route.... MMU's are left out of toy computers because toy engineers don't know how to design real computers -- NOT because they take to much time (the above solves that problem) or because they cost too much (two mapping rams cost less than $10 in volume, and the rest of the circuit could have been dumped into the custom parts or pals already on the board -- an adder/comparator design could have been placed in the custom parts for nearly zero additional production cost). Ditto for memory parity. MMU's are also left out of toy computers because toy programmers don't know how to use an mmu, because toy marketing/sales don't care, and many toy buyers don't care. If you want a toy computer buy one, I like my toy Mac, I can even do some real work on it ... the cost of ownership could have been lower though if less development time had been spent by it's programmers fighting the memory manager and lack of process/os protection from software faults. With an mmu, certain failures can be identified much earlier, allowing the product to mature faster and reach market sooner and possibly stay on the market longer by supporting CLEAN multiuser/multitasking ... thus being more profitable in the LONG RUN. MMU's are left out of systems due to short term thinking. -- John Bass (DBA:DMS Design) DMS Design (System Design, Performance and Arch Consultants) {amdahl,fortune,polyslo}!dmsd!bass
cmcmanis@sun.uucp (Chuck McManis) (08/28/86)
In article <7578@tekecs.UUCP> jans@tekecs.UUCP (Jan Steinman) writes : > > I don't quite buy that. Look at the #1 business machine -- what kind of MMU > does it have? The Atari has just about the same features as the IBM PC -- > including lack of reasonable system software. The Amiga at least made an > attempt to make up for the lack of an MMU with good system software. > -- > :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: > :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: > :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 :::::: Two points here, one neither the Atari nor the 8088 based PC try to multitask. The AT has an MMU built into the '286. Lets not debate this issue yet again (the last time the consensus was "Multitasking is a lot safer with an MMU, however with clever system software and reasonably well behaved programs it is not required.") -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/28/86)
I would like to point out that memory manegment is not usually worth the price in small microcomputers UNLESS it goes hand in hand with multi-processing. So: (1) The IBM PC is not inherently multi-processing. (2) The ST is not inherently multi-processing. (3) The Amiga OS is not designed to accomodate a MMU. I do agree that the Amiga would have been a nicer machine if it had been designed around a MMU, but neither the hardware or software was. -Matt
freed@aum.UUCP (Erik Freed) (08/29/86)
> The delay from RAS to CAS required/accepted by most DRAMS is about the same > is running the address lines thru a mapping ram or adder/comparator based mmu. > Addresses and function codes precede AS by half a clock giving a little more > head room. RAS can be started without knowing if the translation will be > valid, since witholding CAS is a refresh cycle. > The basic arguments seem real sound as presented by this gentlemen and I myself wondered why it would be so difficult to add memory management. I wish that he had worked on the ST!!. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA ptsfa!aum!freed
tmb@mit-prep.ARPA (Thomas M. Breuel) (08/29/86)
||Consider that (for) a simple paging mmu... we are talking under $45 at ||the shelf. This is the difference between the ST being a game machine and ||having the support for process issolation and error detection for a strong ||bussiness machine. | |I don't quite buy that. Look at the #1 business machine -- what kind of MMU |does it have? The Atari has just about the same features as the IBM PC -- |including lack of reasonable system software. The Amiga at least made an |attempt to make up for the lack of an MMU with good system software. The IBM PC has a better MMU than the Atari. While segment registers are awfully annoying if you try to program the 8088 as a machine with a 20 bit address space, they do provide you with a memory model that is very similar to the PDP-11 with separate I/D. That is probably one of the reasons why there is UN*X for the IBM PC but not for the Atari. You can achieve a similar effect by using only indexed addressing on a 68000, but on a 68000 you really lose a lot by doing so. Thomas.
eric@chronon.UUCP (Eric Black) (08/29/86)
In article <510@elmgate.UUCP> jdg@elmgate.UUCP (Jeff Gortatowsky) writes: >In article <64@mit-prep.ARPA>, tmb@mit-prep.ARPA (Thomas M. Breuel) writes: >> However, an MMU has other uses besides paging, e.g. to protect processes >> from one another, to help utilise memory more efficiently, and >> to allow swapping and process duplication (a la fork(1); you can't >> implement fork(1), in general, on the 68000 without an MMU). >> >> I consider it a grave mistake not to have included even a rudimentary kind >> of address remapping on the Amiga; even just an adder on the address lines >> of the 68000 would have simplified the system software and allowed some >> kind of swapping to be hacked. >> >> Thomas. > >I understand your first paragraph completely. But you lost me on the second. >I can see where a MMU that provides protection only would be useful but >address mapping is still of no use. Not without a 68010, admittedly an >easy upgrade, but not provided. If you mapped a some address block to >another would you not HAVE to ensure it was a legal RAM/ROM address? One >faulty address and your back to GURU type crashes, yes? I guess it be >nice to learn from you what type of paging you could implement with just an >adder, etc. Enlighten me. Mail if you must. Post if it seems of general >interest to all 68000 based machines. Just recently there was a fair amount of discussion in net.micro.amiga about the difficulties of making shareable code. One of the biggest difficulties is generating code which can use distinct parts of memory for data for each of the processes/tasks/threads/whatever sharing the one copy of the code. There are ways of doing this for the 68K, but unfortunately none of the compilers currently available for the Amiga do this well, if at all. Protection issues aside, it sure would be nice to be able to compile & link my program so that it uses a data segment starting at some particular address which gets mapped by something MMU-like to the address of a memory block allocated by the OS when I start to run the program. And hey, I could do that for the code, too, and keep executable images on the disk as a memory image, instead of a "hunk" file, so that loading the program consists of allocating memory, reading from the disk into memory, setting the memory map correctly, and going. The hunk scheme used by the Amiga results in the CPU having to touch everything when loading a program, even if you had a hard disk with fast DMA. There are real advantages to be had from a simple address mapping scheme. Protection is nice, especially on a multitasking machine, but is a separate issue. Demand paging, implying the ability to restart an instruction which faulted, is yet another separate issue. -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric >>>> after Sept 1: <<<< {sun,pyramid,hplabs,amdcad}!cti!eric ^^^
wen-king@cit-vlsi.Caltech.Edu (Wen-King Su) (08/30/86)
<<->> This is only a note on John Bass's article about a way to do virtual memory with little or no extra cost in time. There is a catch to hiding MMU operations between RAS and CAS, though I do not know whether this applies to the ST. The high speed CAS only block transfer operation available in many DRAMs is rendered useless since contiguous column addresses in a DRAM chip are no longer contiguous in 68K's address space. I am not familiar with the graphic hardware of the ST, but the block transfer modes of the DRAM chips are well suited for high speed sequential access of blocks of memory that is typical to bitmap graphic systems.
grr@cbmvax.cbm.UUCP (George Robbins) (08/30/86)
In article <937@cit-vax.Caltech.Edu> wen-king@cit-vlsi.UUCP (Wen-King Su) writes: ><<->> > >This is only a note on John Bass's article about a way to do virtual >memory with little or no extra cost in time. There is a catch to >hiding MMU operations between RAS and CAS, though I do not know whether >this applies to the ST. The high speed CAS only block transfer >operation available in many DRAMs is rendered useless since contiguous >column addresses in a DRAM chip are no longer contiguous in 68K's >address space. I am not familiar with the graphic hardware of the ST, >but the block transfer modes of the DRAM chips are well suited for high >speed sequential access of blocks of memory that is typical to bitmap >graphic systems. This isn't really too much of a problem, since implementing page mode operations for the processor is really not much fun without some clues from the cpu (see Fairchild Clipper and Z80,000). The big loss is with graphics, especially with video DRAM, since you loose the linear relation between addresses and shift-register or page mode accesses. Of course one can argue that the display memory need not be relocated, perhaps just protected via a storage key of some sort, but then your system is starting to get complicated... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jeff@gatech.CSNET (Jeff Lee) (08/31/86)
In article <937@cit-vax.Caltech.Edu> wen-king@cit-vlsi.UUCP (Wen-King Su) writes: > The high speed CAS only block transfer >operation available in many DRAMs is rendered useless since contiguous >column addresses in a DRAM chip are no longer contiguous in 68K's >address space. If you are talking about nibble-accessible rams, the ones that I saw operate only on mod-4 boundaries and each time you strobe the CAS they return the next bit circularly (mod-4). Since the memory management schemes that I am familiar with use 2^N boundaries (N > 2), this should be no problem. But then, you might be talking about another (even newer) type of ram that I'm not familiar with. Speaking of which, does anyone know of a REAL (ie - available off the shelf, now) system that actually uses the nibble mode of some of the newer rams. It looks like a great way to load your cache quickly with some of the bus-hog multiprocessors that are becoming available now (Encore, Sequent, etc...). They already load 64 bits of memory at a time onto the separate processor cards when they need to hit main memory. -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
gnu@hoptoad.uucp (John Gilmore) (08/31/86)
In article <4422@gatech.CSNET>, jeff@gatech.CSNET (Jeff Lee) writes: >> ...contiguous >>column addresses in a DRAM chip are no longer contiguous in 68K's >>address space. >If you are talking about nibble-accessible rams... There are many types of RAMs where accessing columns is faster than accessing rows. Nibble mode, where you can toggle CAS and get out 4 bits; page mode, where you can drop CAS, set up a new column address, and enable CAS again; and static column mode, where you can just change the column address on the fly, wait the column access time, then look at the data. There are also video RAMs which scan data out serially by columns. > ...does anyone know of a REAL (ie - available off the > shelf, now) system that actually uses the nibble mode of some of the > newer rams... I do not remember if the new cached Sun uses nibble mode (or other fast column mode) RAMs. Part of the problem is that designers don't want to require nibble mode RAMs, since they usually cost more than "any old RAMs". Designing to the least common denominator in RAMs [modulo what speed you need] is very useful for reducing prices. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
grr@cbmvax.cbm.UUCP (George Robbins) (09/01/86)
In article <271@dmsd.UUCP> bass@dmsd.UUCP (John Bass) writes: > [ omitted - description of simplified Sun derivative MMU design ] > >MMU's are left out of toy computers because toy engineers don't know how >to design real computers -- NOT because they take to much time (the above >solves that problem) or because they cost too much (two mapping rams cost >less than $10 in volume, and the rest of the circuit could have been dumped >into the custom parts or pals already on the board -- an adder/comparator >design could have been placed in the custom parts for nearly zero additional >production cost). Ditto for memory parity. > >John Bass (DBA:DMS Design) Gee John, around here we smile when we say 'Toy Computer...'. I think you are making a mistake in confusing intent with ability. The engineers working at the consumer level would love to slip in an MMU function, but when the time comes to meet to cost criteria, it gets crossed out with a long sigh. The cuts are on dime and dollar issues, let alone a ten! The engineers in Shivji's gang, prior to moving to Atari were working on a Z8000 based game/graphics/unix type box. It had a MMU, which coincidentally did translation in the RAS/CAS delay. The ST can be viewed as a 68000 based derivative of this effort. The Amiga, on the other hand, consists of a high-performance graphics processor complex, memory and display, with a 68000 added on to tickle the graphics chips and interface to the real world. In a sense the software exists to drive the engine, not the engine existing to run some generic software. The real obstacle to putting in an MMU is the lack of any real world software at that level that would make it seem a neccessary item. Unix tends to make the minumum machine too expensive (hard disk and license fees). With two years of hindsight, OS/9 68K level 2 might look like a good choice, but even now, Microware doesn't seen too speedy in delivering their Amiga and ST ports. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jeff@gatech.CSNET (Jeff Lee) (09/02/86)
In article <1045@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >> >> ...does anyone know of a REAL (ie - available off the >> shelf, now) system that actually uses the nibble mode of some of the >> newer rams... > >I do not remember if the new cached Sun uses nibble mode (or other >fast column mode) RAMs. > >Part of the problem is that designers don't want to require nibble mode >RAMs, since they usually cost more than "any old RAMs". Designing to >the least common denominator in RAMs [modulo what speed you need] >is very useful for reducing prices. Speaking of the new SUN, I just saw it come through "The Monthly Report" in the August UNIX Review. For folks who may not have seen it, here are (what I consider to be) the highlights. "Designed to address those traditional scientific/engineering tasks that tend to be computebound (such as electrical and mechanical CAD, geophysical analysis and AI), the SUN-3/200 series features the 25 MHz 68020, a 20 MHz 68881 floating point co-processor, and a proprietary MMU." ... talk of 4 MIPS integer performance ... "Also available is SUN's optional Floating Point Accelerator (FPA) which is said to perform 32 and 64-bit floating point calculations at rates as high as 865 KFLOPS, according to the workstation vendor." "To maximize throughput, the machine has a 64 KB virtual-address, write-back memory cache and 64-bit processor-memory bus. The 3/200 also comes with up to 32 MB of memory, and -- with teh use of four of SUN's new 575 MB disks -- up to 2.3 GB of mass storage capapcity." "SUN is showing the new machines at trade shows this month (AAAI and SIGGRAPH), and is promising shipment within 90 days. The price on the SUN-3/260HM (high-resolution monochrome) base system, including 12-slot card cage and 8 MB memory, is pegged at $33,900; with a 280 MB disk drive and 1/4-inch tape, the cost goes up to $51,500. The base configuration for the 3/260C (color) station is $44,900; with disk and tape, $62,500." Since this may not thrill atari and amiga folks, I restricted followups to this message to net.micro.68k. Enjoy... -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
ludemann@sun.UUCP (09/07/86)
> > > You could do > > > the same with a 68000. With a couple of 35ns rams and some address > > > decoding (to map them into memory) you can implement a similar type of > > > ....... > > > > It's a nice idea in general . . . but not on the ST. Address > > timing is *so* critical that running the address lines through a > > 35ns RAM would result in missing RAS and/or CAS windows on the > > DRAMs. Bad things happen. > > By design, this can be a non-problem. Drams have three parts to each cycle: > > 1) RAS/CAS precharge -- Overlapped with end/begining of M68k cycle > 2) RAS/Row address -- taken from M68k address lines after AS asserted > 3) CAS/Col address -- taken from MMU result after delay from AS asserted > > The delay from RAS to CAS required/accepted by most DRAMS is about the same > is running the address lines thru a mapping ram or adder/comparator based mmu. > Addresses and function codes precede AS by half a clock giving a little more > head room. RAS can be started without knowing if the translation will be > valid, since witholding CAS is a refresh cycle. > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent (applied for and granted) on using the untranslated addresses as the RAS addresses and doing the MMU address translation before the column addresses are needed for CAS. Sooner or later, it's going to cost some competitors a WHOLE lot of money. -- -Jim Ludemann "186,000 miles per second. It's not just a good idea, it's the law."
rokicki@navajo.UUCP (09/08/86)
In article <6985@sun.uucp>, ludemann@sun.uucp (Jim Ludemann) writes: > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > (applied for and granted) on using the untranslated addresses as the > RAS addresses and doing the MMU address translation before the column > addresses are needed for CAS. Sooner or later, it's going to cost some > competitors a WHOLE lot of money. How the hell can the patent office grant patents like this? It's sort of like patenting the idea of grounding DTACK on a 68000 or putting chocolate ice cream in root beer; the idea is too obvious. To coin a phrase, it's patently ridiculous. -tom
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/86)
>I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent >(applied for and granted) on using the untranslated addresses as the >RAS addresses and doing the MMU address translation before the column >addresses are needed for CAS. Sooner or later, it's going to cost some >competitors a WHOLE lot of money. Wrong. The idea is too universal for any lawsuit that would come about from it to hold up in court... It's like patenting a FOR loop. Additionaly, you can easily get around the patent by passing ALL the address lines through to the MMU, and spec'ing a faster time input->output for the LSB address lines. There is no mention of dynamic anything in the MMU, and all a dynamic ram board sees are half the address lines immediately available for processing, and the other half not-yet available. Physically, almost every MMU these days pass the LSB N-bits (depending on the page side) anyway, but simply latch them all at once on the output. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/86)
It's also like patenting the fact that you can interleave a 68000 or 6502 (or any other processor that's half on and half off the BUS). -Matt
ed@mtxinu.UUCP (Ed Gould) (09/09/86)
>> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent >> (applied for and granted) on using the untranslated addresses as the >> RAS addresses and doing the MMU address translation before the column >> addresses are needed for CAS. > >How the hell can the patent office grant patents like this? It's sort >of like patenting the idea of grounding DTACK on a 68000 or putting >chocolate ice cream in root beer; the idea is too obvious. To coin a >phrase, it's patently ridiculous. If it's so obvious, why didn't anyone think of it before Andy did? Is the Set-UID bit (also patented) any less obvious? Not to me, now that I've seen them both. But I never thought of them; neither did anyone else, evidently, before their respective inventors. The person who first put chocolate ice cream into root beer probably didn't realize what they'd done. They should have patented it, too! (Unless, of course, someone had already done the same thing with vanilla ice cream. Then *they* should have pattented it.) The real question, to me, is (since the original poster suggested that Sun's competitors would have to start paying for this idea) Who really owns the patent? The idea was developed while Andy was at Stanford, possibly (I have no idea, one way or the other) with public money. If it was developed with Federal money, then policy says that there will be no fees for use of the patent. If Sun owns it, then there probably will be fees. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
cms@vlsvax1.UUCP (Chuck M. Sweeney) (09/10/86)
In article <823@navajo.STANFORD.EDU> rokicki@navajo.UUCP writes: >In article <6985@sun.uucp>, ludemann@sun.uucp (Jim Ludemann) writes: >> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent >> (applied for and granted) on using the untranslated addresses as the >> RAS addresses and doing the MMU address translation before the column >> addresses are needed for CAS. Sooner or later, it's going to cost some >> competitors a WHOLE lot of money. > >How the hell can the patent office grant patents like this? It's sort >of like patenting the idea of grounding DTACK on a 68000 or putting >chocolate ice cream in root beer; the idea is too obvious. To coin a >phrase, it's patently ridiculous. > One of the criteria the patent office uses (or is supposed to) in granting a patent is that a modification to an existing device/process cannot be obvious to a person of usual competence in the field. Perhaps they felt that it would take unusual competence to figure this one out? (:-) Sweeney
henry@utzoo.UUCP (Henry Spencer) (09/11/86)
> > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > > (applied for and granted) on using the untranslated addresses as the > > RAS addresses and doing the MMU address translation before the column > > addresses are needed for CAS. Sooner or later, it's going to cost some > > competitors a WHOLE lot of money. > > How the hell can the patent office grant patents like this? ... > ... the idea is too obvious. The patent office is not omniscient, and the idea certainly wasn't as widely known five years ago as it is today. It's fairly likely that *somebody* *somewhere* had the idea earlier, and can prove it -- for example, I'm fairly sure at least one blurb for some early MMU chip mentioned the notion -- but it's asking a bit much to expect the Patent Office to know this. Ignoring for the moment the question of whether Andy's then-current employer has some say in the matter, what will happen is that Andy will be able to go out and ask assorted competitors for royalties. There's a fair chance that most of them will pay rather than fight, if he's reasonable about amounts. If he's not, or if somebody decides to balk, there will be a court battle, which Andy probably will lose. The idea is too simple; my guess would be that a vigorous literature search will turn up either prior publication of the idea or something close enough to make the final step "obvious to one skilled in the art", either of which invalidates the patent. In recent years, as I recall, most court challenges to patents have succeeded: it's too hard to come up with something that is really and totally new. Andy's best tactic would be to ask for a modest royalty that's not worth fighting. The chances of successfully gouging someone for a "WHOLE lot" of money aren't good unless he deliberately picks an ailing victim who can't afford a fight. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
csc@watmath.UUCP (Jan Gray) (09/11/86)
In article <79@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent >>> (applied for and granted) on using the untranslated addresses as the >>> RAS addresses and doing the MMU address translation before the column >>> addresses are needed for CAS. >> >>How the hell can the patent office grant patents like this? It's sort >>of like patenting the idea of grounding DTACK on a 68000 or putting >>chocolate ice cream in root beer; the idea is too obvious. To coin a >>phrase, it's patently ridiculous. > >If it's so obvious, why didn't anyone think of it before Andy did? I did; it's the obvious way of building an MMU that doesn't introduce extra wait states, and applies to the 68K family because the other common 16/32 bit CPUs don't require custom MMUs. >Is the Set-UID bit (also patented) any less obvious? Not to me, >now that I've seen them both. But I never thought of them; neither >did anyone else, evidently, before their respective inventors. Like the guy who patented the xor cursor, or Apple's pull-down menu patent, I'll believe it when it holds up in court. Jan Gray Northern Software and University of Waterloo 885-5921
magore@watdcsu.UUCP (M.A.Gore - ICR) (09/11/86)
In article <79@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent >>> (applied for and granted) on using the untranslated addresses as the >>> RAS addresses and doing the MMU address translation before the column >>> addresses are needed for CAS. >> >>How the hell can the patent office grant patents like this? It's sort >>of like patenting the idea of grounding DTACK on a 68000 or putting >>chocolate ice cream in root beer; the idea is too obvious. To coin a >>phrase, it's patently ridiculous. > >If it's so obvious, why didn't anyone think of it before Andy did? >Is the Set-UID bit (also patented) any less obvious? Not to me, >now that I've seen them both. But I never thought of them; neither >did anyone else, evidently, before their respective inventors. > >The person who first put chocolate ice cream into root beer probably >didn't realize what they'd done. They should have patented it, too! >(Unless, of course, someone had already done the same thing with >vanilla ice cream. Then *they* should have pattented it.) > >The real question, to me, is (since the original poster suggested that >Sun's competitors would have to start paying for this idea) Who really >owns the patent? The idea was developed while Andy was at Stanford, >possibly (I have no idea, one way or the other) with public money. >If it was developed with Federal money, then policy says that there >will be no fees for use of the patent. If Sun owns it, then there >probably will be fees. > >-- The problem is that the idea IS old... Many companies have used the idea for paged MMU's. The idea would be obvious to people who design high speed memory systems. High speed memory that uses RAS/MULTIPLE CAS to cut down on access. When you think of one event followed by another you *try* to do things in parallel while waiting. The question and point I am making is two fold (OLD IDEA) and OBVIOUS) *in the circles of memory design*. I'm really worried more about the *general case* of having our common thinking patented. Or THEFT of ideas that are in current use for profit. Some simple ideas don't have patents for similar reasons that not all people use locks. Here the theif can make you pay... The later comment should in no way be implied with SUN, it is an echo of general concern that effects many of us. If someone comes up with something *new* and our knowledge is extended then great, give a patent! I would like to say that I understand Sun uses the method of RAS/CAS delay decode. Perhaps they were the *first* and had the idea shortly after DRAM's came out. Then my idea of OLD would be out..... > 10 years. In any case I am quite interested in why they think they can get a patent. Because if such simple ideas can be patented then it would be a good education for all of us. # Mike Gore # Institute for Computer Research. # These ideas/concepts *do not* imply views held by the University of Waterloo.
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/11/86)
> Xref: cbmvax net.micro.atari16:1841 net.micro.amiga:2519 net.micro.68k:260 > > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > (applied for and granted) on using the untranslated addresses as the > RAS addresses and doing the MMU address translation before the column > addresses are needed for CAS. Any idea of when he patented this? This is a very common idea, doesn't sound like something you could patent. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
rokicki@navajo.STANFORD.EDU (Tomas Rokicki) (09/11/86)
In article <79@mtxinu.UUCP>, ed@mtxinu.UUCP (Ed Gould) writes: > >> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > >> (applied for and granted) on using the untranslated addresses as the > >> RAS addresses and doing the MMU address translation before the column > >> addresses are needed for CAS. > > > >How the hell can the patent office grant patents like this? It's sort > >of like patenting the idea of grounding DTACK on a 68000 or putting > >chocolate ice cream in root beer; the idea is too obvious. To coin a > >phrase, it's patently ridiculous. > > If it's so obvious, why didn't anyone think of it before Andy did? Let's look at this for a minute. You have the following problem: ) you want virtual to physical address mapping ) standard practice is to map only the high order bits (this predates Andy by a good long time) ) virtual to physical mapping takes some time ) you want to use dynamic rams ) dynamic rams require half of the address, and then, some delay later, the other half ) Gee, Wally, what do we do now? It's not that nobody thought of it before, but nobody patented it. It's not a clever idea; it's the only reasonable solution. I had a design like this for the 6809 and dynamic memory before the 68000 even came out; I just never built it. It bothers me that such ideas can be patentable. When you design a new machine, these patents can restrict your design space; if they start patenting all the good solutions to common problems, what do we have left to design with? -tom
wall@fortune.UUCP (Jim Wall) (09/12/86)
The Sun patent is only valid until it holds up in a patent court. I believe that it can be argued on any of several fronts. One is that it is obvious using the existing technology of the times, which is grounds for not granting (or voiding) patents. THe other would be that it was done and documented prior to the patent. Personally, I have documentation that it was discussed here at Fortune five years ago, and I haven't even tried to look any harder than that. Does anyone know when the patent disclosure was filed for the Sun MMU patent? Aw well, I knew I should have filed for those ideas I had, using PALs to decode address spaces, using ROMs as clocked state machines, using memory to store information in..... -Jim Wall ...amd!fortune!wall
garyo@masscomp.UUCP (Gary Oberbrunner) (09/13/86)
In article <6985@sun.uucp>, ludemann@sun.uucp (Jim Ludemann) writes: > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > (applied for and granted) on using the untranslated addresses as the > RAS addresses and doing the MMU address translation before the column > addresses are needed for CAS. Sooner or later, it's going to cost some > competitors a WHOLE lot of money. Yes, folks, I can believe this man. I have in my office right now a patent (which has been successfully contested) on xoring cursors into a frame buffer, so they can be easily erased. The patent also apparently applies to rubber-band lines in xor mode. I also have another one (can you believe this? it's true!) on the transformation equations for perspective projection on a display screen, and their implementation in a digital computer. This one has also been fought, and although the original scope of the patent was much reduced (the guy can now only soak you if you use HIS FORM of the equations), the patent was upheld, not once but several times (I have a sheaf of court documents all about this case - if you're interested in this sicko stuff mail me and I'll provide references). I don't have the numbers or the authors right here, but if you're interested I can mail them to you. It's a mad, mad, mad, mad, mad, MAD world. - Gary Oberbrunner ...!{harvard,allegra}!masscomp!garyo
jnw@mcnc.UUCP (John White) (09/13/86)
In article <823@navajo.STANFORD.EDU>, rokicki@navajo.STANFORD.EDU (Tomas Rokicki) writes: > In article <6985@sun.uucp>, ludemann@sun.uucp (Jim Ludemann) writes: > > I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > > (applied for and granted) on using the untranslated addresses as the > > RAS addresses and doing the MMU address translation before the column > > addresses are needed for CAS. Sooner or later, it's going to cost some > > competitors a WHOLE lot of money. > > How the hell can the patent office grant patents like this? It's sort > of like patenting the idea of grounding DTACK on a 68000 or putting > chocolate ice cream in root beer; the idea is too obvious. To coin a > phrase, it's patently ridiculous. > I don't think that you will convince many people that something is obvious just by saying that it is so, you need to provide an argument. For example: Supose that a designer wants to connect some DRAM to a processor through some sort of memory management (MMU). Let the processor provide an address, and a signal that says that the address is ready and a memory cycle should occur. Also, assume that the bus is a custom one, and that the designer is free to define it. First, the upper part of the address from the processor is passed through the MMU. Putting only the upper part of the address through the MMU is a common practice. Then, the address is passed to the DRAMs. It is common practice to have the lower part of the address go to the row address of the DRAMs, as this makes it easier to handle refresh. Now, the designer must figure out how to select only one bank of DRAMs. According to the spec sheets, he can either provide the RAS strobe to just the selected bank, or he can provide the CAS strobe to just that bank. Let's assume that the CAS strobe is used for selecting the desired bank, and that the RAS strobe is sent to all the DRAMs. Now the designer wants to minimize the number of wait states needed. The access time of the DRAMs is specified from the RAS strobe to data ready, so the RAS strobe should occur as soon as possible. The RAS strobe must not occur before the row address, but as the row address is stable when the processor requests a memory cycle, this request can be used to trigger the RAS strobe immediatly. With a few simple assumptions about the sort of system that is wanted, and doing the most logical thing at each step, (except for that one decision about the two possible ways of selecting a bank), we now have a system that overlaps RAS-CAS delay with the MMU. We did not have to do any thinking to achieve this, nor did we have to make bizarr assumptions about what we wanted. Thus, overlaping RAS-CAS delay with the MMU is obvious to one who is skilled in the design of such systems. Q.E.D. jnw@mcnc
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (09/15/86)
In article <79@mtxinu.UUCP>, ed@mtxinu.UUCP writes: > >> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent > >> (applied for and granted) on using the untranslated addresses as the > >> RAS addresses and doing the MMU address translation before the column > >> addresses are needed for CAS. > > > >How the hell can the patent office grant patents like this? It's sort > >of like patenting the idea of grounding DTACK on a 68000 or putting > >chocolate ice cream in root beer; the idea is too obvious. To coin a > >phrase, it's patently ridiculous. > > ... > The person who first put chocolate ice cream into root beer probably > didn't realize what they'd done. They should have patented it, too! > (Unless, of course, someone had already done the same thing with > vanilla ice cream. Then *they* should have pattented it.) Using the untranslated addresses as the RAS addresses and doing the MMU address translation before the column addresses are needed for CAS sounds pretty general to me. I am sure the process Andy Bechtolsheim patented is quite a bit more specific. A patent cannot be granted for a general idea. It requires a specific implementation of an idea, either in a device or process. Think about it. Without that provision patents would stifle development. They are intended to do just the opposite. A patent is supposed to protect the inventor of a process from those who would use his work as their own. But it is not supposed to prevent people from using a concept the inventor has brought to light in their own inventions, so long as they don't plaigiarize from the original work. Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...akgua!akguc!codas!peora!ucf-cs!usfvax2!jc3b21!fgd3
grr@cbmvax.cbm.UUCP (George Robbins) (09/19/86)
In article <462@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >Using the untranslated addresses as the RAS addresses and doing the MMU >address translation before the column addresses are needed for CAS sounds >pretty general to me. I am sure the process Andy Bechtolsheim patented is >quite a bit more specific. A patent cannot be granted for a general idea. >It requires a specific implementation of an idea, either in a device or >process. Think about it. Without that provision patents would stifle >development. They are intended to do just the opposite. A patent is >supposed to protect the inventor of a process from those who would use his >work as their own. But it is not supposed to prevent people from using a >concept the inventor has brought to light in their own inventions, so long >as they don't plaigiarize from the original work. > > Fabbian Dufoe > UUCP: ...akgua!akguc!codas!peora!ucf-cs!usfvax2!jc3b21!fgd3 On the other hand, it is normal for a person filing a patent application to make as broad a claim as he thinks reasonable. The are a number of highly irritating patents covering things like mice, pull down windows, and character generator ROM's. If you read the patent applications, you immediately say 'this guy has got to be kidding', but unfortunatly, they are for real. It is up to a manufacturer to make sure that they do not use ideas that are patented. If Sun chooses to enforce their patent, they could cause a small operation a lot of pain. The patent may not seem reaonable, but it was granted, and until someone invests the neccessary legal time and money to contest it, it is legally enforcable. -- George Robbins - now working for, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
tenney@well.UUCP (Glenn S. Tenney) (09/20/86)
In article <751@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > ... >It is up to a manufacturer to make sure that they do not use ideas that >are patented. If Sun chooses to enforce their patent, they could cause >a small operation a lot of pain. The patent may not seem reaonable, but >it was granted, and until someone invests the neccessary legal time and >money to contest it, it is legally enforcable. I believe that the patent law allows a special challenge that costs only $1500. This is something fairly recent, but I believe anyone can do it with enough proof and then the Patent office takes over. -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!