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

[Juergen Goeritz <goeritz@oekomm.de>]

On Sat, 20 Apr 2002, Yann Guidon wrote:
>Juergen Goeritz wrote:
>> this is indeed a very, very  convincing idea! Provide the
>> 'fitter' for the processor with the processor. YESSS!
>
>i'm happy to see that this idea is not so hallucinating for
>at least someone ;-) maybe you like it because you're also
>a "HW guy" but the important thing is to have the benefits
>and let people understand how that works.

I spent a long, long time of my life optimizing code for
processors - maybe you understand when I say, no more!
I want an automatic approach.

>> <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>
>
>very nice comparison, even though i didn't think about it :-)

Maybe you just didn't see it ;-)

>However this creates a new kind of problems : gcc should export
>the whole Intermediate Representation instead of just register-wise
>code, because register reallocation works best on program-wise
>working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data
>in the form of a flattened netlist, but GCC outputs code
>that almost looks like already-fitted code.

As an idea, GCC may not be allowed to use the whole set of
opcodes though. Or you may define a 'hypothetic processor'
(like the HYPERPLD in one of the PLD synthesis tools) with
only generic opcodes that allows your type of afterburner
optimization.

>> 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...
>that's ADA/VHDL-like, no ? :-P

I would not try to reduce the input capabilities for the
developer. Lately I ported a pascal program to C that was
heavily using overlays. It was a bit tedious. If I had
a pascal compiler with linux capable of overlays I could
have just saved me this work. And imagine you want to
rewrite the whole fortran library stuff. Better don't!!!

>> Then there were the chance for portability at maxperf.
>> And you wouldn't have to worry about f-cpu type during
>> compilation...
>but then your "distibuted binaries" would be some kind of IR, 
>not executable code. what happens if you want to compile
>a boot loader or a boot kernel ? (i guess the answer but
>i ask you anyway)

This depends. If you define an opcode subset to be used
by GCC it could either be a subset of really existing ones
or hypothetical ones that must be converted/optimized in
a second step first. Today you have two different ways to
use programs
a) in a operating system environment where you have a
   loader program as part of the OS or
b) independent code that was compiled to fixed addresses
   (embedded).

The programs you mentioned usually are of type b) in
which case you would first compile&link with GCC. And
depending on the used opcode subset it may be runnable
code (of course slow! but interchangeable) or you need
that extra step and use the afterburner optimization
to get the real (fast) code (dedicated to a specific
version of f-cpu). But the programs you mentioned do
not really need to be fast (BIOSes aren't fast anyway).

In general I propose an additional step in the toolchain
compile/optimize - assemble - link - optimize - load.

Some years ago there were some developments like this
by the Amiga guys. They kept two versions of code in
their system. A special code file (hypothetical assem.)
that was converted to processor code by the loader at
activation time. The system kept both versions and did
only exchange the unconverted ones with other systems.
But they mixed their idea up too much with parts that
cracked system reliability finally. The part of post-
optimization and adaption to the processor was a good
idea though and should be proceeded by f-cpu, of course
in an adapted manner. ;)

JG

>PS: since i am subscribed to this list, you don't need to CC: :-)

Oops.


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