From mint-bounce@lists.fishpool.fi Wed May 19 00:47:06 2010 Message-ID: <4BF36CEE.3080404@online.no> Date: Wed, 19 May 2010 06:45:34 +0200 From: Jo Even Skarstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 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 Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: joska@online.no Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On 05/18/2010 10:47 PM, Miro Kropacek wrote: > just an idea to discuss -- while hacking CT60 TOS I realized we can do > now things which seemed totally impossible in the past like native > FAT16 / FAT32 support, hard disk driver inside and voila -- 32-bit > TOS API which would make possible, among others, also to make FreeMiNT > kernel 32-bit (i.e. able to compile without -mshort). Of course, we > have to keep compatibility for old apps, so new parameter on stack > would be introduced for new apps (in mintlib and freemint) so that > 32-bit API is used. > > I just wanted to know your opinion on this, is it any good, except > good feeling we're 32-bit? :) What would the benefits of a 32 bit API be? As others have pointed out, we've always had 32 bit pointers, so I think the speed improvements would be marginal. I'm not so sure if it's worth the effort. Wouldn't mind embedded FAT32 and harddisk driver though :) Jo Even