Re: [f-cpu] Winograd DCT on my seul.org account

[cedric <cedric.bail@free.fr>]

> > 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 ?
>
> I guess that writing a new C compiler will indeed be easier than
> hacking gcc.

Euh, well,... I didn't agry with you, writing a C compiler is very hard (It 
actually didn't exist any bison grammar for C). And a lot of thing in the 
C/C++ norme are not clear specified (It's explain the problem with the 3.0.x 
version of gcc). So when you want to write your own C compiler, you must test 
it with a lot of different software and... have a lot of problem.

And I recently read the gcc documentation about how to write a backend to gcc 
and it's not easy, but we can have some possibility and we could have some 
good performance. The only problem is with SIMD and perhaps some optimisation 
with our cray like load/store.
	I thing that nicolas that says to me that for the 3.1 release they will have 
some SIMD optimisation. With our clean ASM, it will certainly be possible to 
use it.
	Last point, if we write one backend, we can have all the gcc frontend 
working on our CPU, and that much more interesting.
	That's only my point of view, and for me coding a C/C++ compiler will 
be a nightmare... 


A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/