[U-Boot-Users] Spartan FPGA patch

[Aggelos Manousarides]

Wolfgang Denk wrote:
> In message <4731ECA0.1010502 at schweigstill.de> you wrote:
>> Wolfgang Denk schrieb:
>>> Oops? I can't parse that. What's the difference between "signed char"
>>> and "int" except the number of bits?
>> Like mentioned before, accessing data via a (signed|unsigned|.) char *
>> is independant of the processor endianess. If you want to read a
> 
> Correct. And storing the result in an "int" type is independent of the
> byte order as well,if you do it right.
> 
>> bitstream which is bytewise formatted you don't want to care about
>> endianess. Or do you also want some endianess string definitions?
> 
> What has this to do with what we're discussing?
> 
>> And it is even worse; on some architectures, like ARM, it is not
>> allowed to do a 16/32 bit memory access on a non-aligned address,
>> e.g.:
> 
> Nobody intended to do that.
> 
>> int val;
>> int * p_data;
> 
> STOP!  I asked why we cannot change "val" into an "int". I never said
> anything about using an "int *" to access to buffer data.
> 

This is the main misunderstanding. When you said "int" I though you 
meant dereferencing an "int *", in fact not only me but other people on 
the list as well. So your proposal is to convert the "char val" to an 
"int val". You don't solve the problem I mentioned by doing this.

This is the current code:

*********************
unsigned char *data = ...;
char val;
int i;

...

val = data [bytecount ++];
i = 8;
do {
    ...
    write(..., (val < 0), ...);
    ...
    val <<= 1;
    i--
} while (i > 0);

*********************

Let us not forget that all we want to do here is take the *bits* of the 
buffer one by one, starting from the MSB. Checking for negativity is 
just a hack to acquire the MSB, since signed values are two's complement.

This code works on all platforms in which "char" defaults to "signed 
char", because storing a byte from an "unsigned char *" to a "char" will 
implicitly convert it to a negative value. On ARM, this fails, becuase 
"char" is also "unsigned char", thus "val<0" is always zero.

Your proposed solution also fails. Just converting the "char val" to an 
"int val", will never produce a negative value in any architecture. This 
integer will always be positive.

To avoid a new series of misunderstandings, you said "if you do it 
right" when you talked about the "int". This could be interpreted as 
some kind of cast so that the "int val" is negative on all 
architectures, but I fail to see how this is cleaner than converting the 
val to "unsigned char" like the "data" and doing "val & 0x80".

--
Angelos Manousaridis