Rep:Re: Re: [f-cpu] GCC 3.1 for F-CPU port

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

-----Message d'origine-----
De: whygee@club-internet.fr
A: f-cpu@seul.org
Date: 03/12/02
Objet: Re: Re: [f-cpu] GCC 3.1 for F-CPU port

X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu

hi !

>De: devik
>> there are several F-CPU assemblers now.
>> even though i don't know which one to trust :-P
>> everyone with a specific syntax, unique features etc ...

>:) Are there reasons other than personal ego ? Like
>if all wants their own assembler ? And are these
>documented so that I can select one ?

nobody is "happy" with other's SW.
unfortunately they are loosely documented,
and the only discriminating factor is whether it works ...

>>>Cedric and Alex have written a pretty complete generic assembler
working with x86 and fcpu. IT's pretty fast and modular. It seems that
they didn't release it now because they have udge work on documentation.
So Cedric, time is up ! Show your code !


>> emulator is a big problem. it will take time
>> before it's completely solved but i am confident.
>
>I understand that it is a big piece of code. But is
>the principle so hairy ?

"in principle, no" :-)

>>>One emulator work, but without SIMD stuff !

One of the big limitations is C itself.
handling the large SIMD data is not easy, so a library
must be designed ... C is limited to 64-bit data
but not F-CPU, which can be configured to handle larger data.

>>>Don't mixe things !! F-cpu are definitly a 64 bits cpu. We try to
make it easy to enlarge the register for SIMD stuff. have 64 bits
register is not a good idea, 256 is much more interresting but 256 means
: 4*64,8*32,16*16,32*8. You never manipulate scalar data with more than
64 bits (or 128 for fp but it's for later). 

[...]
>I use only zero and not-zero accompanied with cmpxx. I didn't
>use MSB because there was discussion about its removal and LSB
>because I don't know good use for it yet ;-)

The problem with MSB is : how to deal with the cases
where F-CPU implements, say, 128-bit registers ?
until now, it's hardwired to bit 63 of the registers
(that's the sign bit ...) but i don't know what will
happen next.

>>> 64 bits register is a futur problem sources ! Think of fcpu with 256
bits register ! (it's more easy to down size than up size, and 4 64 bits
fp vector seems to be an optimal for spec bench as said by a university
paper on vectorising).

>>>Just one question concerning gcc : if you use 2 separate registers
but some instruction could access both register, is that easy to use it
(2*2r1w could be much much quicker than 1 one big 4r2w, and you double
the register number)? And it is possible to "paired" instruction world
easly (it must be done for I64 code). I stay with my "little vliw" idae
for fc1 :)

>>>We have now a gcc expert ! We could evaluate the use of any f-cpu
feature by gcc :)

>>>So now try to convince Whygee that forbbid more than 2 adresse alias
in register bank is a very bad idea !

nicO

_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
Règlement : http://www.ifrance.com/_reloc/sign.sms

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