Oh, sorry, After reference another documents (about sw_64 arch floating
point introduction), I know, 0x7f is fsingle exp '0' (no move), 0x3ff is
fdouble exp '0' (no move).
And for fdouble, we still can calculate the real value base on qemu soft
fpu, so can simplify many details. So for me, the re
I guess, for sign number, the highest bit will not be used, but for
unsigned number, the highest bit will be used (then can let sign and
unsigned number can use the same format contents).
On 10/25/15 23:38, Chen Gang wrote:
>
> /*
> * Single format, it is 64-bit.
> */
> typedef struct TileGXFP
On 8/18/15 01:31, Richard Henderson wrote:
>
> For single-precision it appears that the format is
>
> 63 31 24 10 9 0
> [ mantissa with implicit and guard bits | cmp flags | ?? | s | exp ]
>
> We are able to deduce the bias for the exponen
OK, thanks. What you said sounds reasonable to me. I shall try to send
patches to qemu, firstly.
:-)
On 8/19/15 06:15, Peter Maydell wrote:
> On 18 August 2015 at 22:29, Chen Gang wrote:
>> On 8/18/15 22:32, Peter Maydell wrote:
>>> On 18 August 2015 at 15:27, Chen Gang wrote:
Welcome any
On 18 August 2015 at 22:29, Chen Gang wrote:
> On 8/18/15 22:32, Peter Maydell wrote:
>> On 18 August 2015 at 15:27, Chen Gang wrote:
>>> Welcome any ideas, suggestions and completions.
>>
>> You should stop working on adding new features and instructions,
>> and concentrate on getting a coherent
On 8/18/15 22:32, Peter Maydell wrote:
> On 18 August 2015 at 15:27, Chen Gang wrote:
>> Welcome any ideas, suggestions and completions.
>
> You should stop working on adding new features and instructions,
> and concentrate on getting a coherent set of patches for some
> subset of the instruction
On 18 August 2015 at 15:27, Chen Gang wrote:
> Welcome any ideas, suggestions and completions.
You should stop working on adding new features and instructions,
and concentrate on getting a coherent set of patches for some
subset of the instruction set reviewed and into QEMU.
thanks
-- PMM
On 8/18/15 05:43, Richard Henderson wrote:
>
> I repeat: This is an extremely bad idea.
> I will certainly not sign off on any patch that includes this.
>
OK. At least it is not the professional implementation. But for me, it
can always get the correct result:
- It 'guess' the 'flag' format in
On 08/17/2015 02:09 PM, Chen Gang wrote:
On 8/18/15 01:31, Richard Henderson wrote:
On 08/15/2015 11:16 AM, Chen Gang wrote:
But what you said is really quite valuable to me!! we can treat the flag
as a caller saved context, then can let the caller can use callee freely
(in fact, I guess, the
On 8/18/15 01:31, Richard Henderson wrote:
> On 08/15/2015 11:16 AM, Chen Gang wrote:
>
>> But what you said is really quite valuable to me!! we can treat the flag
>> as a caller saved context, then can let the caller can use callee freely
>> (in fact, I guess, the real hardware treats it as calle
On 08/15/2015 11:16 AM, Chen Gang wrote:
> OK, thanks, but for float(uns)sisf2 and float(uns)sidf2, we can not only
> simply move. :-(
Oh yes, I see that now. Unfortunate.
> But what you said is really quite valuable to me!! we can treat the flag
> as a caller saved context, then can let the ca
On 8/16/15 09:41, Chen Gang wrote:
> On 8/16/15 02:16, Chen Gang wrote:
>>
>> On 8/15/15 23:47, Richard Henderson wrote:
>>> On Aug 15, 2015 2:56 AM, Chen Gang
Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
insns also can be mixed together! The related C code,
On 8/16/15 02:16, Chen Gang wrote:
>
> On 8/15/15 23:47, Richard Henderson wrote:
>> On Aug 15, 2015 2:56 AM, Chen Gang
>>> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
>>> insns also can be mixed together! The related C code, -save-temps, and
>>> objdump files are i
On 8/15/15 23:47, Richard Henderson wrote:
> On Aug 15, 2015 2:56 AM, Chen Gang
>> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
>> insns also can be mixed together! The related C code, -save-temps, and
>> objdump files are in attachments (is it gcc's issue? I guess n
On Aug 15, 2015 2:56 AM, Chen Gang
> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
> insns also can be mixed together! The related C code, -save-temps, and
> objdump files are in attachments (is it gcc's issue? I guess not).
>
> So, I guess, we have to 'crack' all flo
On 8/13/15 22:59, Chen Gang wrote:
> Hello all:
>
> For me, I guess for single insns, they are simple, and each calculation
> insns group can not be mixed with each other. So current implementation
> should be OK.
>
> For double insns, I guess, only mul calculation can be mixed with other
> calcu
Hello all:
For me, I guess for single insns, they are simple, and each calculation
insns group can not be mixed with each other. So current implementation
should be OK.
For double insns, I guess, only mul calculation can be mixed with other
calculation groups (add/sub groups or int2float/double g
Oh, it seems a little complex, for a testsuite case, it lets double add
and double mul together! We need save more information for the correct
calculation in pack1.
It is 20020314-1.exe, the related code (I guess it is correct):
...
fdouble_unpack_max r10, r3, zero
.LVL2:
On 8/9/15 09:10, Chen Gang wrote:
>
> On 8/9/15 01:23, Chen Gang wrote:
>> Hello all:
>>
>> Below is my current idea for all floating point insns. For me, it is not
>> the precise implementation, even not completely implement -- assume pack
>> insns can only for packing (u)int32_t when they are us
On 8/9/15 01:23, Chen Gang wrote:
> Hello all:
>
> Below is my current idea for all floating point insns. For me, it is not
> the precise implementation, even not completely implement -- assume pack
> insns can only for packing (u)int32_t when they are used individually:
>
> fsingle_add1
Hello all:
Below is my current idea for all floating point insns. For me, it is not
the precise implementation, even not completely implement -- assume pack
insns can only for packing (u)int32_t when they are used individually:
fsingle_add1; return calc flags, save calc result to env.
On 8/4/15 23:04, Richard Henderson wrote:
> On 08/04/2015 06:56 AM, Chen Gang wrote:
>>
>> On 8/4/15 04:47, Chen Gang wrote:
>>> On 8/4/15 00:40, Richard Henderson wrote:
On 08/01/2015 02:47 AM, Chen Gang wrote:
> I am just adding floating point instructions (e.g. fsingle_add1),
> but
On 08/04/2015 06:56 AM, Chen Gang wrote:
>
> On 8/4/15 04:47, Chen Gang wrote:
>> On 8/4/15 00:40, Richard Henderson wrote:
>>> On 08/01/2015 02:47 AM, Chen Gang wrote:
I am just adding floating point instructions (e.g. fsingle_add1),
but for me, I can not find any details about them (th
On 8/4/15 04:47, Chen Gang wrote:
> On 8/4/15 00:40, Richard Henderson wrote:
>> On 08/01/2015 02:47 AM, Chen Gang wrote:
>>> I am just adding floating point instructions (e.g. fsingle_add1),
>>> but for me, I can not find any details about them (the ISA
>>> documents only give a summary descripti
On 8/4/15 00:40, Richard Henderson wrote:
> On 08/01/2015 02:47 AM, Chen Gang wrote:
>> I am just adding floating point instructions (e.g. fsingle_add1),
>> but for me, I can not find any details about them (the ISA
>> documents only give a summary description, but not details), e.g.
>
> The tileg
On 08/01/2015 02:47 AM, Chen Gang wrote:
> I am just adding floating point instructions (e.g. fsingle_add1), but
> for me, I can not find any details about them (the ISA documents only
> give a summary description, but not details), e.g.
The tilegx splits the four/six cycle arithmetic into multipl
Hello All:
I am just adding floating point instructions (e.g. fsingle_add1), but
for me, I can not find any details about them (the ISA documents only
give a summary description, but not details), e.g.
fsingle_add1
Floating Point Single Precision Add Part 1
Syntax
fsingle_add1 De
27 matches
Mail list logo
