Please help me correct or fix my code !!

Hello Everyone!,

I would really apricate it if you could help me correct the code below to shift a 24 Bit (6 hex char '6BB92C000000') within a 64 bit register '00006BB92C000000''. Notes that I have already offset it the hex char with 2^24 ..i.e Multiplied (''6BB92C) * 2^24.

I'm tryiing to shift this register with the following values : '05', 'F1','07','1A', '2A', and 'EA', any Idea how to get a result without overflow the conversion ? or getting an error or a warning message when I tried the negative hex values ? I know for a fact that, MATLAB dose not support conversion for any bit higher than 53. Also . I know the arithmetic shift of a binary numbers ( Left shift Multiply by 2^nShift & for the Right shift we divide by 2^nShift), any ideas?. I have also tried to convert the Fraction-floting point to decimal & Binarry, and still dese not giving me the correct answer. Thank you and I appreciate your help.

hex= '6BB92C';

hexi2Decimal= hex2dec(hex); % Hexal in Decimal

zeroOffset=dec2hex(hexi2Decimal*2^24) % Offest with 24 zeros to the left

zeroOffsetinBin=dec2bin(hex2dec(zeroOffset)); % Offest with 24 zeros to the left in Binary

zeroShiftinDeca=hex2dec(zeroOffset);

nShift=hex2dec('05') % Number of Shift in hex or dec

ShiftedHexinDecimal= hex2dec(zeroOffset)*2^nShift;

finalShiftedRegister=dec2hex(ShiftedHexinDecimal) % Final shiffted register

ShiftedHexinBin=dec2bin(ShiftedHexinDecimal);

% MATLAB Built-in function for bitshift

BitShift=dec2hex(bitshift(zeroShiftinDeca,nShift))

Answer 1

[Walter Roberson]

Use uint64. You can use bitxor, bitand, bitor, bitshift.

If you have an input value expressed in hex, then sscanf with %lx format can read up to 16 nibbles as uint64

[Irwin2020]

Walter, I really appreciate your comment. I have already tried the bitshift , and it gave me an error. I'll enforce the 'uint64' datatype on all of the conversions. as far as the sscanf ; I have used similar way to extract the desierd binarry vector , and simplly I used extractBefore(ShiftedHexininBin, 25)

[Walter Roberson]

extractBefore leaves the values as character, which does not work for bit shifts.

[Irwin2020]

So just correct me if I'm wrong, to do right shift , arithmetically you divide by 2^nShift , and for the big values right- shift ( two Hex char ) 'AD', 'C8' , and any Hex char combination , you would subtract those values from 'FF'?

[Walter Roberson]

once you have converted the hex to unsigned integer, then use bitshift and similar. The reason not to just divide by 2^shift is uint8 operations are defined as uint8(operation(double(operands)) and converting double to uint8 is by rounding not truncation. For example uint8(3)/uint8(2) is uint8(double(uint8(3))/double(uint8(2))) which is uint8(1.5) which is uint8(2), whereas bitshift would produce uint8(1)

I am not sure of the context for the subtraction you are discussing? Are you talking about how to do two's complement arithmetic? Or are you asking about signed shift?

[Irwin2020]

I’m not referring to the two’s complement( invert and add one) nor I’m using truncation and simply I don’t wanna lose any data precision, I’m talking about the signed-shift, and particularly the right shift . I’m assuming we have negative “-“ MSB : ‘EBB9C3’, and when shifting it to the right by “F0” , we could subtract it from “FF” i.e ‘FF’ - ‘F0’ = 15 and then we simply do:

hex2dec(‘EBB9C3’)/2^15 ?

 Or

rShift =floor(hex2dec(‘EBB9C3’))*(2^-15)) ?? Dose this clarify my context ?

[Walter Roberson]

When you indicate that F0 should correspond to -15 then that implies that FF should correspond to -0 with 00 corresponding to +0. Systems that have both a negative and positive zero are either One's Complement or else Separate Sign. You appear to be using One's Complement.

Is this correct? If it is then one of the implications is that FF + 01 would be 01 since FF would correspond to 0. In the One's Complement system you need to make an adjustment when the calculation crosses 0 in either direction, which is not something that has to be done with Two's Complement.

Does your system require division? The major practical difference between systems that have signed zero or not is that in systems with signed zero then division by 0 gives sign(numerator)*sign(the zero) *infinity so for example -5/-0 gives +infinity. Whereas when zero is unsigned the result is sign(numerator)*infinity

[Irwin2020]

Thanks for your comments. I’m using One’s Complement only if needed and my system doesn’t require a division, simply I'm trying to avoid any division that involves in my calculations, because it makes thing more complicated. Also , I’m aware of the signed zero implications, all I wanted is that , to bypass the 53 bit issue with MATLAB, specially when we divide and do dec2hex. I picked ‘F0’ as an arbitrary value. all I wanted is to shift left - right without getting any warning or error message by using MATLAB built in functions in my code.

[Walter Roberson]

> sprintf('%016x', 0x6BB92C000000)

ans =
    '00006bb92c000000'
    

That is, instead of using dec2hex, use sprintf() . And sscanf() for the reverse.

    >> sscanf('00006bb92c000000', '%lx')
ans =
  uint64
   118443051319296

You can also safely use dec2bin() on int64() and uint64() [at least in the most recent versions], but bin2dec requires special care:

   >> S='11010111011100100101100000000000000000000000001';
   >> bin2dec(['0b' S 'u64'])
   ans =
           118443051319297

The ability to use 0b prefix and type suffixes in MATLAB is pretty new.

For older releases, I would reshape the binary to groups of 8, bin2dec(), uint8(), and typecast() to uint64 (but I would double-check that the desired byte order was used; you might need to swapbytes())