From mint-bounce@lists.fishpool.fi Wed Dec 9 07:41:20 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=LHJhYG9CoLSp11z7lM7HqefCnfRS1ACAsMQ0EsMLrJA=; b=pizaYhqQgQ8TDJAEFaf2f2OvCvx3TEhrPgsqFjRqPUaZGu7jwucjW45XxpriNjYO9X ao4liAx1dYz9NEiqJAR6xBp4FfJ3EgRbag1XG4+1I0+fdn3kBIj10fyT84WIOb/zvOTO dkumwnCFw3n7mrbPTo0NsEgpLjyxw49z9g/jI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=oFyCV5zf+tTZaiXutgImf+UL34fJXYgxJUDx2zjknsrPUwvu81Uz0GNJ6eVJfTqMY9 cQZrXTmVxzKaeCXptlXWkq1Pg20pd9KTlEvEomvMFTIIPaEYfADJGHofwsjuquLzKpbz q0pDMcorCYqwj3+3fG0GpzhvIGegSPQ04yZlo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 From: Peter Persson In-Reply-To: <11a6f2b10912090408t4d8c9874h12fa44026a463178@mail.gmail.com> Date: Wed, 9 Dec 2009 13:37:50 +0100 Message-Id: <30A076C3-963C-4AE6-8618-20975ED57DBA@gmail.com> References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <11a6f2b10912081349x51b88c71p278c085ff9b77f2e@mail.gmail.com> <11a6f2b10912082333g5ede94a6t862ff00a111c970a@mail.gmail.com> <7116AF0ECE9F4F099B489E49FEE856FC@mercatus.local> <11a6f2b10912090408t4d8c9874h12fa44026a463178@mail.gmail.com> To: mint X-Mailer: Apple Mail (2.1077) 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 nB9CfKgI009915 >> 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. >> > no body is asking you to, and once they are set, there should be no > need to modify them. Of they become that outdated, they can (again) be > replace by C functions I tend to agree with Jo here. Maintainability is extremely important. Assembler should be used where it makes a difference, not in a higher level OS layer such as the AES. And I'm not saying this because I have some special affection towards higher level languages, because I don't. But we're not talking about texture mapping routines with tight inner loops here. > The people on this planet who can write "algorithms in C that are hard > to beat", usually have an excessive understanding of ASM (or how ASM > is written in binary for, and executed at run time), and are as common > as "hens teeth". This is not to say "none of those people are with > earshot of this thread", but as you your self know writing good clean > fast, or better still exceedingly fast, algorithms is actually quite > complex, and may require much code rewrite, and tests for all > situations. No, this is just common sense. The best way to optimize something - regardless of language - is to find a better algorithm. I usually check the output of GCC to see if I could have a better job myself, and I often discover that while I might have been able to beat it by a few instructions, it doesn't make any difference whatsoever in practice. > The fundamental flaw in your vision (and many others peoples who blow > "only high level languages" trumpets), is that C is compiled into hex > byte codes, when these are "read in an english/language style" they > are called assembly instructions (as seen in any debugger - assembly > numonics). What exactly is your point here? -- PeP