From fnaumann@mail.cs.uni-magdeburg.de Thu Mar 18 17:39:36 2004 Subject: Re: [MiNT] Shared libs without MMU resources From: Petr Stehlik To: mint@lists.fishpool.fi In-Reply-To: <405868D5.4060101@imperia.net> References: <405868D5.4060101@imperia.net> Content-Type: text/plain Message-Id: <1079627332.24920.37.camel@joy.sophics> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 18 Mar 2004 17:28:52 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at sophics.cz Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: joy@sophics.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: On Wed, 2004-03-17 at 16:03, Guido Flohr wrote: > (virtual) address of "errno" is mapped by the MMU to a real address > Drawback: Old MiNT hardware (mc68000) does not have a MMU but it does > have a strong lobby here. ;-) does the mc68000 have a lobby, really? I am wondering what the smile should stand for there. I don't believe that there are more than 5% of nonMMU users in the FreeMiNT camp. The ST machines are 20 years old now (the CPU is even older). Where are we - in museum? Honestly - there is no real development, no given direction, no goals, no timeframe, no leaders, no discussion, nothing. Judging from this list the MiNT and its community is already dead. If there was a direction and goal, it would probably say that mc68000 is unsupported by FreeMiNT 2.0 which is to contain the following features and is to be released at xx.yy.2001 (or slightly later). That would make it clear if to go for the shared libs and how to get there. > Furthermore, several Atari idiosyncrasies, > like the variable length block of system variables, cookie jars, closed > source tsr programs, ill-designed ipc protocols, etc. will make the > whole thing very hard to implement when you still want to be able to run > legacy software. There has been a strong pressure from the MiNT guys to either fix or abandon these ill-designed things for a couple of years already. If they succeeded yet or no, I don't know. We should make a poll with the questions: 1) are you able to run your favourite software with MMU enabled? 2) do you run with MMU enabled all the time? > 2) We modify our compiler system: > Yet, somebody with a profund knowledge of gcc internals would probably > be able to code that feature into the compiler and convince the gcc > maintainers to accept the patch. I don't think we'd have to convince the gcc maintainers since Frank believes we should stay with GCC 2.95.x forever. Petr