On 2020/7/14 上午2:46, Laurent Vivier wrote:
>> +gparam->value = lock_user(VERIFY_WRITE, target_gparam->value,
>> + sizeof(*gparam->value), 0);
>
> I don't think you should use directly the guest memory.
> You should have something like that:
>
> int value;
>
I shall try to send another DRM_IOCTL_* patches within this weekend.
Thanks.
On 2020/6/29 下午7:05, Laurent Vivier wrote:
> Le 05/06/2020 à 03:32, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang
>>
>> Another DRM_IOCTL_* commands will be done later.
>>
That sounds good, I'll send patch v7, thanks.
On 2020/6/4 下午5:10, Laurent Vivier wrote:
> Le 04/06/2020 à 03:45, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang
>>
>> Another DRM_IOCTL_* commands will be done later.
>>
>> Signed-off-by
OK, thanks. I'll send patch v6. :)
On 2020/6/3 下午8:03, Laurent Vivier wrote:
> Le 03/06/2020 à 13:05, Chen Gang a écrit :
>> On 2020/6/3 下午5:49, Laurent Vivier wrote:
>>> Le 03/06/2020 à 03:08, cheng...@emindsoft.com.cn a écrit :
>>>> +#ifdef HAVE_DRM_H
>>>&
is_error(ret)) {
>> +unlock_drm_version(ver);
>> +return ret;
>> +}
>> +return host_to_target_drmversion(arg, ver);
>
> and unlock the structure here (rather than in host_to_target_drmversion()).
>
> You should return "ret" too.
>
OK, thanks.
>> +}
>> +return -TARGET_EFAULT;
>
> Why -TARGET_EFAULT? -TARGET_ENOSYS would be better.
>
OK, thanks.
Chen Gang.
On 2020/6/2 下午9:40, Laurent Vivier wrote:
>> +static inline abi_long target_to_host_drmversion(struct drm_version
>> *host_ver,
>> +abi_long target_addr)
>> +{
>> +struct target_drm_version *target_ver;
>> +
>> +if
;
> In fact, you should only check for the include with something like
> "check_include libdrm/drm.h" and then define a HAVE_DRM_H to use it
> around the new code:
>
> #ifdef HAVE_DRM_H
> #include
> #endif
>
> ...
> #ifdef HAVE_DRM_H
> static inline abi_long target_to_host_drmversion(...
> ...
> #endif
> ...
>
> #ifdef HAVE_DRM_H
> IOCTL_SPECIAL(DRM_IOCTL_VERSION,...
> ...
> #endif
>
OK, thanks. I'll send patch v4
Chen Gang
On 2020/5/12 上午2:43, Laurent Vivier wrote:
>>
>> + IOCTL_SPECIAL(DRM_IOCTL_VERSION, IOC_RW, do_ioctl_drm,
>> +MK_PTR(MK_STRUCT(STRUCT_drm_version)))
>
> Add a blank line here.
>
OK, thanks.
>> #ifdef TARGET_TIOCSTART
>>IOCTL_IGNORE(TIOCSTART)
>>IOCTL_IGNORE(TIOCSTOP)
2020 à 12:38, cheng...@emindsoft.com.cn a écrit :
>>> From: Chen Gang
>>>
>>> The other DRM_IOCTL_* commands will be done later.
>>>
>>> Signed-off-by: Chen Gang
>>> ---
>>> linux-user/ioctls.h| 3 +
>>> linux
On 2020/2/24 下午8:43, Paolo Bonzini wrote:
> On 22/02/20 13:25, Chen Gang wrote:
>> On 2020/2/22 下午3:37, Paolo Bonzini wrote:
>>> On 22/02/20 03:10, Chen Gang wrote:
>>>> Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
>>>>
>>>&g
On 2020/2/22 下午3:37, Paolo Bonzini wrote:
> On 22/02/20 03:10, Chen Gang wrote:
>> Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
>>
>> In helper_fxam_ST0, I guess, we need "env->fpus |= 0x200" (but I don't
>> know wheter it will be con
On 2020/2/22 上午10:10, Chen Gang wrote:
> On 2020/2/22 上午12:18, Paolo Bonzini wrote:
>> On 21/02/20 15:09, Chen Gang wrote:
>>>> -/* XXX: test fptags too */
>>>> +if (env->fptags[env->fpstt]) {
>>>> +en
On 2020/2/22 上午12:18, Paolo Bonzini wrote:
> On 21/02/20 15:09, Chen Gang wrote:
>>> -/* XXX: test fptags too */
>>> +if (env->fptags[env->fpstt]) {
>>> +env->fpus |= 0x4100; /* Empty */
>>> +return;
>>> +}
>&
On 2020/2/21 下午4:58, Paolo Bonzini wrote:
> On 21/02/20 04:45, cheng...@emindsoft.com.cn wrote:
>> static inline void fpush(CPUX86State *env)
>> {
>> -env->fpstt = (env->fpstt - 1) & 7;
>> -env->fptags[env->fpstt] = 0; /* validate stack entry */
>> +set_fpstt(env, env->fpstt - 1,
ers for it, I hope
qemu can still support tilegx.
By the way, for floating point instructions patches, I have sent before
(2 years ago), it seems I did not get any reply. I hope they are useful
for tilegx.
Thanks.
--
Chen Gang (陈刚)
Thanks.
> CC: Chen Gang <gang.chen.5...@gmail.com>
> Signed-off-by: Laurent Vivier <lviv...@redhat.com>
> ---
> target-tilegx/cpu.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/target-tilegx/cpu.c b/target-tilegx/cpu.
Hello Maintainers:
Please help check this patch when you have time.
Thanks.
On 5/15/16 07:40, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <cheng...@emindsoft.com.cn>
>
> These patches are the normal floating point implementation, instead of
> the original temporary o
On 5/6/16 00:11, Edgar E. Iglesias wrote:
> On Thu, May 05, 2016 at 10:48:57PM +0800, Chen Gang wrote:
>> On 5/5/16 00:05, Peter Maydell wrote:
>>> On 29 March 2016 at 15:13, <cheng...@emindsoft.com.cn> wrote:
>>>> From: Chen Gang <cheng...@emindso
On 5/5/16 00:05, Peter Maydell wrote:
> On 29 March 2016 at 15:13, <cheng...@emindsoft.com.cn> wrote:
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> The return address is in target space, so the restorer address needs to
>> be target space, too.
>
not bear the time point,
please help implement the tilegx floating point insns.
Thanks.
On 3/31/16 21:57, Chen Gang wrote:
>
> On 3/31/16 00:09, Laurent Vivier wrote:
>>
>> Le 30/03/2016 17:42, cheng...@emindsoft.com.cn a écrit :
>>> From: Chen Gang <cheng...@emindsof
On 3/31/16 00:09, Laurent Vivier wrote:
>
> Le 30/03/2016 17:42, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> The restorer needs the return code address which is frame->retcode, not
>> frame itself.
>
On 3/29/16 22:25, Laurent Vivier wrote:
> Le 29/03/2016 16:01, cheng...@emindsoft.com.cn a écrit :
>> The restorer needs the return code address which is frame->retcode, not
>> frame itself.
>>
>> Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
>> ---
On 3/29/16 06:57, Chen Gang wrote:
> On 3/29/16 06:17, Laurent Vivier wrote:
>>
>> The address of retcode in host and guest can differ.
>> You need something like:
>>
>> restorer = (unsigned long)(frame_addr + offsetof(struct
>> target_rt_sigf
an incorrect restore address, then causes unwind failure.
>>>
>>> Also cleanup the original incorrect indentation.
>>>
>>> Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
>>> ---
>>> linux-user/signal.c | 12 ++--
>>>
Hello all:
Is this patch helpful? If it shouldn't be merged into our master branch,
please let me know, I shall treat it as my own local patch (when I
update my local master branch, I'll merge it at last).
Thanks.
On 3/16/16 23:51, Chen Gang wrote:
> Hello all:
>
> It is only for
...@emindsoft.com.cn wrote:
> From: Chen Gang <cheng...@emindsoft.com.cn>
>
> Original implementation uses do_rt_sigreturn directly in host space,
> when a guest program is in unwind procedure in guest space, it will get
> an incorrect restore address, then causes unwind failu
3/16/16 23:38, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <gang.chen.5...@gmail.com>
>
> It is only for debug and analyzing tilegx qemu related issues.
>
> Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
> ---
> target-tilegx/helper.c| 34
On 2016年01月28日 22:54, Peter Maydell wrote:
> On 27 January 2016 at 01:37, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>> Within one single call to target_mmap(), it should be OK.
>>
>> But multiple call to target_mmap(), may call mmap_frag() multiple times
>
On 2016年01月26日 17:11, Peter Maydell wrote:
> On 26 January 2016 at 02:58, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>> The related comments for "if (prot1 == 0)" code block is "no page was
>> there, so we allocate one".
>>
>> So I gues
On 2016年01月26日 18:26, Peter Maydell wrote:
> On 26 January 2016 at 10:19, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>> When I run WeChat.exe with i386 wine with qemu-i386 under sw_64 arch.
>>
>> - The related command:
>>
>>"./i386-linux-u
thread is at the bottom of this
mail, please check.
On 2016年01月25日 23:07, Peter Maydell wrote:
> On 11 January 2016 at 09:01, <cheng...@emindsoft.com.cn> wrote:
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> mmap() size in mmap_frag() is qemu_host
On 2016年01月14日 17:41, Laurent Vivier wrote:
>
> Le 14/01/2016 10:37, Chen Gang a écrit :
>>
>> On 2016年01月14日 17:10, Laurent Vivier wrote:
>>>
>>> Le 14/01/2016 10:01, Chen Gang a écrit :
>>>>
>>>> I am not quite sure whethe
On 2016年01月14日 18:30, Peter Maydell wrote:
> On 14 January 2016 at 10:26, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>> On 2016年01月14日 18:05, Peter Maydell wrote:
>>> If we don't mark the page as non-writeable when we generate a TB
>>> from it, how do we de
On 2016年01月14日 17:10, Laurent Vivier wrote:
>
> Le 14/01/2016 10:01, Chen Gang a écrit :
>>
>> I am not quite sure whether kernel always returns sizeof(int) (I guess,
>> it should be).
>
> it can be 1 only if len is 1, but this is managed below.
>
Excuse m
On 2016年01月14日 16:15, Laurent Vivier wrote:
> Le 14/01/2016 07:24, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> After host_to_target_sock_type(), the length of val may be changed, so
>> calculate the related lv, to
On 2016年01月14日 18:05, Peter Maydell wrote:
> On 14 January 2016 at 06:03, <cheng...@emindsoft.com.cn> wrote:
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> Guest may allocate a readable, writable, and executable page, then write
>> data on the page, a
On 1/11/16 19:04, Peter Maydell wrote:
> On 11 January 2016 at 10:31, Chen Gang <cheng...@emindsoft.com.cn> wrote:
> [various things about a patch]
>
> Why have we dropped qemu-devel from this email thread?
>
Oh, sorry, I did not notice about it.
Thanks.
--
Chen G
Oh, sorry, after check again, I guess, we need continue to discuss.
On 2016年01月08日 17:40, Chen Gang wrote:
>
> On 2016年01月08日 16:25, Laurent Vivier wrote:
>>
>>> +if (optlen < sizeof(struct target_timeval)) {
>>> +return -TARGET_EIN
qemu tilegx,
during my free time.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
lv;
>
OK.
>> +if (copy_to_user_timeval(optval_addr, )) {
>> +return -TARGET_EFAULT;
>> +}
>> +if (put_user_u32(sizeof(struct target_timeval), optlen)) {
>> +return -TARGET_EFAULT;
>> +}
>
> if (put_user_u32(len, optlen))
> return -TARGET_EFAULT;
>
OK. I shall send patch v2 for it, in the next week.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
; ?
>>>
>>
>> At present, level is TARGET_SOL_SOCKET, but we need SOL_SOCKET.
>
> Yes, you're right... so there is a bug in TARGET_SO_BINDTODEVICE which
> is using "level" :)
>
OK, thanks. I shall send patch v2 for it, next week.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
linux-user/syscall_defs.h
>> +++ b/linux-user/syscall_defs.h
>> @@ -165,6 +165,11 @@ struct target_ip_mreq_source {
>> uint32_t imr_sourceaddr;
>> };
>>
>> +struct target_linger {
>> +int l_onoff;/* Linger active*/
>> +
e same location, prot1 will be PAGE_VALID (
now, it may be 0), then can protect to enter "if (prot1 == 0)", again.
> I don't really understand this mmap code, though -- that's just
> the result of looking at it for fifteen minutes or so.
>
OK, I can understand.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
zero;
-}
-}
-
-if (!sig) {
-return float32_zero;
+return packFloat32(1, exp, 0);
}
scount = countLeadingZeros64(absa) - 40;
On 1/3/16 06:25, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <gang.chen.5...@gmail.com>
>
> It is based on
can skip this patch (or discussion).
Thanks.
On 2015年12月30日 09:35, Chen Gang wrote:
> Hello all:
>
> This patch is only for a discussion, I guess this patch is valuable for
> i386 wine running Windows.
>
> Theoretically, this patch is incorrect, we have to implement softmmu to
&
:
> From: Chen Gang <cheng...@emindsoft.com.cn>
>
> mmap() size in mmap_frag() is qemu_host_page_size, but the outside calls
> page_set_flags() may be not with qemu_host_page_size. So after mmap(),
> call page_set_flags() in time.
>
> Also let addr increasing step be
On 12/30/15 09:14, Laurent Vivier wrote:
>
> Le 30/12/2015 02:10, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> When mapping MAP_ANONYMOUS memory fragments, still need notice about to
>> set it zero, or it will cau
to enable or
disable the related code (if they are really valuable enough for some
using cases).
Thanks.
On 2015年12月30日 09:11, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <cheng...@emindsoft.com.cn>
>
> It is a temporary fix for i386 target system running Windows.
>
>
On 12/24/15 23:52, Chen Gang wrote:
> On 12/24/15 07:07, Richard Henderson wrote:
>
>> Moreover, I thought we agreed to do away with that CALC bit.
>>
After check again, I guess, we can stil reserve CALC bit:
- Then we can remove float32_to_sfmt (use high 32-bit to save f
On 12/25/15 04:01, Richard Henderson wrote:
> On 12/24/2015 07:38 AM, Chen Gang wrote:
>>
>> OK, thanks. Since fp_status need to be initialized to be 0, so I will
>> declared it statically, too (need we consider about thread safe for it?
>> I guess not).
>
> W
On 12/24/15 17:54, Laurent Vivier wrote:
>
> Le 24/12/2015 02:07, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> In this case, real_end is larger than end, which may cause mmap_frag
>> process the incorrect memory re
ally, too (need we consider about thread safe for it?
I guess not).
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
ain, when
you have time, it may still have issues.
> Moreover, I thought we agreed to do away with that CALC bit.
>
OK, I will try, next.
I will copy and reconstruct related code from qemu fpu implementation
instead of (u)int32/64_to_float32/64 functions (just like you said, I
guess).
Hope I can finish within 2015-12-31.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
, ideas, and completions.
BTW: Merry Christmas! :-)
Thanks.
On 2015年12月24日 09:07, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <cheng...@emindsoft.com.cn>
>
> In this case, real_end is larger than end, which may cause mmap_frag
> process the incorrect memory regio
On 12/11/15 06:15, Chen Gang wrote:
>
> On 12/11/15 04:18, Richard Henderson wrote:
>> On 12/10/2015 09:15 AM, Richard Henderson wrote:
>>> d = (uint64_t)sign << 63;
>>> d = deposit64(d, 53, 11, exp);
>>> d = deposit64(d, 21, 32, man);
On 12/21/15 23:01, Richard Henderson wrote:
> On 12/20/2015 07:30 AM, Chen Gang wrote:
>> And we have to still check TILEGX_F_CALC_CVT, for they are really two
>> different format: TILEGX_F_CALC_CVT has no HBIT, but TILEGX_F_CALC_NCVT
>> has HBIT (which we need
> From: "Laurent Vivier";<laur...@vivier.eu>;
>
> Le 21/12/2015 03:33, cheng...@emindsoft.com.cn a écrit :
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> When mapping MAP_ANONYMOUS memory fragments, still need notice about to
>> set
On 2015年12月18日 18:47, Chen Gang wrote:
>
> On 2015年12月18日 17:41, Laurent Vivier wrote:
>>
>> Le 18/12/2015 07:51, Chen Gang a écrit :
[...]
>>>
>>> +++ b/linux-user/mmap.c
>>> @@ -567,6 +567,10 @@ abi_long target_mmap(abi_ulong start, abi_
overflow cases -- like double implementation does).
- Use (u)int32_to_float32 for the mantissa.
- Then process exp again.
Thanks.
On 12/11/15 06:14, Chen Gang wrote:
>> In particular, if gcc decided to optimize fractional fixed-point types, it
>> > would do somethi
On 2015年12月18日 17:41, Laurent Vivier wrote:
>
>
> Le 18/12/2015 07:51, Chen Gang a écrit :
>>
>> I found this issue during my working time, it is about sw_64 (almost the
>> same as alpha) host running i386 wine programs.
>>
>> I also found another
On 12/18/15 17:37, Laurent Vivier wrote:
>
> Le 18/12/2015 07:26, Chen Gang a écrit :
>>
>> For fcntl, it always needs to notice about it, just like do_fcntl() has
>> done, or it will cause issue (e.g. alpha host run i386 guest).
>>
>> Signed-off-by:
On 12/19/15 06:15, Laurent Vivier wrote:
>
> Le 18/12/2015 23:12, Chen Gang a écrit :
>>
[...]
>>
>> OK, thank you very much. I shall config my email client again to notice
>> about it.
>
> You should not use your email client to send patches, you shou
On 12/19/15 05:58, Laurent Vivier wrote:
>
> Le 18/12/2015 22:40, Chen Gang a écrit :
>>
[...]
>> I did not get any script/checkpatch.pl complains, originally.
>>
>> Does my email client configuration is incorrect, then cause incorrect
>> mail format? I gu
For fcntl, it always needs to notice about it, just like do_fcntl() has
done, or it will cause issue (e.g. alpha host run i386 guest).
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
---
linux-user/syscall.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
, but for most archs, they have no this issue.
linux-user/mmap.c: Always zero MAP_ANONYMOUS memory in target_mmap()
In some architectures, they have no policy to zero MAP_ANONYMOUS memory,
which will cause issue for qemu target_mmap.
Signed-off-by: Chen Gang <gang.che
On 12/11/15 05:17, Richard Henderson wrote:
> On 12/10/2015 06:15 AM, Chen Gang wrote:
>> +#define TILEGX_F_MAN_HBIT (1ULL << 59)
> ...
>> +static uint64_t fr_to_man(float64 d)
>> +{
>> +uint64_t val = get_f64_man(d) << 7;
>>
On 12/12/15 08:41, Richard Henderson wrote:
> On 12/11/2015 03:38 PM, Chen Gang wrote:
>>
>> On 12/11/15 05:17, Richard Henderson wrote:
>>> On 12/10/2015 06:15 AM, Chen Gang wrote:
>>>> +#define TILEGX_F_MAN_HBIT (1ULL << 59)
>>
It passes gcc testsuite.
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
---
target-tilegx/helper-fsingle.c | 212 +
1 file changed, 212 insertions(+)
create mode 100644 target-tilegx/helper-fsingle.c
diff --git a/target-tilegx/helper-fsing
They are used by fsingle and fdouble helpers.
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
---
target-tilegx/helper-fshared.c | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 target-tilegx/helper-fshared.c
diff --git a/target-
On 12/11/15 05:37, Richard Henderson wrote:
> On 12/10/2015 06:16 AM, Chen Gang wrote:
[...]
>>
>> diff --git a/target-tilegx/cpu.h b/target-tilegx/cpu.h
>> index 03df107..445a606 100644
>> --- a/target-tilegx/cpu.h
>> +++ b/target-tilegx/cpu.h
>> @@ -8
; Hmm. Actually, this incorrectly adds the implicit bit. We'd actually need to
> steal portions of softfloat.c to do this properly. Which still isn't that
> difficult.
>
Yes, thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
On 12/11/15 01:15, Richard Henderson wrote:
> On 12/10/2015 06:15 AM, Chen Gang wrote:
>> +#define TILEGX_F_CALC_CVT 0 /* convert int to fsingle */
>> +#define TILEGX_F_CALC_NCVT 1 /* Not convertion */
>> +
>> +static uint32_t get_f32_exp(float32 f)
>
free time).
And thank my company for the support. :-)
Thanks.
On 12/10/15 22:12, Chen Gang wrote:
>
> These patches are the normal floating point implementation, instead of
> the original temporary one.
>
> It passes building, and gcc testsuite.
>
> Chen Gang (4):
&
It passes gcc testsuite.
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
---
target-tilegx/helper-fdouble.c | 400 +
1 file changed, 400 insertions(+)
create mode 100644 target-tilegx/helper-fdouble.c
diff --git a/target-tilegx/helper-fdoub
It passes normal building, and gcc testsuite.
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
---
target-tilegx/Makefile.objs | 3 +-
target-tilegx/cpu.h | 2 ++
target-tilegx/helper.h | 12
target-tilegx/translate.c
Hello Maintainers:
Please help check these patches when you have time.
If it is necessary to send patch v3 for it, please let me know.
Thanks.
On 11/17/15 03:37, Chen Gang wrote:
> From d0f0e0a78e81f9589d25b0a2b4ad826d6e55257d Mon Sep 17 00:00:00 2001
> From: Chen Gang <ga
Oh, sorry again, the original attachment is incorrect, either.
The attachment in this reply is the correct one.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
> From: xili_gchen_5...@hotmail.com
>
>From 1c4bb91e72995a1675d3aa0f911c534a3e8db749 Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Tue, 17 Nov 2015 03:07:33 +0800
Subject: [PATCH v2 2/4] target-tilegx: Add single floating point implementation
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com&
Excuse me, I copied/pasted the patch to the website, which may generate
the incorrect coding styles.
Please check the attachment in this reply mail for the correct coding
styles (and sorry, the original mail's attachment which I chose is
incorrect).
On 11/17/15 03:43, Chen Gang wrote:
> F
>From d0f0e0a78e81f9589d25b0a2b4ad826d6e55257d Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Tue, 17 Nov 2015 03:09:18 +0800
Subject: [PATCH v2 4/4] target-tilegx: Integrate floating pointer implementation
It passes normal building, and gcc testsuite.
S
>From db171c94e8c9df446c091d9f42004c80ed8c6ccc Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Tue, 17 Nov 2015 03:08:38 +0800
Subject: [PATCH v2 3/4] target-tilegx: Add double floating point implementation
Signed-off-by: Chen Gang <gang.chen.5...@gmail.com&
>From d0f0e0a78e81f9589d25b0a2b4ad826d6e55257d Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Tue, 17 Nov 2015 03:13:54 +0800
Subject: [PATCH v2 0/4] target-tilegx: Implement floating point instructions
These patches are the normal floating point implementation
>From 40c3e3f79b206b9506e0d6679e301885bb3ee277 Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Tue, 17 Nov 2015 03:04:50 +0800
Subject: [PATCH v2 1/4] target-tilegx: Add floating point shared functions
They are used by fsingle and fdouble helpers.
Signed-off
Excuse me, I copied/pasted the patch to the website, which may generate
the incorrect coding styles.
Please check the attachment in this reply mail for the correct coding
styles (and sorry, the original mail's attachment which I chose is
incorrect).
On 11/17/15 03:41, Chen Gang wrote:
> F
On 11/12/15 22:34, Richard Henderson wrote:
> On 11/08/2015 06:43 AM, Chen Gang wrote:
>
>> +#if !defined(HOST_WORDS_BIGENDIAN)
>> +/* According to float(uns)sisf2 and float(uns)sidf2 in gcc tilegx.md */
>> +uint64_t exp : 8; /* exp, 0x9e:
On 11/13/15 00:18, Richard Henderson wrote:
> On 11/12/2015 05:12 PM, Chen Gang wrote:
>> On 11/12/15 22:36, Richard Henderson wrote:
>>>> +if (sfmt.calc == TILEGX_F_CALC_CVT) {
>>>> +if (sfmt.sign)
>>>> +f.f =
sa, fp_status);
>> +} else {
>
> Formatting.
>
> You really should know better by now.
> I'm not even going to look at the rest.
>
Excuse me, my English is not quite well, I am not quite understand your
meaning.
Does the code above have issues?
Thanks.
--
Chen Gang (陈刚)
Ope
On 11/13/15 00:10, Peter Maydell wrote:
> On 12 November 2015 at 16:04, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
>> On 11/12/15 22:34, Richard Henderson wrote:
>>> On 11/08/2015 06:43 AM, Chen Gang wrote:
>>>
>>>> +#if !defined(HOST_WORDS_BIGENDI
>From c467db1c0a5f4c6560b8b2115732aa718c4b Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 8 Nov 2015 09:10:17 +0800
Subject: [PATCH 3/4] target-tilegx: Implement fpu fdouble floating point
instructions
Signed-off-by: Chen Gang <gang.chen.5.
>From 8fab455a5ac5508d06cc69f778e926ad098fbe5b Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 8 Nov 2015 09:11:36 +0800
Subject: [PATCH 4/4] target-tilegx: Let fpu implementation code can be built
and used
It passes gcc testsuite: it can get the sa
>From 91a3d7d591cac6c4a39d4dbc5c3ffe8c17b10b6a Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 8 Nov 2015 09:05:29 +0800
Subject: [PATCH 1/4] target-tilegx: Add fpu header file
It defines the main data structures for tilegx fpu. Also it provides th
>From 3270485ebd56429f6f62f0a4f967009d8a1b14d6 Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 8 Nov 2015 09:08:40 +0800
Subject: [PATCH 2/4] target-tilegx: Implement fpu single floating point
instructions
Signed-off-by: Chen Gang <gang.chen.5.
>From 8fab455a5ac5508d06cc69f778e926ad098fbe5b Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 8 Nov 2015 09:28:16 +0800
Subject: [PATCH 0/4] Implment fpu floating point instructions
It passes gcc testsuite: get the same result like the original float
the nearest skipped bit carrying for fdouble.
- Process the nearest skipped bit carrying for fsingle.
I shall try to fix the left issues all within this week (2015-11-08).
Thanks.
On 11/1/15 12:30, Chen Gang wrote:
>
> Oh, sorry, it can not pass gcc testsuite: the fdouble mul insns have
&g
).
Thanks.
On 11/1/15 00:59, Chen Gang wrote:
> From 42733d085bfcb4882cfa4eb25a9387e3d953a64f Mon Sep 17 00:00:00 2001
> From: Chen Gang <gang.chen.5...@gmail.com>
> Date: Sun, 1 Nov 2015 00:50:33 +0800
> Subject: [PATCH] target-tilegx: Implement floating point instructions
>
nd fixing the related
issues.
Hope I can finish today and send patches for it (although I am not quite
sure).
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
>From 42733d085bfcb4882cfa4eb25a9387e3d953a64f Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 1 Nov 2015 00:50:33 +0800
Subject: [PATCH] target-tilegx: Implement floating point instructions
It is implenented in a normal way, and passed unit tests (8 t
ormalize and pack result from srca, srcb, and dest.
* ; move result to dest.
*/
#pragma pack(pop)
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
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.
> */
>
value, 64-bit.
*/
typedef struct TileGXFPDFmtV {
uint64_t unknown0 : 4;/* unknown */
uint64_t mantissa : 55; /* mantissa */
uint64_t unknown1 : 5;/* unknown */
} TileGXFPDFmtV;
#pragma pack(pop)
Welcome any ideas, suggestions, and completions from any members.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
1 - 100 of 614 matches
Mail list logo
