Rep:Re: 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: 04/12/02
Objet: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port

hi,

>De: "Antoine"
>
>>>In my opinion, an integer (or a pointer) wider than 64 bits
>>> really has no point. Such widths should be reserved for SIMD.
>>
>> why "reserved" ?
>
>I meant e.g. 128-bit registers could be used for 2*64, 4*32,
>8*16 or 16*8, but not for a single 128-bit integer/pointer.

oh, _that_ old debate ...

>>>yep ! But you rebegin... From one hand, you want to keep the binary
compatibility with the SIMD growing size, and you to make choose of the
size of scalar type ??? that's not consistent. If you need manipulate
bitfield you must used inter-chunk instruction (there is a big lack of
it because you ever think with the 64 bits register in mind, so all
interchunk op are mais thought the 64 bits scalar size)
Mainly if you have a 64 bits register, you will have "somewhere" the 64
that goes inside complexity (o(n), o(ln(n)), o(n*log(n)), think of a 128
bit shifter...). If n is wider (128 bits!) you will decrease the speed
of the code for very very specific operation, where most of the time
inter-chunk op will be enough (inter-chunk instruction will have the
complexity of the number of chunks).


but then why would someone be kept from using a "whole"
register for holding a bitmask (for video, or whatever)
or even an IPv6 address, or things like that ?
integers are not the only data types out there ...

>>>that's so specific... We don't make a dsp or even a network cpu. Do
forget that such feature will slow down the clock !

my point of view is that a register doesn't necessarily
contains an "integer". Usually, in C, one has to cover
bitmask and such under the name of "integer". but i consider
that as a limitation .... What if i'm dealing with a bitfield
of many bits ? It's SIMD in a sense, but if there are 100 bits,
then the 'integer' approach does not work nicely.

>>>That's the internal gcc stuff to handle bitfield the right way.

However if you think in term of "register" it's ok with F-CPU.

This is why the size postfix would contain .128 and so on.
This would trap if the CPU doesn't implement the
corresponding operations, but at least ROP2 can do it ;-)

>>>Forget the idea of emulate none existing instruction !! Antoine have
demonstrate that will be a real mess. And the performance will suffer a
lot. We make free softawre. So recompile !

>But someone else had a point : 128-bit floats could be useful ;)

well, they are quite large and not much used, or useful
in practice .... unless someone wants to do quantic

>>>All stuff like Maya or synthetic image. I even think that spice use
long double (80 bit on x86, 128 on Sparc)

chromodynamics or something like that _and_ comes with the
adapted unit ;-) (lazy me)

>>>yep :)

YG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

_____________________________________________________________________
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/