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

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

hi,

Juergen Goeritz wrote:
> 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.

i did not spend my life doing this but as ar as i remember, i have
spent more than ten years trying to work around a lot of problems.
i too say "no more". However you can't solve a problem you're foreign to,
and you can't automate something you can't do yourself.
A lot of my efforts are an attempt to understand all i can from the
matter and find realistic solutions. it requires some abnegation,
such as watching over this list for example ;-P

> >> <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 ;-)
it was not the original idea (giving gcc an over-simplified view of the
processor and doing the rest).

> >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.

that's what i thought (more or less) in the first place.

> >> 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!!!

arrgggghhhhh....

however, i found that expressing algos in VHDL was not so difficult,
though it needed some leaning. But it was easier to learn VHDL than C
(for me). C is used everywhere and one feels a bit forced, but VHDL
is often tought very superficially and the benefits are not apparent.

> >> 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.
most certainly.

> 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).
;-D

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

i seem to have understood something like that.
Now my idea was something like
 cpp - gcc - as=>simulates the dumb CPU and optimize<= - link - load

maybe if we provide a simplified ISA to gcc, compilation and debug
would be simpler...

> 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. ;)
well, if you have enough time to hack that, go ahead...
but before you optimise, take some time to learn how
to do that. I know that i don't write enough papers
about it, but you already know that F-CPU is another
new type of beast which needs its own techniques
and mindset. It was designed almost as a Trojan Horse,
seeming quite similar to others (to not scare the execs
out there) but the guts and programming habits have
probably no equivalent.
As a "HW guy", you certainly have enough background
to understand most things, so i'm only worried about
my own ability to teach them.

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

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