From mint-bounce@lists.fishpool.fi Wed Dec 9 03:57:16 2009 Message-ID: <7116AF0ECE9F4F099B489E49FEE856FC@mercatus.local> From: "Jo Even Skarstein" To: "mint" References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <11a6f2b10911281336q6ad74b7au657ac40469b28d8@mail.gmail.com> <11a6f2b10912081349x51b88c71p278c085ff9b77f2e@mail.gmail.com> <11a6f2b10912082333g5ede94a6t862ff00a111c970a@mail.gmail.com> In-Reply-To: <11a6f2b10912082333g5ede94a6t862ff00a111c970a@mail.gmail.com> Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 Date: Wed, 9 Dec 2009 09:54:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-EsetScannerBuild: 6181 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: -------------------------------------------------- From: "Paul Wratt" Sent: Wednesday, December 09, 2009 8:33 AM To: "mint" Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 > For anyone else who is reading this, and has not read my latest post > in ARAnyM list (or related ACP list posts), I am proposing the same > additions of ASM to XaAES (along with full AES implementaions) to be I think this is a very, very bad idea. The goal should be to get rid of assembler, not add more. I can't see how the future development of the AES can benefit from obfuscated assembly code which ties it to a single CPU. I programmed a lot of 68k and 6502-assembler in the 80's and early 90's, and I don't intend to do that again. I can see the benefit in assembler if you try to optimize a line-drawing routine - but there are no such things in the AES. The AES is separate from the hardware, and thus should contain no hardware-specific code. And assembler is 100% hardware specific. It belongs in device drivers and nowhere else. When it comes to performance, well designed (and implemented!) algorithms in C are hard to beat. For such a big project, the compiler will for sure optimize the code better than yourself. I think the effort should be put into bug-fixing, then adding more features (add some missing 4.1-features, MagiC-style scrollable editfields and the edit-object) and finally work on the visuals. First make it more stable, then more feature-rich and finally make it look better :-) And do it all in C so the work can be continued when you loose interest or for other reasons have to drop this project. > This XaAES v2 development should coincide with revisions of AES and > VDI and related functions (like XBIOS if needed), eg. AES v5, > revisions that can "last to the end of this millenium" as it were Having the VDI as a kernel module so the AES can call it directly will be a huge benefit performance-wise. Jo Even __________ Information from ESET NOD32 Antivirus, version of virus signature database 4671 (20091208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com