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

[Juergen Goeritz <goeritz@oekomm.de>]

Hi!

this is indeed a very, very  convincing idea! Provide the
'fitter' for the processor with the processor. YESSS!

<compare to vhdl>
It would be similar to todays FPGAs tool chains!
You can use a 'global tool' like synplicity or whatever
and run the device fitter from the vendor to create
fpga netlist.
</compare to vhdl>

Now you take gcc (or the ones for ada, f, pas and so on)
and run the f-cpu optimization fitter as a second step.
And I would love to see the optimization procedure as a
part of the loader...
Then there were the chance for portability at maxperf.
And you wouldn't have to worry about f-cpu type during
compilation...

And the hardware guys must think about how software is
to be optimized - what amount of synergy effects :-) 

And finally I don't see problems using gcc as a frontend
tool only.

JG

On Sat, 20 Apr 2002, Yann Guidon wrote:
>> 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/
>

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