In TVM's whitepaper, we got this in Chapter 3.2.8: > Integers in cells are big-endian by default. > Notice that the default order of bits in Integer s serialized into Cells is big-endian, not littleendian.14 In this respect TVM is a big-endian machine. However, this affects only the serialization of integers inside cells. The internal representation of the Integer value type is implementation-dependent and irrelevant for the operation of TVM. Besides, there are some special primitives such as STULE for (de)serializing little-endian integers, which must be stored into an integral number of bytes (otherwise “little-endianness” does not make sense, unless one is also willing to revert the order of bits inside octets). Such primitives are useful for interfacing with the little-endian world—for instance, for parsing custom-format messages arriving to a TON Blockchain smart contract from the outside world. Please share with me what is thatm and why it's important Reference: https://docs.ton.org/tvm.pdf

In TVM's whitepaper, we got this in Chapter 3.2.8: > Integers in cells are big-endian by default. > Notice that the default order of bits in Integer s serialized into Cells is big-endian, not littleendian.14 In this respect TVM is a big-endian machine. However, this affects only the serialization of integers inside cells. The internal representation of the Integer value type is implementation-dependent and irrelevant for the operation of TVM. Besides, there are some special primitives such as STULE for (de)serializing little-endian integers, which must be stored into an integral number of bytes (otherwise “little-endianness” does not make sense, unless one is also willing to revert the order of bits inside octets). Such primitives are useful for interfacing with the little-endian world—for instance, for parsing custom-format messages arriving to a TON Blockchain smart contract from the outside world. Please share with me what is thatm and why it's impor