tempInt16 := Int16((byte1 shl 8) + byte2);
200*256+255=51455, which is greater than 32767 :)
200*256+255=51455, which is greater than 32767 :)
But this is what I don't understand. 200 > 127, so the sign bit is 1. Thus, as the two bytes represent a signed int, I should get a negative value: -14081
But my clarification that the two bytes represent a signed, not an unsigned int is ignored. :-\
type
Tbytes2int16 = packed record
case integer of
0: (byte2, byte1 : Byte);
1: (tempInt16 : Int16);
end;
But beware of endianness issues.
When byte1 is greater than 127 (decimal) the expressionis too large to fit in a signed 16 bit integer, and so the compiler warns you of that fact if range checks are enabled.
It is as simple as that.
has no chance to get the endianness wrong.
has no chance to get the endianness wrong.
...but it depends on whether your intention is to combine bytes and words (which do not necessarily represent specific numbers) or to combine numbers using arithmetic/logical operations. The distinction is obviously subtle, but is very much relevant when one is tinkering with e.g. CPU simulation.
MarkMLl
@MarkMLI, I honestly confess, I didn't get you. The Muso's intent was to combine two bytes in a signed word (Int16). What do you mean by making the 'subtle' distinction between combining bytes/words and combining numbers? Can you please explain.
What is a byte? The industry has eventually agreed that's it's an eight-bit "octet", and that a word is sixteen bits, but those aren't necessarily numbers.Actually, they are whole numbers in a specific range. At a certain level of abstraction, you can consider them as a domain of bijection to another (finite) set, e.g. characters, enums, floats, etc.
If you want to concatenate two bytes into a word, with absolutely no interpretation, then you use a variant record and are careful about endianness.Concatenation means there is interpretation. That is why the endianness is important.
If you want to assemble 16 bits in memory from two 8-bit quantities then you use a shift and an "or" operation.You are utmost correct. But since we know well that the addition (the adder) is an "or" combined with a "xor" for the carry-bit to the next cell, and also, the SHL operation (same instruction) fills with zeroes on the right, we're quite sure that "+" works the same way as the "or" and there will be no carry-bit from the low byte.
If you want to merge two numbers of a certain "bitedness" into one with a larger "bitedness", then you use multiplication and addition. But you'd better be damned sure of the representation convention, and be prepared to take sign into consideration.Quite correct again. But we also know that SHL/SHR are ignoring the signednness of the item, which is not relevant in the case when we're working with unsigned variables, and then they behaves just like multiplication/division by the power of two. This is our particular case (variables of type 'byte').
Now, if we go back to @Muso's OP. "Two bytes"... but are those signed or unsigned? A byte isn't (necesarliy) a number. "Into a signed word"... but that's unambiguously a number.IMO, The Muso wants to transfer some signed words through a communication link, but I can't be absolutely sure from his writings.
So it really boils down to what one knows about the source values, and what one requires from the result.
w=51455; i=-18687