[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Scriiiitch ! Oups ! Danger, danger...

Hello everybody,

Sorry to add some comments only today but I have 269 mails left (i haven't yet finish to read all attached comments).

I have begin to read this thread and I thinks some peoples seems not known the vhdl, because if you need programming some application with vhdl, good luck.

Let's explain me.

First I well known vhdl (i am a hardware man, then thanks for the compliments).

Second, some history : vhdl is the abbreviation of Vhsic High-level Design Language, or Vlsi High-level Description Language (this is an academic fight about the D abbreviation); vhsic is itself the abbreviation for Very High Scale Integrated Circuit. This language have been firstly normalized in 1989, and have been modified only 2 time since (in 1993 and in 1998) under the reference ieee-1076.
This language have been originally done to create some behavioral description of hardware to be able to make some design simulations.
Yes, it has been developped in ada (and it has kept its limitations), but he hasn't all the feature of a programming language.

If some one need create a program in vhdl, he must forget the sequential programming, he must think parallel execution programming, clock synchronism and sampling.
In vhdl, you have two types of process the concurrential and the sequential (but not exactly same sequential than C execution).

The code inside the sequential structure is executed in order of writing, but the "shared" variables (the name is not totally appropriated) are updated for the other process only at the end of  the execution.
All concurrential process are executed in parallel.

By example, if in C you write :

main () {
...
a=b;
c=a;
...
}
You have 3 "shared" variables a, b, c and in memory a=b and c=a at the end

In vhdl, the syntax change (of course), but if you put your code like a concurrential statement :

entity...
end...
architecture...
...
begin
...
a <= b;
c <= a;
...
end;

At the end, you have only 2 "shared" variables b and c, and c=b at the end.

If you write the same thing into a sequential statement :
entity...
end...
architecture...
...
begin
...
process (...)
    wait ...;
    a <= b;
    c <= a;
end process;
...
end;

At the end, you have only 3 "shared" variables a,b and c, and in a=b  and c=? at the end. In realty, c keep the value of a before the execution of the process.



To be more practical, all the manipulation done in the article are caduc . Because, if you parallized your execution, you couldn't predict the execution time of the instruction. It's why we need add some synchronization construct to ensure the behaviour in vhdl.

At last,  Juergen spoke about fpga netlist. To obtain a netlist, you need reduce the set of vhdl code (this subset is known like the rtl - Register Transfert Level - vhdl, and it normalization is in progress, under name ieee-1076.6) and some of the major restrictions are no file access, no string/char support.

If someone need more informations about vhdl or want discuss on the subject, we can begin a new thread or I can send him some links on the subject.

See Ya,
Just an Illusion

Juergen Goeritz wrote:
Pine.LNX.3.96.1020420074609.22467A-100000@redwood.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/