[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] Winograd DCT on my seul.org account
>> >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.
>> Please don't code software in VHDL - but this is just
>> my personal view and you could argue with me about it.
>and i won't give up this pleasure ;-)
>i would be very interested to see how such a parallel langage could
>be transformed into a sequential code.
>At least, the parallelism issues will disappear.
>The overload functions provide the user with transparent means
>to apply their algorithms on different data types.
>The event-driven model makes some more things easier (like
>the way functions are synchronised).
>I like these ideas :-)
>I don't want to use the ADA model verbatim, however.
Yes, don't give up the parallel view. It is superior. ;-)
>> I learned C because it is THE U**X language.
>but it's an oooooold langage :-( and it's not adapted
>to today's computers...
You are working with oooooold operating systems BTW.
U**X is nearly as old as I am :-( but still superior
>> >> 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
>> We are not so far apart. Just put 'link' to the left, too.
>> Linking is a dumb task that need not be addressed by your
>> optimization and thus should better be left out. Its like
>> cpp - gcc - as - link => for the dumb CPU => optimze - load
>i am not at ease with that.
>However, if we can use GCC 3/4 with XML export of the IR,
>[far in the future] this won't be a problem anymore.
>The GLIBC could be compiled in XML form and the linker could
>choose to use only the necessary parts (if you only use
>printf in your program) or "link" to te usual interface.
>If only printf is needed, the corresponding XML IR is integrated
>to the program's representation and optimised with it.
I wanted to express that maybe one could do shared lib linking
before doing the second optimization stage...
>> >maybe if we provide a simplified ISA to gcc, compilation and debug
>> >would be simpler...
>> Hm, hm! Debugging is depending on whether you let gcc
>> use a real opcode subset very simple. Otherwise you
>> have to have a sort of '-O0' switch in your afterburner
>> optimizer. Debugging on heavy optimized programs brings
>> a hack of invisibilities anyway and thus could be skipped.
>> If you debug you want to see as much as possible!
>i meant : debug/development of our "optimiser".
Argh! Handwork welcome...
>It is not a good thing to optimise an untested code, btw.
:-) It's funny to compare the results...
>> When you have finished your next paper (explaining it
>> in more detail and other optimzation hints) I could
>> probably convince myself to start to code such a beast...
>i'll try my best...
>but i better write papers that bring some money back to
>my pocket, too. My chocolate budget is very important ;-)
Haven't seen a lot of chocolate for quite a while... ;-)
>> >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.
>> Good teaching lessons BTW ;-)
>does that mean that you learned something ?
>if yes ==> oh great ! ;-)
Sorry, I can't help but learning... ;-)
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/