@guy: I don't know what each letter stands for, but the link has this:

TRN1 Interleave even elements from two vectors .

I assume there is TRN for odds and maybe mixed?

On Tue, Jun 15, 2021, 03:34 Roger Ferrer Ibanez, <roger.ferrer@...> wrote:

Hi,

I didn't realise this was the private list and Romain is not in

this one. So I'm forwarding his answer on his behalf

There's some sample codes to emulate SVE/NEON-like instructions

using the historical EPI intrinsics (should be mostly

self-explanatory, Roger will definitely know them ) here:







<https://github.com/rdolbeau/EPI-test-codes-vector/blob/master/simplefft16-rvv/vf64.h>







Other subdirectories of the same repo includes integer variants.







Not all functions might work for non-power-of-two length, but

they can be a starting point for some useful pattern.







Cordially,

Hope this helps.

Kind regards,

On 15/6/21 9:08, Roger Ferrer Ibanez

wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most

efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the
  
  scalar to subtract
  
  
  



• zip is harder: start with the "halved indexes" vid + vsrl.vi
  
  (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements"
  
  vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a
  
  power of two, shift) with the first index of the second vector
  
  (which maybe is vl/2 in your case). So you get 0, vl/2, 0,
  
  vl/2, 0, vl/2, .... Then add this vector to the halved indexes
  
  so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
  
  
  



• unzip worst of the cases you can reverse what you did for
  
  zip
  
  
  



• trn I don't have any ideas from the top of my head, /cc
  
  Romain Dolbeau who may recall how he worked around the cases
  
  in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via

lists.riscv.org wrote:

Dear  Craig and Roger,

     ​    ​Thanks a lot for providing  me  good solution. I have tried them,  they are

all good solutions of  upsample

application.

    ​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and

 so on.  The Index value  is still difficult to be initialized.

Best Regards

Damon Yu

------------------原始邮件

------------------

发件人: <tech-vector-ext@...>

发送时间:06/11/21 18:51:12

收件人: <tech-vector-ext@...>

主题:Re: 回复：[RISC-V] [tech-vector-ext] RISC-V Vector

Spec version 1.0-rc1-20210608

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you

(logical) shift right 1 bit (vsrl.vi)

would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size

and you don't have to load a materialised value from memory

(you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via

lists.riscv.org wrote:

Hi, all

    I encountered a difficulty of applying

 "vrgather" instruction recently.  The details are shown

blow:

    The date from source should be duplicated as

pair in a upsample application. 

     Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]

           dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4,

5, 5, 6, 6, 7, 7, 8, 8]

     So, my relazation is:

--------------------------------------------------------------------------------------------------

  int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5,

5 ........，31，31}；// to be compatibled of all the

VLEN(128 ~ 1024)

   vfloat32m2_t data = vundefined_f32m2();

    vfloat32m1_t  zero

= ( vfloat32m1_t )vmv_v_i_i32m1(0);

   while(length >0)

    {

         int gvl = vsetvl_e32m1(length);

        vuint32m2_t v_index = vle32_v_u32m2(index,

gvl);

         vfloat32m1_t src_data = vle32_v_f32m1(src,

gvl);

         data = vset_f32m2(data, src_data, 0);

         data  = vset_f32m2(data, zero, 1);

         vfloat32m2_t res =

vrrgather_vv_f32m2(data, v_index, gvl);  

         length -=gvl;

         src += gvl;

        vse32_v_f32m2(out, res, gvl);

        dst +=gvl;

    }

-----------------------------------------------------------------------------------------------

  

    As shown before, the index data should be

 initialized as the max VLEN to make the code  compatibled.

So do all the applications,

that need a constant.

    I think it is contrary to

the idea of RISC-V, that one code can run on all the

RISC-V hardware.  Does anyone have a better method

? 

Best Regards

Damon Yu

------------------原始邮件

------------------

发件人: <tech-vector-ext@...>

发送时间:06/09/21 14:46:30

收件人: <tech-vector-ext@...>

主题:[RISC-V] [tech-vector-ext] RISC-V Vector

Spec version 1.0-rc1-20210608

I've just tagged the first release candidate for v1.0 of the vector


spec in github.  PDF attached below.





I've included the TG agreed updates and handled almost all of the


outstanding issues for v1.0.  Thanks for all the feedback.





