[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] Winograd DCT on my seul.org account
- To: f-cpu@seul.org
- Subject: Re: [f-cpu] Winograd DCT on my seul.org account
- From: djrom <pash.cracken@free.fr>
- Date: Fri, 19 Apr 2002 09:09:49 +0200
- Delivered-To: archiver@seul.org
- Delivered-To: f-cpu-outgoing@seul.org
- Delivered-To: f-cpu@seul.org
- Delivery-Date: Fri, 19 Apr 2002 03:10:10 -0400
- Reply-To: f-cpu@seul.org
- Sender: owner-f-cpu@seul.org
this is a very interesting paper. but what haven't you written the code in assembler ? the C code looks like assembler in any way, so ... :-)
it cause the problem of gcc to (re)raise. optimisations for FC0 are very different from usual optimisations, even for RISC processors. I don't know the real structure of gcc, but I guess it'll be very difficult to put FC0 tricks without breaking the portability, no ? I even wonder if rewriting a new compiler won't be much easier than trying to add such things in gcc, if we want the compiler to be good. we don't want to see the F-Cpu ends like the PIV, used at less than 30%, right ?
moreover, we should perhaps think about another langage to be used on modern processors. C is very limited in his expressivity, so the operations like SIMD or "real" optimisations put a ton of work on the compiler's shoulders. it shouldn't just try to optimise, but it must even try to *understand* what the programmers meant. is there a langage really usable for modern RISC processors ? maybe we should try to return to lisp or ML, or something like that, no ? that's could also be a way to promote new langages: I don't want 2030's processors to be always coded in C ! :-)
if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-)
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/