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

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

> What about CAML or derivatives ? :)
And eiffel ? But, we need to support a lot of language and not only the one we 
can optimize...

> You are speaking only about imperative languages, which, I think, is not
> very suitable in huge projects where we need to trust what we code.
The question is where did we need a language for the F-CPU ? for hardware : 
VHDL, OS : ASM+C, Virtual machine : ASM+C or VHDL,  F-CPU asm : C...

So where did you see a need of a new language ? For special developpement 
on F-CPU, perhaps ? In that case, it's not our choice, but the one of the 
developpers !

> Anyway, I don't think C is the most efficient language. Some people
> considers it as a super assembler (register allocation, etc.), but in fact,
> the way you write a C program is underoptimized compared with an 
> assembler :

> For example, to do a left bit rotation, you need to do in C :
>    rotated_value = (value << shifter) | (((unsigned)value >>
> ((sizeof(value) * 8) - shifter)) & ((sizeof(value) * 256) - 1));

I didn't agry whit your remark, it's possible to add some rewriting "macro" in 
gcc backend, so that a shiftl + or + shiftr = rotl. I think that's possible, 
perhaps not easy but possible.

> There is no C operator for that kind of bit operation and the generated
> code is not a 'rotl' but a mixture of 'shl' and 'or' operations. Using
> inline functions with asm ? not a standard. Depending on target, GCC is
> less or more efficient. Visual C++ or Borland asm directives are definitely
> bad (cannot tell which register is allocatable or clobbered in an asm
> directive).

> The way to code in C language is one way to code but not the most efficient:
> it is very easy to make buggy code even if each module has no bugs.
I agree, but that's not the question, C/C++ will used and represent the 
majority of gnu software, so we need a good gcc port for F-CPU. But to test 
it and have some result we need a good virtual machine to see how bad the 
generated code is ;-)

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