I would appreciate if folks could read through the whole thing and


give comments over email and through Github issues.  Please also


submit PRs for typos and other wording improvements.





I'd like to try and settle most concerns over email if possible, and


assume it'll take a little while for everyone to go through the doc.





I'll tentatively schedule a vector TG meeting on Friday June 25 to go


over issues best dealt with on a call.  I'm hoping we can enter public


review at the same point in time.  Remember, we don't have to reach


agreement on all the issues before starting public review, just be OK


as a group with putting this out for public review.





Krste

-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación

WARNING / LEGAL TEXT: This message is intended only for the

use of theindividual or entity to which it is addressed and

may containinformation which is privileged, confidential,

proprietary, or exemptfrom disclosure under applicable law. If

you are not the intendedrecipient or the person responsible

for delivering the message to theintended recipient, you are

strictly prohibited from disclosing,distributing, copying, or

in any way using this message. If you havereceived this

communication in error, please notify the sender anddestroy

and delete any copies you may have received.





http://www.bsc.es/disclaimer

-- 

Roger Ferrer Ibáñez - roger.ferrer@...

Barcelona Supercomputing Center - Centro Nacional de Supercomputación

-- 

Roger Ferrer Ibáñez - roger.ferrer@...

Barcelona Supercomputing Center - Centro Nacional de Supercomputación

Hi,

I didn't realise this was the private list and Romain is not in this one. So I'm forwarding his answer on his behalf

There's some sample codes to emulate SVE/NEON-like instructions using the historical EPI intrinsics (should be mostly self-explanatory, Roger will definitely know them ) here:

<https://github.com/rdolbeau/EPI-test-codes-vector/blob/master/simplefft16-rvv/vf64.h>

Other subdirectories of the same repo includes integer variants.

Not all functions might work for non-power-of-two length, but they can be a starting point for some useful pattern.

Cordially,

Hope this helps.

Kind regards,

On 15/6/21 9:08, Roger Ferrer Ibanez wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the scalar to subtract
  
• zip is harder: start with the "halved indexes" vid + vsrl.vi (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements" vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a power of two, shift) with the first index of the second vector (which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2, 0, vl/2, .... Then add this vector to the halved indexes so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
  
• unzip worst of the cases you can reverse what you did for zip
  
• trn I don't have any ideas from the top of my head, /cc Romain Dolbeau who may recall how he worked around the cases in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via lists.riscv.org wrote:

Dear  Craig and Roger,

     ​    ​Thanks a lot for providing  me  good solution. I have tried them,  they are all good solutions of  upsample application.

    ​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards

Damon Yu

------------------原始邮件 ------------------

发件人: <tech-vector-ext@...>

发送时间:06/11/21 18:51:12

收件人: <tech-vector-ext@...>

主题:Re: 回复：[RISC-V] [tech-vector-ext] RISC-V Vector Spec version 1.0-rc1-20210608

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and you don't have to load a materialised value from memory (you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via lists.riscv.org wrote:

Hi, all

    I encountered a difficulty of applying  "vrgather" instruction recently.  The details are shown blow:

    The date from source should be duplicated as pair in a upsample application. 

     Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]

           dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8]

     So, my relazation is:

--------------------------------------------------------------------------------------------------

  int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 ........，31，31}；// to be compatibled of all the VLEN(128 ~ 1024)

   vfloat32m2_t data = vundefined_f32m2();

    vfloat32m1_t  zero = ( vfloat32m1_t )vmv_v_i_i32m1(0);

   while(length >0)

    {

         int gvl = vsetvl_e32m1(length);

        vuint32m2_t v_index = vle32_v_u32m2(index, gvl);

         vfloat32m1_t src_data = vle32_v_f32m1(src, gvl);

         data = vset_f32m2(data, src_data, 0);

         data  = vset_f32m2(data, zero, 1);

         vfloat32m2_t res = vrrgather_vv_f32m2(data, v_index, gvl);  

         length -=gvl;

         src += gvl;

        vse32_v_f32m2(out, res, gvl);

        dst +=gvl;

    }

-----------------------------------------------------------------------------------------------   

    As shown before, the index data should be  initialized as the max VLEN to make the code  compatibled.

