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

[Yann Guidon <whygee@f-cpu.org>]

hi !

djrom wrote:
> 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 ... :-)
you answered the question :-) i also spoke a bit about this in one place.

> 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 ?
it is well-known that compiled code has at least 30% overhead. then the user
comes in and inputs "portable" code and you loose another factor.
Then you don't use the advanced features like SIMD and you loose yet another
factor. Finally, if the compiler doesn't "understand" how to write efficient
code (for example, jump and data prefetch !) then you have a running time
that is at least this of other CPUs.
But the compiler must be at least as smart as the processor, though this is
not granted yet.

> 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 ?
If you except FORTRAN (F95 and later are pretty good), C is used everywhere
performance is at stake. And assembly langage, too.

> maybe we should try to return to lisp or ML, or something like that, no ?
mais après vous, mon cher ;-)

> that's could also be a way to promote new langages: I don't want
> 2030's processors to be always coded in C ! :-)
neither do i but i don't have much power.
A VHDL derivative would be way tooooooooo cool (funny, from ADA to VHDL
and back to software :-D) but i can't do everything ...
IIRC ADA was ported to the GNU framework so we could reuse the frontend
and use another backend. Adding VHDL semantics could make programming
become a completely different experience.

> if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-)
i can't even count on myself.

--------------------------------------------------------------------
However i had an idea during a private discussion with Cedric...
He probably won't like that i speak again about it, but i like
this idea because it is a good compromise : efficient and realistic.

The idea is to use GCC and give a very simplistic machine description.
So we won't have to mess with GCC's internals and problems.
GCC will output assembly langage for our simplistic machine
(63 registers + 0, post-incrememnted-only addressing, direct register jump etc.)
but all the "dirty optimisation work" will be done before assembly.
The GCC code would be translated to real instructions and some global analysis
will be done, for example for computing optimal pointer increments and prefetching
the jump destinations well in advance... so GCC won't care and F-CPU specific stuff
will be kept separate.

This is the easiest solution which allows everybody to use most existing sources,
not having tough problems with GCC and create our own optimisation techniques.
We can start with a "dumb assembler" with a 1-to-1 translation, and add optimisations
progressively.
--------------------------------------------------------------------

at least, it's a better effort than doing our own compiler from scratch, no ?

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