From mint-bounce@lists.fishpool.fi Fri Jan 8 14:37:21 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Lprqqv1oBj5mwrG1TdC2ZA+4E847C/VNraFWw88QeSM=; b=v/XVo15xy2J0bE5AO77AomD9UbQ12oYlrApaUhAUkrJXmoCQXLIMipAFSYepU3U1yq maIU2hbNLuGg6c6ZPRlXbu9ThEJfY7lo/9beT8sLD4BNiES4rtnwXynq1/01kAA60AOc OcHXzF+tyMPyCcZUFNrZKLjmnuR+q+iS0Ynx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Vaac0OTTigAEcighZ4KBWY392W4KCx81r/tCRZXG7yIBjF47irU99CqhNHLuzNBimM ZkkDxA96yCXygWxU3SirqC5SBjOZ4LxWarT25rxuGtKn6GSZLbHnrPHM+3G0mdvXz6uX iiIvk+5ZeryM2XNVQZDoL+8mq7IWXpQVqQG3U= MIME-Version: 1.0 In-Reply-To: <4B477EC1.5020804@freesbee.fr> References: <4B3F0163.6090409@atari-source.org> <4B3F44DC.8040304@freesbee.fr> <11a6f2b11001081017x111818f9v544f5721e6f97817@mail.gmail.com> <4B477EC1.5020804@freesbee.fr> Date: Fri, 8 Jan 2010 13:35:51 -0600 Message-ID: <11a6f2b11001081135k4f279dd9n60cdc97166771c5@mail.gmail.com> Subject: Re: [MiNT] Sparemint Coldfire From: Paul Wratt To: mint Content-Type: text/plain; charset=ISO-8859-1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: paul.wratt@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o08JbLKL022493 2010/1/8 Vincent Rivière : > Paul Wratt wrote: >> >> this looks like a good way to go, presuming that v4e does not need any >> patches applied to source, or is that the point of the previous >> comments, that it still needs minimal patching (compared to other 68k >> variant output). >> >> BTW: why is there still a need to patch is the source is C/C++, wasn't >> that the point of another discussion re: ASM. I do however understand >> the need to patch for GCC 4.x "strictness" due to the age of >> sources... > > Here are the facts. > > 1) Older sources have *sometimes* to be patched for GCC 4.x "strictness". > There are usually no GCC problem with up-to-date open-source programs. > Sometimes the makefiles have to be revised a bit, too. > > 2) A C program that compiles well with GCC 4.x for 68000 will compile > equally well for ColdFire. You just have to have the required libraries for > ColdFire, and add the option -mcpu=5475 to the gcc command line. It worked > flawlessly with all the few packages I have compiled an run on ColdFire. > > 3) Software fully or partially written in assembly will require manual > patching to be 100% ColdFire. It is usually quite simple for user programs > (as I did in the MiNTLib), but it is sometimes a bit tricky in OS software > (as I did for EmuTOS). > > Most Linux open-source software are written in C only, there will be no > problem to get them work fully optimized on ColdFire. > > Due to speed issues, traditional Atari software have often some parts > written in assembly, if not all. They will require some more or less easy > patching to be 100 ColdFire optimized. However it is not a big issue, since > the the Atari ColdFire OS will embed a lightweight 68000 emulation. Thanks > to the speed of the ColdFire, there will be no performance issue. > > So the big problem is not rebuilding the whole SpareMiNT archive for > ColdFire, it is rebuilding it with GCC 4.x. > If we fix each package one after each other, there will be no problem. And > if they are committed. > > -- > Vincent Rivière > ta, thanks, more good general knowledge, hell I'll be able to write a compact gcc 5 at this rate :) on the ASM thing, I have a package I was going to port to help solve the problem of cross architecture, High Level Assembler, to help in getting mint to be used as a proto-typing platform however if this gcc speed and size thing continues on its current trend not even a clean boot AFROS LiveCD will provide fast enough native compilation. However I had not excluded placing cross-compilers with the next AFROS-update and was going to with any FuDE for AFROS anyway, so some of these other options, like Eeros SB v1 & v2 post will now be part of that, to provide more options, but documented, and already setup in extractable form. BTW, any patches done on RPM builds, they can work with changes for Gentoo right? (I used a Gentoo patch to get Zoo to compile on my Mandriva based distro) Paul