Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting

[whygee@club-internet.fr]

hello,

>De: Andreas Romeyke
>Hallo,
mojn,

>On Mon, 25 Feb 2002, Yann Guidon wrote:
>> > Any hints?
>> i am not sure to understand.
>I meant:
>
>- - we need a compiler which generates temporary code at a level between
>assembler/machinecode and C + libc like Forth does. At this level we had
>basic functions, which 
>
>first:
>- - can be compiled/assembled automatically by a stupid Compiler/assembler,
>so we have first the issue of functionality
>
>second:
>- - can be assembled/substituted by handoptimized SIMD-assembler, so we have
>then the issue of higher speed
>
>(BTW. I know about that there is only a local optimization possible, but
>it depends on abstraction level of the basic functions in temporary code)

usually, scheduling optimisation requires a block of around 100 instructions
to be worth the effort and the result. it is usally performed with dataflow
analysis. i presume that GCC's internal temporary representation is interesting
but it seems too complex for me to do a quick hack ...

>> however, in the race for performance, one of worst the problems is to
>> get rid of of the intermediate levels of representation, because we
>> lose data and semantics during each conversion. What matters most is
>> "what does the program do" rather than "how does it do it" because we
>> can find better ways.
>
>IMHO we should use a simpler language than C because a Compiler with
>SIMD and superpipelining should be easier to developed.

C clearly lacks some modern and useful features such
as returning multiple data through the registers (and not
by reference) for example. the pointer management is awful.
SIMD is of course a big pain but superpipelining should
not be a problem because a dataflow analysis should do the trick
on most codes.
Unfortunately, most code today is written in C :-(

>> I have the feeling that GCC will make really slow programs.
>> while the superpipeline can reach a somewhat higher frequency,
>> an inadequate compiler makes the system work really slow.
>> i fear that this constatation can be used as an argument
>> against the project.
>
>The problem is that softwaredevelopers thinking more in serial than
>parallel. You can verify this thesis comparing your code-writing with VHDL
>and with C/C++.

sure. modularity and laziness are other negative factors...
you know, "if it compiles then i can leave it as is"...

>> PS: anybody knows whether he comes to the LSM ?
>I will not be there, but I want.
please keep us informed ! it would be cool if you could come.

>BTW.: Anybody would send me the F-CPU-CDROM from last CCC, any hints?
i could. send me your address (private email).

>Bye Andreas
YG

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