daniel tian <daniel.xnt...@gmail.com> writes: > I am porting gcc to a 32bit RISC chip, and I met a logical > error with 16bit arithmetic operations in generating assemble code. > the error is between two 16bit data movement(unsigned short). > While like A = B, A, and B are all unsigned short type. B is a > result of a series of computation, which may have value in high 16bit. > Because A , B are both HImode, so the move insn doesn't take zero > extend operation, so A will have value in high 16bit which will caused > a wrong result in computation.
The relevant types in your code are "unsigned short". I assume that on your processor that is a 16 bit type. An variable of an unsigned 16 bit type can hold values from 0 to 0xffff, inclusive. There is nothing wrong with having the high bit be set in such a variable. It just means that the value is between 0x8000 and 0xffff. > ;; 1--> 23 R5=R6 0>>0xc :nothing > //R5 and R6 are both unsigned short type. But R6 will > have it's value in high 16bit because of series of logical operations > (AND, OR, XOR and so on). Doing it like this way will cause R5 also > being valued in high 16bit. This will cause a wrong value. The correct > one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn >>From R6. But How I let gcc know it. No. 0>> means a logical right shift, not an arithmetic right shift (LSHIFTRT rathre than ASHIFTRT). When doing a logical right shift, the sign bit is moved right also; it is not sticky. This instruction is fine. Perhaps there is a problem in your implementation of LSHIFTRT. Ian
