Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Lonny Pursell <atari@bright.net>]

on 12/9/09 7:37 AM, Peter Persson wrote:

>>> 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?

I have to agree with Jo and Peter.  Having spent the time to learn assembler
over the past 2 years, I have to say its far easier to read "C".  The only
reason I bothered to do that is because I wanted to salvage GFA, and clean
it up, but the entire suite is written in assembler. Unfortunately.

Since the ACP project appeared I'm now faced with the huge task of trying to
get GFA which is 100% assembler to run native on the coldfire.  This is a
huge task, possibly I can't even do it, because the complexity of the
compiler is quite something.  Now, if it was written in "C" I'd probably
have a native version of GFA up and running already with some minor tweaks.
;-P

So to me, the maintaining part far out weighs the asm benefits, since the
asm code itself locks the source into a specific cpu.  Not to mention with a
newer faster machine, its not worth it in my opinion to add more assembler.
The goal really should be to get rid of it at certain levels.  One should
view the "C" compiler as an abstraction layer and let it do the work.

You know ozk used be a 100% total asm coder, everything he did was asm,
hence the name on his web page asm soft.  Then one day he saw the light and
switched to "C" much to my surprise. I have to say, I'm glad he did.


-- 
Lonny Pursell    http://www.bright.net/~gfabasic/