68000 Memory Managment
Jeff Gortatowsky
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>
Dave Haynie
> 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.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Thomas M. Breuel
|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 Mos
...
>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
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
Jeff Gortatowsky
> 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.
George Robbins
>
>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!g...@seismo.css.GOV
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
Scott Aschenbach
> In article <5...@elmgate.UUCP> j...@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. ...
>
> *can* do multitasking.
>
> --
> Gijs Mos
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 sc...@rsch.wisc.edu
John Bass
> 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 Smith
> ...
> 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
George Robbins
>
>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.
Landon Dyer
> *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 Lee
>> a bus fault on the 68000 makes it difficult to implement paging.
>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
Tom Johnson
>In article <7...@ark.UUCP>, gi...@ark.UUCP (Gijs Mos) writes:
>> In article <5...@elmgate.UUCP> j...@elmgate.UUCP writes:
>> ...
>> >If memory serves me correct the 68000 can not restart/resume a bus faulted
>...
>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
Landon Dyer
> 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....
Chris Lewis
>In article <1...@puff.UUCP> sc...@puff.UUCP (Scott Aschenbach) writes:
>>In article <7...@ark.UUCP>, gi...@ark.UUCP (Gijs Mos) writes:
>>> In article <5...@elmgate.UUCP> j...@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
Douglas H. Price
> 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.
>
> 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 Spencer
> 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 Spencer
> 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.
Jan Steinman
>In article <6...@cbmvax.cbmvax.cbm.UUCP>, g...@cbmvax.cbm.UUCP (George Robbins) writes:
>> A reasonable attitute, but remember that both the Amiga and Atari were
>
>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 ::::::
John Bass
> In article <43...@gatech.CSNET>, je...@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.
Chuck McManis
>
> 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: cmcm...@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
Erik Freed
> 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
Thomas M. Breuel
||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 Black
>In article <6...@mit-prep.ARPA>, t...@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 Su
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.
George Robbins
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...
Jeff Lee
>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.
--
John Gilmore
>> ...contiguous
>>column addresses in a DRAM chip are no longer contiguous in 68K's
>>address space.
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 jgil...@lll-crg.arpa
May the Source be with you!
George Robbins
>
>
>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.
>
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.
Jeff Lee
>>
>> ...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...
lude...@sun.uucp
> > > 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.
>
(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."
rok...@navajo.uucp
> 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 Gould
>> (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.
>
>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."
Chuck M. Sweeney
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 Spencer
> > (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.
>
> ... 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.
Jan Gray
>>> 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
M.A.Gore - ICR
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.
Bob Larson
In article <7...@mtxinu.UUCP> e...@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: Bla...@Usc-Eclb.Arpa or bla...@usc-oberon.arpa
Uucp: (ihnp4,hplabs,tektronix)!sdcrdcf!usc-oberon!blarson
Dave Haynie
>
> 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.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Tomas Rokicki
> >> 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
Jim Wall
The Sun patent is only valid until it holds up in a patent
court. I believe that it can be argued on any of several fronts.
One is that it is obvious using the existing technology of the
times, which is grounds for not granting (or voiding) patents.
THe other would be that it was done and documented prior to the
patent. Personally, I have documentation that it was discussed
here at Fortune five years ago, and I haven't even tried to
look any harder than that. Does anyone know when the patent
disclosure was filed for the Sun MMU patent?
Aw well, I knew I should have filed for those ideas I had,
using PALs to decode address spaces, using ROMs as clocked state
machines, using memory to store information in.....
-Jim Wall
...amd!fortune!wall
ag...@ccvaxa.uucp
...> 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
Gary Oberbrunner
> 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
Reese E. Faucette
>>>> (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.
>>>
>>>the idea is too obvious. [...]
>>
>>If it's so obvious, why didn't anyone think of it before Andy did?
>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 Spencer
> 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.
Jim Omura
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
Peter S. Shenkin
>> 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...
>
>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!pet...@columbia.ARPA
Fabbian G. Dufoe
> >> 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
John Gilmore
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
Chris Lewis
>In article <8000003@ccvaxa> ag...@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
Jan Gray
>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
Hugh LaMaster
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: lama...@ames-pioneer.arpa
Moffett Field, CA 94035 ARPA: lamaster%pio...@ames.arpa
Phone: (415)694-6117 ARPA: lama...@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")
George Robbins
>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
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
Steven E. Rice
> . . .
>>>> 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.
> . . .
> 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.
I'm afraid the "general idea" concept is no bar to a patent! Many years
ago, Western Electric (I think. . .) obtained a patent protecting their
interests in NPN-to-PNP transistor connections! Not too long after both
varieties of transistor were circulating in their lab, someone saw that
the collector of one type could be connected to the base of the other
type (you can't do that with tubes!). Pretty general idea, eh? My
employer paid royalties on this invention until the patent expired.
As another example, there has been a long battle over who first invented
the laser. Recently (the last year or so), a winner was declared and a
number of patents issued. Can you think of a more general idea than the
laser?
Whether or not Andy's invention ultimately proves patentable (because of
details having to do with the dates of the first public announcement and
filing of the patent disclosure, prior art, and so forth), the idea is
quite clearly patentable! Further, if the claims are drawn up broadly
(lawyers are hired for this purpose. . .), the patent should cover any
realization of the idea as used in memory mapping systems. Remember,
though, that the patent could be invalidated merely by proving prior
art! (Does anyone have an example of an equivalent, but earlier,
implementation of this idea? To invalidate the patent, the prior art
would probably have to involve dynamic RAMs. . .)
A patent does not just "protect the inventor of a process from those
who would use his work as their own." The idea is protected in all
realizations that are covered by the claims made in the patent, as long
as there is no reason (such as prior art) that they should be
invalidated. For a period of seventeen years, the inventor is allowed
to control the use of his invention, and charge for the privilege. In
return, he makes the invention public and relinquishes all control of
the invention at the end of the patent's lifetime.
If there were no patents, the only protection people would have is to
keep everything secret (so-called "trade secrets"). This would impede
the flow of information much more than not being able to use an
invention without compensation to the inventor!
Steve Rice
----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
Glenn S. Tenney
> ...
>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!ten...@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 Knight
>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
jo...@ibm.com, jo...@yktvmh.bitnet, ...!philabs!polaris!josh
Mark Campbell
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
Dennis Griesser
>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.
Too late. Apple already got that one. Back in the Apple ][ days.
Bob Welland
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.
Dave Hsu
Interesting. I wonder how they explained the app notes for the 6545
CRTC explaining how it was intended for interleaved access.
-dave
--
David Hsu (301) 454-1433 || -8798 || -8715 "I know no-thing!" -eneevax
Communications & Signal Processing Laboratory / EE Systems Staff
Systems Research Center, Bldg 093 / Engineering Computer Facility
The University of Maryland -~- College Park, MD 20742
ARPA: h...@eneevax.umd.edu UUCP: [seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu
"...because the bowels of the saints are refreshed by thee, brother..."
David Herron, NPR Lover
>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, da...@UKMA.BITNET, da...@ms.uky.csnet
(I'm also "postmaster" at all those addresses)
(And "news" and "netnews" and "uucp" and ....)
Radford Neal
> 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"...
The Kronos operating system for the CDC 6000 also had things similar to
the SUID bit. An system command could have various special "entry points"
that gave them special priviledges even when run by ordinary users. I
first used this system in 1974, but I think it had the feature for many
years before then.
As far as I can see, the only innovation in UNIX SUID stuff is that the
priviledges inherited can be those of any user, not just some "super user",
as determined by file ownership. Personally, I don't this this ought to be
enough to justify a patent.
Radford Neal
The University of Calgary
Jeff Lee
> 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.
I have a copy of the patent in front of me and I'm afraid that it is
quite general. They explain things in term of a general MMU that accepts
the address bus, uses direct address lines and indirect address lines,
a timing generator, and main memory. They then give a specific example
that they are running that uses segmentation and paging on the upper
address lines. They speak specifically about using dynamic rams (actually
any rams that use row and column address strobes), and using the
untranslated address lines before the translated address lines to increase
the breathing room for translation. I'll quote the important section where
he is actually telling what the invention is.
--------------------------- begin quote mode -----------------------------
Disclosure of Invention
An object of the invention is to minimize the delay incurred by a
memory management unit in accessing a computer memory. The above object of
the invention is realized by overlapping the delay time through the memory
management unit with the access of memory. This is achieved by a computer
memory addresses with row and column addresses and a memory management unit
that allows low order addresses to pass directly into the row address of the
computer memory whereas the high-order addresses pass through the memory
management unit and enter the column address of the computer memory.
The system utilizes an address bus extending from a processor to
a memory management means. The address bus splits memory addresses into
pre-defined direct and indirect address segments. The direct address
segments are fed directly to a computer main memory array of the type
having rows and columns of control lines for bit storage elements which
are located at intersections of the control lines. While the direct address
segments are fed to either of the rows or columns of the main memory, the
indirect address segments are fed to a memory management means which
translates the indirect segments to a physical address. The translated
indirect address segments are then fed to the other of the rows or columns
of the main memory array, so that rows and columns of the main memory array
are controlled by the direct address segments on the one hand and the
translated indirect address segments on the other hand. The rows and
columns of the mins array have connected driver circuits for enabling access
to the storage elements. A timing generator is provided for strobing the
row and column driver circuits with sequential pulses. While the direct
address segmentsarrive first at main memory, and are strobed first, the
translated indirect address segments arrive shortly thereafter and are
strobed second, thereby permitting access to storage locations in main
memory. The time between the two strobing pulses is used for indirect
address translation, reducing memory access time.
In addition, the invention minimizes the address translation time
of the memory management unit by using a high-speed static RAM (random-
access-memory) for the translation process and by using the same RAM
address lines both for address input and for accessing the entries of the
memory management means in order to modify the translation.
----------------------------- end quote mode -----------------------------
This also looks, now that I have read it while typing it in, like they
are also patenting using a high speed ram as the memory management
storage device. This is even more general than people probably realized,
but when I was looking into patents, the suggestion was to make it as
general as possible so you could better protect the heart of the process.
Anyway, if anyone would like a copy of the entire patent (6 pages) you
can send $2 to me and I'll mail you back a copy. This won't quite cover
the expense of getting it to you, but it will deter people who aren't
really interested in it that much and keep me from going broke sending
out a hundred of these. I'll pay for the envelope and the return postage.
Just send your mailing address to:
Jeff Lee c/o School of ICS
Georgia Tech
225 North Avenue
Atlanta, GA. 30332
I would suggest that you check your local library or maybe a college library
someplace close. This will save you $2 and a couple of weeks time.
--
Jeff Lee
CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
Phillip Mathews
>>>>> I hate to tell you folks, but Andy Bechtolsheim here at Sun has a patent
>>>>
>>>>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)
Hall
>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
Barry Shein
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.
Ed Gould
>> way to do JACCT"...
>
>The Kronos operating system for the CDC 6000 also had things similar to
>the SUID bit. An system command could have various special "entry points"
>
>As far as I can see, the only innovation in UNIX SUID stuff is that the
>priviledges inherited can be those of any user, not just some "super user",
>as determined by file ownership. Personally, I don't this this ought to be
>enough to justify a patent.
Lots of people have given examples of things that other systems did that
are subsumed by the set-uid bit. The examples vary fairly widely,
but they seem to have a common thread: There have been ways to do
priveliged functions in the past, so what's so new about set-uid?
It seems to me that what's new is the complete generalization of privilege.
In the Kronos example, above, note that a "system command could have...".
This allows the (necessarily) privileged system maintainers to designate
a privileged program. Set-uid allows *any* user to say "during the
execution of this program, which *I* have so designated, you may have
*my* permissions."
Is there a feature elsewhere that allows this?
--
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."
Andrew Tannenbaum
>
> The first time I hears of the SUID I thought "what a nifty general
> way to do JACCT"...
It rubs me the wrong way to see the creators of UNIX being dragged
through the dirt for patenting SUID. You aren't going to see Dennis
Ritchie saying "Oh yea? I did too create the SUID idea." I think SUID
was patented in an attempt to protect the UNIX kernel from theft - you
sell an illicit copy of the kernel, you violate patent law.
No one ever said that UNIX had any original ideas. From the Ritchie
and Thompson "UNIX Timesharing System" paper (July 1974 CACM, July-Aug
1978 UNIX System BSTJ): "The success of UNIX lies not so much in new
inventions but rather in the full exploitation of a carefully selected
set of fertile ideas, and especially in showing that they can be keys
to the implementation of a small yet powerful operating system."
In those days there were no software patents, so SUID was probably
the easiest feature for which it was possible to create an analog in
hardware (which could be patented). It was apparently original enough
to be patented. That doesn't mean it was patented because Dennis
thought it was a brilliant idea. I'm sure that his pride in being
involved in the creation of UNIX doesn't revolve around the SUID
patent.
Andrew Tannenbaum Interactive Boston, MA +1 617 247 1155
Bill Rainey
The SUID patent was filed for on July 9th, 1973.
--
Bill Rainey
Stride Micro
UUCP: cbosgd!utah-cs!utah-gr!stride!bill
ARPA: stride!bi...@utah-gr.arpa
Rex Ballard
No, there is only one way to get a patent in this country -- Hire a *GOOD*
patent attorney. Even if you invent something new, a bad attorney, or
no attorney could cost you the patent. My great-great-grandfather lost
several railroad patents to a bad attorney.
As to being obvious, this does not mean the patent cannot be granted.
The only requirement is that the idea be original.
Paper clips, staples, and other "obvious" devices and processes have
been patented at one time.
David Dyer-Bennet
>
> Would you people all referencing systems which had/have SUID-ish
> features "way back in 1976" note that UNIX and SUID pre-dates 1976*,
>
> 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
Jack Jansen
In article <4...@vaxb.calgary.UUCP> rad...@calgary.UUCP (Radford Neal) writes:
>In article <47...@ukma.uky.csnet>, da...@ukma.uky.csnet (David Herron, NPR Lover) writes:
>
>> hmmmm... I guess the patent office didn't know about JACCT on TOPS-10.
>>
>
>priviledges inherited can be those of any user, not just some "super user",
>as determined by file ownership. Personally, I don't this this ought to be
>enough to justify a patent.
I think the innovation that *anyone* can make a program with special
permissions is an innovation. The methods all the older operating systems
used was always something like giving extra permissions to files living
in a certain directory, or files specified in a certain list, etc.
What this conceptually does is move those programs to a different ring
of security: somewhere in between the kernel and the user. This is totally
different from suid. Also, the features provided by older operating systems
usually gave you a way of completely turning off the protection scheme.
Suid is much cleaner (and safer) in that respect.
--
Jack Jansen, ja...@mcvax.UUCP
The shell is my oyster.
Alan Lehotsky
but that he wasn't sure about its predecessor TENEX. In the interest of architectural
history, I want to set the record straight.
TOPS-10 was one of the first "time-sharing" systems - and dates back to approximately
1966! So, it significantly precedes any version of UNIX (even the PDP-7 proto-UNIX)! I
don't have a date for when .JACCT was invented - and my "TOPS-10 Phonebook" is at home, not
at work - but I think that it was in place by 1969. TENEX was an operating system built
originally by BBN [could be wrong about this] and then adopted by DEC as TOPS-20 and released
in the mid-70's.
The amusing thing about the age of TOPS-10 is that when the file system was originally
designed, they only had about 12 bits to store dates (file-creation, modification, etc.) But
that was okay, because it was stored relative to 1966, which gave them 9 years - and they were
sure that the machine would be obsolete LONG before that! When 1975 roled around you can imagine
the chagrin (and broken programs) when the dates rolled around! (Luckily, they managed to find
another 6 bits)
Jerry Leichter
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
bi...@navajo.uucp
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 Spencer
>
> 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
Henry Spencer
> priviledges inherited can be those of any user, not just some "super user",
> as determined by file ownership. Personally, I don't this this ought to be
> enough to justify a patent.
Why not? It's definitely a useful generalization. And it wasn't trivial
and obvious until Dennis thought of it first.
Barry Shein
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
John Mashey
>It rubs me the wrong way to see the creators of UNIX being dragged
>through the dirt for patenting SUID. You aren't going to see Dennis
>Ritchie saying "Oh yea? I did too create the SUID idea." I think SUID
>was patented in an attempt to protect the UNIX kernel from theft - you
>sell an illicit copy of the kernel, you violate patent law.
Although I have no idea whether or not it was true in this case, it
certainly was true that there were times at BTL (and elsewhere) that
there were big pushes by the internal lawyers to generate patents on
anything conceivable, for good and reaonable reasons. This was standard
practice in the hardware side; whenever software patents were a hot topic,
there was often a strong push to find things that were software patentable,
not necessarily by those who generated the software.
Note: this is no criticism of anybody, including the lawyers who sometimes
tried to push patenting things that software people that were crazy.
This area of the law has been a confusing quagmire for a long, long time.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
sin...@spar.uucp
to let programs they created use any of the privileges (capabilities) they
had, and allowed the programmer to grant the capability to run any program
they created to other people; this did not permit others to get at the
capabilties held by the program. Seems that SUID is a very restricted case
of this. (Alas, I have no date on the invention of the capability system,
but since it is fundamental to the project, the philosophical details almost
certainly come from very early on, and probably pre-date the official
project start).
Henry Spencer
> to let programs they created use any of the privileges (capabilities) they
> had, and allowed the programmer to grant the capability to run any program
> they created to other people; this did not permit others to get at the
> capabilties held by the program. Seems that SUID is a very restricted case
Capability-based systems do indeed considerably pre-date the setuid bit.
They are also vastly more complex than the setuid bit. Seen from this side,
Dennis's innovation was to realize that a very simple facility would give
the most important benefit of such schemes with little of their complexity.