From mint-bounce@lists.fishpool.fi Mon May 4 07:56:10 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tO+pMtMlhXkwcSJ1dejKDLds1P3ye3jI8Vk31dQv540=; b=djvzi7RENiaEwPP4hXWzMt9AAF5zmUwiXMRECqQDuvgbD2ViD0fEsx3Fvqnp3r54I1 zijMCuRX133NalbOgaXAa/KViZGqJFpBpSlBWxDPmdtMvj34wJel4p0EXsBChTVORmap 4GeoAXTNCaU6UvIZUTNjT1yFWxEfuuQD7ExEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ji7cfQpcmrrQ3q47MgGUcTuXha+A2UJkprD3YsHsuU5l3gOU3xeuQjEMQ6f9kt72e1 gMDFtWH24wkcU0siEJc6zkggVvCP171aU+zBQC1+3oTDp6mItjpipY2bvJdzokPgU4NV VmcKoYbhLFNOs3q5yL9z+Ljr/NcYyAIn4Z4HE= Message-ID: <49FED6A5.6010802@freesbee.fr> Date: Mon, 04 May 2009 13:51:01 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] EmuTOS for ColdFire References: <49FE9448.8020606@freesbee.fr> <1241422433.8225.27.camel@petr> In-Reply-To: <1241422433.8225.27.camel@petr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hello, Petr. Be sure I understand your fears. I can't say you are fully wrong. However... > I don't agree. It doesn't make any sense for me to rewrite each given > source twice - first to port from m68k to CF and then from CF to > anything else. The CF step is unnecessary, IMHO. Nobody is going to rewrite each source twice. Because of the similarities between 680x0 and ColdFire, the changes for ColdFire in assembler files are very small and easy. It is the case for the MiNTLib and EmuTOS (except VDI). The required changes are only things like replacing addq.w by addq.l inside #ifdef blocks. > There is no m68k > cleaning that could be reused for a completely different CPU, I believe > (unless this is done the way Martin worked on EmuTOS - he was rewriting > every assembler source he could to plain C to achieve true portability - > but we cannot afford that on 8 MHz machines - the assembler is used > there for a good reason). Only one VDI source in EmuTOS is too complicated to be modified for ColdFire. That code will have to be rewritten in C for portability. Such rewrite will be reusable as-is for totally different processors. The current assembler code optimized for 68000 can be kept for 68000 targets, there will be no performance loss. Moreover, nowadays GCC produces very efficient code. I'm very curious to see the speed differences between the C VDI and the assembler one on 68000. > If I still were an active Atari developer I would > soon become bored by generating several different binaries (for m68k, > for CF, and for anything else that might appear) especially when I > wouldn't have a chance to test them out properly (I don't plan on buying > CF). That's why I work on toolchains. I want that clean sources can be built easily and automatically for any architecture (Debian is a good example). There is a lot if stuff already existing in GNU tools (especially in Automake), we just have to use it. Testing binaries is another problem. > Please note that I am not in any way against ACP or any other hobby/fun > project someone might come up with. I just can't agree with the logic > that is presented here in some mails. I think things work differently in > real world (and I am talking from my own experience when I release the > multi-platform software I happen to develop). Hardware lovers will build a new Atari-like computer based on ColdFire. That will happen, because they want to see such a thing, and it is their hobby. Their primary goal is to have new hardware features, and the ability to run most TT/Hades binaries. However, as you underlined it, and despite the efforts of the developers, I'm sure there will be some incompatibilities, and speed issues. I don't like hardware myself, I'm very happy with my brand-new PC, I use ARAnyM and Steem occasionally for testing the output of the compilers. I use my STe only for reading old floppies, until someone provides an universal USB floppy reader. But the ACP project is cool, that's why I'm going to buy a board. Then when I have the hardware, I will not be satisfied by half-speed 68000 emulation. One of my hobbies is about toolchains for generating fully optimized binaries for any CPU. So I want a compiler (and libraries, OS...) for running native ColdFire software. I will do it because it is my own hobby. If it is seen as a good thing, ColdFire support will be added to official sources. If it is not, I will publish my own patches and binaries. No problem. -- Vincent Rivière