So do all the applications, that need a constant.

    I think it is contrary to the idea of RISC-V, that one code can run on all the RISC-V hardware.  Does anyone have a better method ? 

Best Regards

Damon Yu

------------------原始邮件 ------------------

发件人: <tech-vector-ext@...>

发送时间:06/09/21 14:46:30

收件人: <tech-vector-ext@...>

主题:[RISC-V] [tech-vector-ext] RISC-V Vector Spec version 1.0-rc1-20210608

I've just tagged the first release candidate for v1.0 of the vector
spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and
give comments over email and through Github issues.  Please also
submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call.  I'm hoping we can enter public
review at the same point in time.  Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.

Krste

-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación

WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged, confidential, proprietary, or exemptfrom disclosure under applicable law. If you are not the intendedrecipient or the person responsible for delivering the message to theintended recipient, you are strictly prohibited from disclosing,distributing, copying, or in any way using this message. If you havereceived this communication in error, please notify the sender anddestroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

-- 
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación

-- 
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most

efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the
  
  scalar to subtract
  
  
  



• zip is harder: start with the "halved indexes" vid + vsrl.vi
  
  (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements"
  
  vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a
  
  power of two, shift) with the first index of the second vector
  
  (which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2,
  
  0, vl/2, .... Then add this vector to the halved indexes so you
  
  get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
  
  
  



• unzip worst of the cases you can reverse what you did for zip
  
  
  



• trn I don't have any ideas from the top of my head, /cc Romain
  
  Dolbeau who may recall how he worked around the cases in FFTW
  
  where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via

lists.riscv.org wrote:

Dear  Craig and Roger,

     ​    ​Thanks a lot for providing  me  good

solution. I have tried them,  they are all good solutions of 

upsample application.

    ​    ​ But, when it comes to other applications, such  as zip/unzip,

trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards

Damon Yu

------------------原始邮件

------------------

发件人: <tech-vector-ext@...>

发送时间:06/11/21 18:51:12

收件人: <tech-vector-ext@...>

主题:Re: 回复：[RISC-V] [tech-vector-ext] RISC-V Vector

Spec version 1.0-rc1-20210608

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you

(logical) shift right 1 bit (vsrl.vi)

would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and

you don't have to load a materialised value from memory (you

compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via

lists.riscv.org wrote:

Hi, all

    I encountered a difficulty of applying

 "vrgather" instruction recently.  The details are shown blow:

    The date from source should be duplicated as pair

in a upsample application. 

     Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]

           dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5,

5, 6, 6, 7, 7, 8, 8]

     So, my relazation is:

--------------------------------------------------------------------------------------------------

  int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5

........，31，31}；// to be compatibled of all the VLEN(128

~ 1024)

   vfloat32m2_t data = vundefined_f32m2();

    vfloat32m1_t  zero =

( vfloat32m1_t )vmv_v_i_i32m1(0);

   while(length >0)

    {

         int gvl = vsetvl_e32m1(length);

        vuint32m2_t v_index = vle32_v_u32m2(index,

gvl);

         vfloat32m1_t src_data = vle32_v_f32m1(src,

gvl);

         data = vset_f32m2(data, src_data, 0);

         data  = vset_f32m2(data, zero, 1);

         vfloat32m2_t res =

vrrgather_vv_f32m2(data, v_index, gvl);  

         length -=gvl;

         src += gvl;

        vse32_v_f32m2(out, res, gvl);

        dst +=gvl;

    }

-----------------------------------------------------------------------------------------------

  

    As shown before, the index data should be

 initialized as the max VLEN to make the code  compatibled.

So do all the

applications, that need a constant.

    I think it is

contrary to the idea of RISC-V, that one code can run

on all the RISC-V hardware.  Does anyone have a better

method ? 

Best Regards

Damon Yu

------------------原始邮件

------------------

发件人: <tech-vector-ext@...>

发送时间:06/09/21 14:46:30

收件人: <tech-vector-ext@...>

主题:[RISC-V] [tech-vector-ext] RISC-V Vector Spec

version 1.0-rc1-20210608

I've just tagged the first release candidate for v1.0 of the vector


spec in github.  PDF attached below.





I've included the TG agreed updates and handled almost all of the


outstanding issues for v1.0.  Thanks for all the feedback.





I would appreciate if folks could read through the whole thing and


