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.
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
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.
blarson@usc-oberon.UUCP (Bob Larson) (09/11/86)
[net.arch added, net.micro.atari16 and net.micro.amega deleted.] 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? [...] >>the idea is too obvious. [...] > >If it's so obvious, why didn't anyone think of it before Andy did? I won't claim to have thought of it before Andy did, but I did think it up independently. (But can't prove it, and didn't try to patent it since I didn't think it was patentable.) The real test of the validity of a patent is in court. (But sometimes the threat of a suit is enough, since even if you win it might cost you more that settling out of court.) Does anybody have proof of having or using this idea before Andy's patent? -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa or blarson@usc-oberon.arpa Uucp: (ihnp4,hplabs,tektronix)!sdcrdcf!usc-oberon!blarson
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!wallaglew@ccvaxa.UUCP (09/12/86)
...> Sun's patent, and response "I did first" from the University of Waterloo Did Andy B. attempt to patent `his' approach in Canada? Andy "the Crazy Canuck" Glew. USEnet: ihnp4!uiucdcs!ccvaxa!aglew Gould CSD 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
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
reese@kim.Berkeley.EDU (Reese E. Faucette) (09/13/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? [...] >>>the idea is too obvious. [...] >> >>If it's so obvious, why didn't anyone think of it before Andy did? >Does anybody have proof of having or using this idea before Andy's >patent? well, when i was a sophomore at caltech in 1981, a guy taking the microprocessor lab with me built a 68000 system with exactly this memory management scheme. i am sure his project proposal is still on file with the professor of that class... -reese
henry@utzoo.UUCP (Henry Spencer) (09/14/86)
> well, when i was a sophomore at caltech in 1981, a guy taking the > microprocessor lab with me built a 68000 system with exactly this > memory management scheme. i am sure his project proposal is still on > file with the professor of that class... If you have to dig into the prof's files to find out about it, it's not an issue for Andy's patent. The intent of the patent system is that you can patent anything that you invent which is neither well-known nor an obvious derivative of something well-known, and has not been patented before. Whether somebody else claims to have invented it too is irrelevant; that becomes relevant only if the other person also applied for a patent (placing priority in doubt) or published the idea (making it well-known). The one respect in which this might actually be significant is as a minor item of contributing evidence to a contention that the technique is "obvious to one skilled in the art", i.e. an obvious derivative of well- known stuff. Multiple independent invention by non-wizards might strengthen such an argument. Warning: the above contains serious oversimplifications. Furthermore, I am not a patent lawyer; consult an expert before doing anything rash. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jimomura@lsuc.UUCP (Jim Omura) (09/14/86)
In article <8000003@ccvaxa> aglew@ccvaxa.UUCP writes: > >...> Sun's patent, and response "I did first" from the University of Waterloo > >Did Andy B. attempt to patent `his' approach in Canada? > >Andy "the Crazy Canuck" Glew. USEnet: ihnp4!uiucdcs!ccvaxa!aglew >Gould CSD 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms This response confuses me. If there was prior knowledge of the method claimed to be "new" in the patent application, and such information was publically obtainable, then the patent was improperly awarded. It doesn't matter whether the first user ever applied for patent protection. What *would* matter is whether the information was secret at the time or published (NOT published in the normal sense, but simply "publically available" in any way). Cheers! -- Jim O. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
peters@cubsvax.UUCP (Peter S. Shenkin) (09/15/86)
In article <utzoo.7123> henry@utzoo.UUCP (Henry Spencer) writes: >> well, when i was a sophomore at caltech in 1981, a guy taking the >> microprocessor lab with me built a 68000 system with exactly this >> memory management scheme. i am sure his project proposal is still on >> file with the professor of that class... > >If you have to dig into the prof's files to find out about it, it's not >an issue for Andy's patent. It's then known as a "trade secret." If you figure out someone else's trade secret, you can patent it. The original purpose of the patent system was to encourage disclosure of new inventions; giving the inventor exclusive rights for a period of time was seen as an inducement to this end. Of course, as Henry points out, if the scheme was published or presented publicly, then it's not patentable, because it has already been disclosed. (...though I believe an inventor can file for a patent up to one year after he's disclosed his invention in public....) Irrelevant to this newsgroup of course; sorry. And no, I'm not a patent attorney either. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
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
gnu@hoptoad.uucp (John Gilmore) (09/15/86)
Andreas Bechtolsheim holds US Patent # 4,527,232 which is on the Sun-2 MMU.
I am pretty sure that the idea of translating virtual addresses while
the row address is being presented to memory, is about as old as DRAMs.
I have never seen a design that hung static RAMs directly in the path
to memory, with no bypass, and with no cacheing or other auto-loading:
they are loaded by software instructions that reference particular
addresses or address spaces. This idea could be original with Andy.
Another unique thing in his design is having two levels of static RAM
to cut down on the size of the RAMs required, while still having a small,
manageable page size.
Not having the patent in front of me, I don't know whether this is what
it claims as proprietary, or something else. Typically the claims sections
are written in as broad a language as possible and then fought out in court
if anybody cares.
I don't know if they filed for patent protection in Canada. I do know that
the patent is NOT owned by Stanford, but by Sun.
I advise MMU designers to get a copy of this patent. Enforcing the patent
would be a dandy way for Sun to put a competitor out of business if it
ever became worth the bother.
John Gilmore, Nebula Consultants
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
May the Source be with you!clewis@spectrix.UUCP (Chris Lewis) (09/15/86)
In article <1335@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >In article <8000003@ccvaxa> aglew@ccvaxa.UUCP writes: >> >>...> Sun's patent, and response "I did first" from the University of Waterloo [BTW: Sun's patent on doing MMU translation during DRAM CAS time] >> >>Did Andy B. attempt to patent `his' approach in Canada? >> >>Andy "the Crazy Canuck" Glew. USEnet: ihnp4!uiucdcs!ccvaxa!aglew >>Gould CSD 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms > > > This response confuses me. If there was prior knowledge of the method >claimed to be "new" in the patent application, and such information was >publically obtainable, then the patent was improperly awarded. It doesn't >matter whether the first user ever applied for patent protection. What *would* >matter is whether the information was secret at the time or published (NOT >published in the normal sense, but simply "publically available" in any way). It wouldn't be the first time that they've done it. While I worked at AES Data, I was informed that Nabu Corp (manufacturer of Teledon terminals) held a patent on the idea of distributing software over the telephone (bye-bye computer networks!) The person who told me was not particularly technical, so it is more likely that the patent is really held on distributing software via cable TV wires - fitting in with Nabu's software distribution service. That sounds like Stargate ... (Actually, I presume that Lauren has already cleared that potential problem). Presumably Canadian patents. Also, about a year ago, one of the original UUCP implementors was trying to find literature about the well known technique of call-back when trying to verify the identity of a telephone caller. You see, someone he knew was being sued for US patent infringement on just that (patent dated 1978 or 9)... He didn't think that the UUCP documentation of call-back (I've seen call-back in UUCP documentation dated in '78) would be sufficiently clear to establish prior knowledge. As it turns out, there's lots of published references to call-back dated prior to 1978 (especially non-computerized), and I shouldn't think that the patent could possibly stand if seriously challenged in court. I like Henry's idea, considering the effectiveness of some of the patent screening, why not patent some idea too simple for somebody to have patented before. Then make money by charging royalties to "infringers" too small to be worth fighting in court. -- Chris Lewis UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis Phone: (416)-474-1955
csc@watmath.UUCP (Jan Gray) (09/17/86)
>I like Henry's idea, considering the effectiveness of some of the patent >screening, why not patent some idea too simple for somebody to have patented >before. Excuse me while I patent the interleaved video and processor access technique that the Macintosh, ST, and Amiga (among others) use...I'll let you know when the licencing agreements are ready. Jan Gray
lamaster@nike.uucp (Hugh LaMaster) (09/17/86)
Does anyone know what the current patent law provides for the time period
of exclusive use? How long after the patent is granted before others can
freely use the patent? Does anyone know when this particular patent was
granted and when it runs out?
Hugh LaMaster, m/s 233-9, UUCP: {seismo,hplabs}!nike!pioneer!lamaster
NASA Ames Research Center ARPA: lamaster@ames-pioneer.arpa
Moffett Field, CA 94035 ARPA: lamaster%pioneer@ames.arpa
Phone: (415)694-6117 ARPA: lamaster@ames.arc.nasa.gov
"The reasonable man adapts himself to the world, the unreasonable man
adapts the world to himself, therefore, all progress depends on the
unreasonable man." -- George Bernard Shaw
("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")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!
josh@polaris.UUCP (Josh Knight) (09/20/86)
In article <610@nike.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: >Does anyone know what the current patent law provides for the time period >of exclusive use? How long after the patent is granted before others can >freely use the patent? Does anyone know when this particular patent was >granted and when it runs out? U.S. patents provide 17 years protection for the holder of the patent. It may very well be different in other countries. As has been pointed out, if you can show "prior art" the patent may not stand up against a challenge. Many computer manufacturers don't use the patents they hold on clever ideas to prevent others from using the ideas; rather they use these patents as bargaining chips when negotiating cross licensing agreements. Essentially all manufacturers of 370 plug compatbile machines have such agreements with IBM; it's only a question of who pays whom how much in addition. A patent came to our attention recently: it looks very much like a "branch history table" but was issued about 15 years AFTER what folks around here consider "the BHT patent". The company that holds the patent almost certainly has a cross license agreement with IBM, so it seems unlikely that any one will ever figure out whether they are really the same or not. Whilst we're asking questions, how old is the SUID bit patent? Anybody know the number? -- Josh Knight, IBM T.J. Watson Research josh@ibm.com, josh@yktvmh.bitnet, ...!philabs!polaris!josh
campbell@sauron.UUCP (Mark Campbell) (09/22/86)
Ritchie's SUID parent is numbered 4,135,240 and was dated January 16, 1979. Protection of data file contents. Abstract: An improved arrangment for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents. An additional access control bit is added to each executable file. When this bit is set to one, the identification of the current user is changed to that of the owner of the executable file. THe program in the executable file then has access to all data files woned by the same owner. This change is temporary, the proper identification being restored when the program is terminated. -- Mark Campbell Phone: (803)-791-6697 E-Mail: !ncsu!ncrcae!sauron!campbell
welland@cbmvax.cbm.UUCP (Bob Welland) (09/24/86)
The Zilog Z8000 MMU (Z8010) does not use the lower 8 address bits in its translation process. Most of the Zilog documents show the low order address bits going around the MMU and into "Memory Control". It seems obvious to me that any self respecting hardware designer would assert RAS as soon as possible in there "Memory Controller" (There is no horrible maximum RAS to CAS time). As I understand it, this is the part of the Sun patent that gets everyone upset. Is there someone out there with a Zilog application note that shows DRAMs explicitly ? I only have 1983 manuals but I know the Z8000 is from around 1978 ... Robert Welland Toy Engineer (I am told) Whatever I should disclaim I do here and now with the disclaim - r.
david@ukma.uky.csnet (David Herron, NPR Lover) (09/27/86)
In article <727@sauron.UUCP> campbell@sauron.UUCP (Mark Campbell) writes: >Ritchie's SUID parent is numbered 4,135,240 and was dated January 16, 1979. > >Protection of data file contents. hmmmm... I guess the patent office didn't know about JACCT on TOPS-10. The first time I hears of the SUID I thought "what a nifty general way to do JACCT". Is there a difference? [For those of you who aren't old DEC-10 hackers... JACCT means "Job Always Control-C Trapped". That was apparently an EXTREMELY old feature of it. Anyway, it was a bit which would be set in the user's priveledges (actually it was off in another word of the user data structure...) when the user executed a special program (anything executed from a [1,*] directory whose name was mentioned on a list which was compiled in the kernal (PRVTAB)). The bit gave the user equivalent to [1,2] priveledges (i.e. anything the user wanted to do). The reason the Job was Always Control-C Trapped was was for old versions where a user could run a jacct program, control-c, then ddt it and be able to do anything he wanted... Control-C trapping stopped the user from doing that, so the user can now only do what the jacct'd program wanted to do.] Now, using this facility one can 'emulate' the SUID facility to an extent. You run the program, you instantly have full access to all files, you can also change user-id easily, etc. So you do so. Then when you're done the program changes back and exits. (dropping the jacct status, etc...) It's of course trivial to emulate the jacct facility on suid. As I see it suid is merely a refinement of jacct... not a new thing. Have I missed something? (BTW, jacct is a very old facility... I first ran into it in 1977 when I first got on a tops-10 machine... I'm not sure how long beforehand it was in tops-10) -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet (I'm also "postmaster" at all those addresses) (And "news" and "netnews" and "uucp" and ....)
philm@galbp.UUCP (Phillip Mathews) (09/30/86)
In article <> reese@kim.Berkeley.EDU.UUCP (Reese E. Faucette) 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? [...] >>>>the idea is too obvious. [...] There are two ways to get a patent in this country--invent something new or hire a *GOOD* patent attorney--c.f patent #4488662 on which i am listed as co-inventor. This patent is for a 7474 used to de-glitch the wait/ready line of a Z80SIO. Pure b***s*** invented by the patent attorney (the de-glitching was mine--tthe b***s*** is the patent attorney's)
marcus@ihlpl.UUCP (Hall) (09/30/86)
In article <727@sauron.UUCP> campbell@sauron.UUCP (Mark Campbell) writes: >Ritchie's SUID parent is numbered 4,135,240 and was dated January 16, 1979. I remember that the HP2000 system that we used at my high school allowed a file to be put into a state known as "LOCKED". This allowed the program to access data files that were also in a "LOCKED" state and owned by me. This appears to be essentially the same idea as the SUID bit, and it was running in 1976. I guess that since it didn't really change your id to be the program owner but was a special case in access of files (i.e. such programs could not create new files owned by the program's owner, etc.) it isn't quite the same, but the action certainly is awfully close. Marcus Hall ..!ihnp4!ihlpl!marcus
bzs@bu-cs.BU.EDU (Barry Shein) (10/02/86)
Would you people all referencing systems which had/have SUID-ish features "way back in 1976" note that UNIX and SUID pre-dates 1976*, I am not sure exactly when it was introduced but very early 70's is a good guess (the patent may have been dated 1979 but that's the date the patent was granted, not the date all prior claims starts at.) For example, someone mentioned a similar feature in TOPS-10, UNIX completely predates TOPS-10 as far as I know tho not it's predecessor TENEX, the person didn't mention whether this feature was in TENEX. Just because TOPS-10 got old and died doesn't mean its older than UNIX. Having had experience with some of these other similar schemes I would say they would be very weak prior claims in that they mostly stunk. It's like saying round tires shouldn't be patented cause someone had come up with a square tire earlier...Be careful, it's the precise description of the thing, not "a patent on a way to access a priv'd file" which is what these arguments seem to be reducing it to to make their point. There is also an attitude problem here. Yes, a patent does indeed give certain rights to the patent holder. It also gives certain rights to the patent non-holder. A major reason for patents is to encourage inventors to publish the details of their invention, with protection, so the general public may benefit. It also puts some limits on those protections (time limit, must be utilized etc.) You people speak like it's some sort of con-job of no benefit to the industry in general, that's patently untrue :-) -Barry Shein, Boston University * I used UNIX with SUID around 1976-7, V6.
bill@stride.UUCP (Bill Rainey) (10/02/86)
The SUID patent was filed for on July 9th, 1973. -- Bill Rainey Stride Micro UUCP: cbosgd!utah-cs!utah-gr!stride!bill ARPA: stride!bill@utah-gr.arpa
ddb@starfire.UUCP (David Dyer-Bennet) (10/03/86)
In article <1611@bu-cs.bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > Would you people all referencing systems which had/have SUID-ish > features "way back in 1976" note that UNIX and SUID pre-dates 1976*, > > For example, someone mentioned a similar feature in TOPS-10, UNIX > completely predates TOPS-10 as far as I know tho not it's predecessor > TENEX, the person didn't mention whether this feature was in TENEX. > Just because TOPS-10 got old and died doesn't mean its older than UNIX. TENEX was derived from tops-10, not the other way around. Tops-20 was derived from Tenex. Unix was developed partly because they couldn't get Bell to buy them a pdp-10 to play with (read the standard early unix history article), so I believe that tops-10 predates unix significantly. -- David Dyer-Bennet, former DEC LCG employee -- David Dyer-Bennet Usenet: ...ihnp4!umn-cs!starfire!ddb Fido: sysop of fido 14/341, (612) 721-8967 Telephone: (612) 721-8800 USmail: 4242 Minnehaha Ave S Mpls, MN 55406
leichter@yale.UUCP (Jerry Leichter) (10/03/86)
Bsrry Shein writes about TOPS-10 as "a descendent of TENEX" and perhaps not as old as Unix. This has the history quite confused. I used TOPS-10 in 1969 or so; at the time it was already at Version 5 or thereabouts. JACCT was already there; I don't know exactly when it was introduced. TOPS-10 itself descended from earlier OS's for the PDP-15 (?), which, for all I know, already had JACCT or some analogue. TENEX was considerably later, and while not a direct descendent of TOPS-10 had some similarities. It was TOPS-20 that descended from TENEX. None of this has anything to do with the patentability of SUID. Clearly, the original idea in SUID is NOT that some programs can be privileged - in one form or another, that's been present in every OS with any idea of protection - but that "privilege" is not a unique things belonging only to the OS, but something any user has, in some sense, and can share. Years ago, an article appeared - in Software Practice and Experience, I believe - which described a game of some sort, with a master list of high scores. A challenge was given: Maintain such a master list, given the constraints that (a) anyone who runs the game program can have their score recorded; (b) no one can spoof the records by accessing the master list directly; (c) any user, without special privileges, can create a new master list for his version of the game. These constraints are easy to satisfy on Unix with a SUID program. To this day, they are quite difficult to satisfy on most other systems. (Often, they simply CANNOT be satisfied.) -- Jerry
billw@navajo.UUCP (10/04/86)
Actually TOPS10 is close to 20 years old, making it consdierably older than UNIX. TENEX was the predecessor to TOPS20, both of which come after TOPS10. The first version of TOPS20 was in 1976 or 77, and it doesn't have anything like SUID (nor does TENEX). BillW, a TOPS20 and TOPS10 systems programmer. Still.
henry@utzoo.UUCP (Henry Spencer) (10/04/86)
> hmmmm... I guess the patent office didn't know about JACCT on TOPS-10... > > The first time I hears of the SUID I thought "what a nifty general > way to do JACCT". Is there a difference? The generalization is precisely the invention that justifies the patent. Any number of systems had magic bits saying "run this as root". Dennis was the first one to notice that the facility could be made much more versatile -- among other things, it could safely be made available to the ordinary users -- if it meant "run this as the owner of the file" instead. This means one can have protected subsystems without each and every one needing to be trusted with (transient) superuser privileges. The generalization looks obvious and trivial only after you've been told about it and gotten used to the idea. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
bzs@bu-cs.BU.EDU (Barry Shein) (10/04/86)
Mea Culpa, I confused TOPS-20's descendancy from TENEX with TOPS-10's. Sorry for the error. The point still stands that the people I was responding to who are mentioning SUID-ish features they have seen in the mid-late 70's and propose that these pre-date UNIX's SUID patent of 1979 have their history backwards. That was my only point, sorry about getting the PDP-10 O/S's TOPSy-turvy, as is typical with these things I believe you can delete that claim from my note and the rest of the note still stands on its own two feet. -Barry Shein, Boston University
rentsch@unc.UUCP (Tim Rentsch) (10/11/86)
Just a note in the interest of historical accuracy. The JACCT bit on PDP-10's has been around a long long time. I first used a PDP-10 in 1970, and the JACCT bit was in the operating system then. (btw, JACCT is mnemonic for Job ACCounTing bit, since originally the only program which ran with JACCT was the login/logout programs.) I believe JACCT existed ever since the days of the PDP-6 (1968? 1966? anyone know?), and it had the same function, BUT it did not then trap control-C's -- they instead were translated to escapes! [For those of you out there in netland to know the pleasure of running your own jacct'ed programs -- cheers. today's hackers never had it so good.]