From mint-bounce@lists.fishpool.fi Tue May 18 17:03:47 2010 Message-ID: <4BF30050.90802@freesbee.fr> Date: Tue, 18 May 2010 23:02:08 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] 32-bit FreeMiNT kernel References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o4IL3kgh011938 Miro Kropacek wrote: > I just wanted to know your opinion on this, is it any good, except > good feeling we're 32-bit? :) 32-bit will be slower on ST (but who cares ?), 16-bit is slower on ColdFire. Anyway, unlike x86, we always have 32-bit pointers, that's the most important. I think your 16/32-bit reflexion is just about increasing the size of the parameters of some API functions, where it matters. This could probably easily implemented as additional function calls, without breaking the existing compatibility. -- Vincent Rivière