give comments over email and through Github issues.  Please also


submit PRs for typos and other wording improvements.





I'd like to try and settle most concerns over email if possible, and


assume it'll take a little while for everyone to go through the doc.





I'll tentatively schedule a vector TG meeting on Friday June 25 to go


over issues best dealt with on a call.  I'm hoping we can enter public


review at the same point in time.  Remember, we don't have to reach


agreement on all the issues before starting public review, just be OK


as a group with putting this out for public review.





Krste

-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación

WARNING / LEGAL TEXT: This message is intended only for the use

of theindividual or entity to which it is addressed and may

containinformation which is privileged, confidential,

proprietary, or exemptfrom disclosure under applicable law. If

you are not the intendedrecipient or the person responsible for

delivering the message to theintended recipient, you are

strictly prohibited from disclosing,distributing, copying, or in

any way using this message. If you havereceived this

communication in error, please notify the sender anddestroy and

delete any copies you may have received.





http://www.bsc.es/disclaimer

-- 

Roger Ferrer Ibáñez - roger.ferrer@...

Barcelona Supercomputing Center - Centro Nacional de Supercomputación

Software should still work with VLEN>=64 if written correctly, as it should be VLEN agnostic.
Maybe it should be a recommendation that VLEN>=128, with a minimum of 64 for app processors?

Lower performance is an implementation cost/benefit decision.

Tony

-----Original Message-----
From: tech-vector-ext@... [mailto:tech-vector-ext@...] On Behalf Of Krste Asanovic
Sent: 03 June 2021 17:24
To: Guy Lemieux <guy.lemieux@...>
Cc: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>; Shaofei (B) <shaofei1@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] Smaller embedded version of the Vector extension



> On Jun 3, 2021, at 9:16 AM, Guy Lemieux <guy.lemieux@...> wrote:
>
> What is the advantage to RVV requiring VLEN >= 128?
>
> I think this should be changed to VLEN >= 64 because:
>
> 1) VLEN = 64 is more likely for small implementations; creating a
> mandatory expectation to improve software portability

This is the requirement for app processors, which are not generally small cores.
Most competing SIMD extensions are at least 128b per vector register.

