[SOLVED] how bits are arranged in memory, so that they would make sense ?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
[low address] actual memory represention of bits from low add to high address [high address]
the way you write that makes it hard to read and understand, because it's so unusual.
Quote:
Originally Posted by ununun
1] is [high add] 00100110 [low add] = 38_dec ?
Yes, that's 26 hex or 38 decimal.
Low and high address makes no sense here, because that seems to be *one* byte. A byte is always stored in *one* memory location, so only *one* address.
Quote:
Originally Posted by ununun
2] is [high add] 00100110 [low add] = 68_dec ?
No. That's still the same bit pattern. How would you get 68 decimal, which is 44 hex?
In a way, yes. But bear in mind that -opposed to the previous samples- two bytes do actually occupy two memory locations, two addresses. But they aren't necessarily stored in memory in the order you wrote them down.
Actually, Intel CPUs and their compatible counterparts store the low byte in the lower memory address, the high byte in the higher address. Some Motorola CPUs, however, do it the other way round. That's why it can be troublesome to exchange binary data among different computer systems.
Quote:
Originally Posted by ununun
Code:
$ echo "A" > f && xxd -b f
0000000: 01000001 00001010
Yes. Letter 'A' has the code 41 hex, that's the first byte you see, and the implicitly added linefeed has code 0A hex, that's the second byte.
First of all, even though the traditional individually-accessible unit of storage is an 8-bit byte, many of the values that are stored are larger ... 16 bits, 32, 64, or even 128 bits. (It is also often the case that the memory-addresses used are a multiple of the number of bytes necessary to store the value ... a 4-byte value being stored on an address that is a multiple of 4 and so on.)
There is nothing about "a block of memory" that tells you how the bytes stored there "should" be interpreted. It's simply the case that, when the processor is asked to load a value of some-size from some-address, it interprets the range of bytes that it fetches in some way. And, this interpretation is processor-dependent.
Intel processors traditionally used so-called "little-endian" notation: the "least significant byte" is stored first.
Motorola processors traditionally used so-called "big-endian" notation: the "most significant byte" is stored first.
In most processors, the most-significant bit in each byte is the leftmost bit.
But, once again, "there is no pre-set interpretation." When the processor is instructed to fetch X bytes from address Y, and to interpret those bytes as (whatever...), it does so, or else it promptly dies trying.
It's still the very same bit pattern, so: Yes, see above.
The "high add" and "low add" tags make the meaning clear, assuming an LSB architecture such as X86 . It is 2600 hex, not 26 hex, so 9728 dec.
Quote:
Originally Posted by ununun
actual memory represention
"actual" is a tricky word there. There is a lot of parallelism as well as remapping in the actual implementation. There is no fundamental bit level (nor even byte level) serialization of memory. LSB architectures act as if there is a fundamental continuous sequence from least significant bit at lowest address through most significant at highest address. But what is actually physically present is a more complicated question.
Quote:
Originally Posted by sundialsvcs
In most processors, the most-significant bit in each byte is the leftmost bit.
Is that stage left or the audience's left?
Left and Right are meaningless when you are talking about bits within a processor or bits in memory.
In most processors that have some instruction that explicitly or implicitly defines numbering of bits within a byte, the most significant bit is usually the highest numbered bit. But that is not universally true. There are processors numbering both bits within a byte and bytes within a larger element from least to most. There are processors numbering bits within a byte from least to most but bytes within a larger value from most to least (always struck me as flawed design). There are processors numbering both bits within a byte and bytes within a larger element from most to least.
In English (and many related languages) we use a a left to right numbering system together with what was originally a right to left, least significant digit first numbering system. Having those together for so long has led to treating the numbering as left to right, most significant first (which looks exactly the same on paper and only differs in your mind).
But all of those are just conventions of writing. Too many people have inflexible minds and think left to right fundamentally connects to first to last, and indirectly from that think most significant digit written on the left and most significant digit first are connected and equally fundamental.
None of those connections are fundamental: Left isn't fundamentally first. Left isn't fundamentally most significant. Most significant isn't fundamentally first.
Those notions can lead to real confusion when you try to misuse left and right as fundamentally meaningful within computer storage.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.