From mint-bounce@lists.fishpool.fi Thu Jun 4 10:51:37 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ZH2bRxS++VZCm8nDAhyyAnhrMq4saGfvFrXkvAz5+lI=; b=Rzmm1B+Q8s3Hu8d9pAUAGVnA/BhdexBI2wwU+y75QcXzXDXFDBPCTAlMbHjq2iGEvf dQI+c0bh6xeehJI/6ZSKYb+GviUQRPVsMHDntH2EnVD5bl4wWRs9HODiPW3tblkUGRlZ 8n0DjINVxXtN2c5o0oKNqOipa8HxHlQY9ffmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=SMq4sZd3wq0UzBkGQ5PC9Sb5z5uhZV7dS5AOF6Zat88dbmuTmVgvwJaRTfTWMNmVKU Ph3jwO8zzDQ77GMZjYlJ9fiov5ldmLiRjd34jWNVu0PPleEtSX7lLLdGOctN3s1Zrtd1 9T60qacdHWpKOUk26w+yNNT8G9JWB55IDmjws= Message-Id: <798CA648-5143-446F-9FFB-F4ADC91A2F13@gmail.com> From: Peter Persson To: mint In-Reply-To: <4A27DBE4.8040002@freesbee.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [MiNT] MiNTLib for ColdFire : DONE ! Date: Thu, 4 Jun 2009 16:44:25 +0200 References: <49F743B1.8030803@freesbee.fr> <4A27B367.10107@freesbee.fr> <00F5468A-B8B1-47E4-8185-09C51C2298F8@gmail.com> <4A27D854.6040809@freesbee.fr> <58EAF272-A2E6-46AA-BBE2-886D37A65024@gmail.com> <4A27DBE4.8040002@freesbee.fr> X-Mailer: Apple Mail (2.935.3) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@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 n54EpbmV030118 Hi, 4 jun 2009 kl. 16.36 skrev Vincent Rivière: > Yes, we could do that if someone wants to add compatibility for > ColdFire binaries on 680x0, but I don't think it is a good idea ;-) I don't think it's such a bad idea - but it depends on the code. It's not suitable for time critical stuff, obviously. > > but the MAC >> instructions screw things up.. Didier solved the latter by using an >> unused TRAP instruction. > > Yes, the Line A and MAC instructions share the same opcodes, and it > is untrappable. This is a big problem for the ColdFire OS. ColdFire > programs should just avoir do use Line A, like any modern > applications. I've found that even "clean" apps calls the Line A to retrieve the variable list. It's probably unused though. The point with using the TRAP approach is that it's easy to patch - just replace $A000 in the binary with the corresponding TRAP opcode. It's easy to implement in the OS too. > > Is this something which could be added to the >> kernel as well? It does make it slightly easier to write code for >> both systems, since I woudn't have to check which CPU I'm running on. > > I really don't like the idea of making "compatible binaries", > because it would be suboptimal on any system. Some kind of "fat > binaries" like on MacOS could do the trick, but I really don't want > to see that. Well, we already have separate binaries for 68000/FPU/020+ etc. I don't think having another set of binaries matters. -- PeP