Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!mintaka!mit-eddie!rutgers!bpa!cbmvax!valentin From: valentin@cbmvax.commodore.com (Valentin Pepelea) Newsgroups: comp.sys.amiga Subject: Re: Message-ID: <9827@cbmvax.commodore.com> Date: 26 Feb 90 19:51:22 GMT References: <184.25e933aa@waikato.ac.nz> Reply-To: valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) Followup-To: comp.sys.amiga.tech Organization: Commodore, West Chester, PA Lines: 28 In article <184.25e933aa@waikato.ac.nz> hamish@waikato.ac.nz writes: > >How about memory protection (On 020 & 030) for memory that isn't declared as >MEMF_PUBLIC. This would mean an end to trashing other programs code & >libraries, as well as the system& user stack for tasks & processes. I saw >mention somewhere in the past that mem protection wouldn't work because >MEMF_PUBLIC is supposed to be just that public. Exactly. There is no point providing memory protection at all, if one part of memory cannot be protected. As long as public memory is free to be stomped by anybody, a crash is still unrecoverable. >PS. Could somebody tell me where the 68881/882 is supposed to be decoded in > the 68000/010 address space. It depends on the hardware, i.e. how you attached the 68881 to the 68010. (not 68000) The IEEE math libraries get only a 50% with a 68881 attached to a 68010, compared to a bare 68000. The slowness comes from the fact that the coprocessor interface has to be made in software on the 68010. If you want speed imprevement, you defenitely have to take advantage of the 68020's microcoded coprocessor interface. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be