>
> 2) two implementations, each with VLEN >= 64, do not expose anything
> new to software that is not already exposed by VLEN >= 128
>
> 3) allowing VLEN =32 would expose something new to software (register
> file data layout when SEW=64)
>
> 4) are there any disadvantages to VLEN >= 64 (versus the current VLEN
>> = 128)? (I can't see any)

Lower performance on codes that work well on other app architectures.

Krste

>
> Guy
>
>
> On Wed, Jun 2, 2021 at 11:13 AM <krste@...> wrote:
>>
>>
>> The VLEN>=128 constraint is only for the application processor "V"
>> extension for the app profile - not for embedded vectors which can
>> have VLEN=32.
>>
>> From spec Introduction:
>> '
>> The term base vector extension is used informally to describe the standard set of vector ISA components that will be required for the single-letter "V" extension, which is intended for use in standard server and application-processor platform profiles. The set of mandatory instructions and supported element widths will vary with the base ISA (RV32I, RV64I) as described below.
>>
>> Other profiles, including embedded profiles, may choose to mandate only subsets of these extensions. The exact set of mandatory supported instructions for an implementation to be compliant with a given profile will only be determined when each profile spec is ratified. For convenience in defining subset profiles, vector instruction subsets are given ISA string names beginning with the "Zv" prefix.
>> '
>>
>> There are a set Zve* names for the embedded subsets (see github issue
>> #550).
>>
>> A minimal embedded implementaton using RV32E+Zfinx+vectors would be
>> same state size as ARM MVE.
>>
>> P extension does not have floating-point, but for short
>> integer/fixed-point SIMD makes sense as alternative.
>>
>> The software fragmentation issue is that some library routines that
>> expose VLEN might not be portable between app cores and embedded
>> cores, but these are different software ecosystems (e.g. ABI/calling
>> convention might be different) and only a few kinds of routine rely
>> on VLEN.
>>
>> For app cores that can afford VLEN>=128, the advantage is the removal
>> of stripmining code in cases that operate on fixed-size vectors.
>>
>> Krste
>>
>>
>>
>>>>>>> On Wed, 2 Jun 2021 05:10:32 -0700, "Guy Lemieux" <guy.lemieux@...> said:
>>
>> | Allowing VLEN<128 would allow for smaller vector register files,
>> | bit it would also result in a profile that is not
>> | forward-compatible with the V spec. This would produce another fracture the software ecosystem.
>>
>> | To avoid such a fracture, there are two choices:
>> | (1) go with P instead
>> | (2) relax the V spec to allow smaller implementations
>>
>> | So the key question for this group is whether to relax the minimum
>> | VLEN to 32 or 64?
>>
>> | note: a possible justification for keeping 128 might be to
>> | recommend (1) instead. I don’t know anything about P, but it seems
>> | like it could be speced in a way that is competitive/comparable with Helium.
>>
>> | Guy
>>
>> | PS — I have started to design an “RVV-lite” profile which would be
>> | more amenable to embedded implementations. However, I have adopted
>> | a stance that it must remain forward compatible with the full V
>> | spec, so I have not considered VLEN below 128. I am happy to share
>> | my work on this and involve other contributors — email me if you would like to see a copy.
>>
>> | On Wed, Jun 2, 2021 at 3:15 AM Andrew Waterman <andrew@...> wrote:
>>
>> |     The uppercase-V V extension is meant to cater to apps processors, where
>> |     the VLEN >= 128 constraint is not inappropriate and is sometimes
>> |     beneficial.  But there's nothing fundamental about the ISA design that
>> |     prohibits VLEN < 128.  A minimal configuration is VLEN=ELEN=32, giving the
>> |     same total amount of state as MVE.  (And if you set LMUL=4, then you even
>> |     get the same shape: 8 registers of 128 bits apiece.)
>>
>> |     Such a thing wouldn't be called V, but perhaps something like Zvmin.
>> |     Other than agreeing on a feature set and assigning it a name, the
>> |     architecting is already done.
>>
>> |     (If you search the spec for Zfinx, you'll see that a Zfinx variant is
>> |     planned, but only barely sketched out.)
>>
>> |     On Wed, Jun 2, 2021 at 3:04 AM Tariq Kurd via lists.riscv.org <tariq.kurd=
>> |     huawei.com@...> wrote:
>>
>> |         Hi everyone,
>>
>> |
>>
>> |         Are there any plans for a cut-down configuration of the vector
>> |         extension suitable for embedded cores? It seems that the 32x128-bit
>> |         register file is suitable for application class cores but it very
>> |         large for embedded cores, especially if
>>
>> |         the F registers also need to be implemented (which I think is the
>> |         case, unless a Zfinx version is specified).
>>
>> |
>>
>> |         ARM MVE only has 8x128-bit registers for FP and Vector, so it much
>> |         more suitable for embedded applications.
>>
>> |         https://en.wikichip.org/wiki/arm/helium
>>
>> |
>>
>> |         What’s the approach here? Should embedded applications implement the
>> |         P-extension instead?
>>
>> |
>>
>> |         Tariq
>>
>> |
>>
>> |         Tariq Kurd
>>
>> |         Processor Design
>>
>> |         I RISC-V Cores, Bristol
>>
>> |         E-mail:
>>
>> |         Tariq.Kurd@...
>>
>> |         Company:
>>
>> |         Huawei technologies R&D (UK) Ltd
>>
>> |         I Address: 290
>>
>> |         Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32
>> |         4TR, UK
>>
>> |
>>
>> |         315px-Huawei
>>
>> |         http://www.huawei.com
>>
>> |         cid:image002.jpg@...
>>
>> |         This e-mail and its attachments contain confidential information from
>> |         HUAWEI, which
>>
>> |         is intended only for the person or entity whose address is listed
>> |         above. Any use of the information contained herein in any way
>> |         (including, but not limited to, total or partial
>> |         disclosure,reproduction, or dissemination) by persons other than the
>> |         intended recipient(s)
>>
>> |         is prohibited. If you receive this e-mail in error, please notify the
>> |         sender by phone or email immediately and delete it !
>>
>> |         本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人
>> |         或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复
>> |         制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知
>> |         发件人并删除本邮件！
>>
>> |
>>
>> |
>> | x[DELETED ATTACHMENT image001.png, PNG image] x[DELETED ATTACHMENT
>> | image002.jpg, JPEG image]