LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This 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


Reply
  Search this Thread
Old 11-04-2011, 01:09 PM   #1
ununun
Member
 
Registered: Jun 2011
Posts: 82

Rep: Reputation: Disabled
how bits are arranged in memory, so that they would make sense ?


[low address] actual memory represention of bits from low add to high address [high address]

1] is [high add] 00100110 [low add] = 38_dec ?

2] is [high add] 00100110 [low add] = 68_dec ?

3] is [high add] 00100110 00000000 [low add] = hex(38_dec) = 26_hex ?

4] is [high add] 00100110 00000000 [low add] = hex(9728_dec) = 2200_hex ?

Code:
$ echo "A" > f && xxd -b f
0000000: 01000001 00001010
5] is f.data = [high add] 00001010 01000001 [low add] ?

6] is f.data = [high add] 01000001 00001010 [low add] ?

yes/no would be enough but extra info is appreciated.

thanks
 
Old 11-04-2011, 01:56 PM   #2
Doc CPU
Senior Member
 
Registered: Jun 2011
Location: Stuttgart, Germany
Distribution: Mint, Debian, Gentoo, Win 2k/XP
Posts: 1,099

Rep: Reputation: 344Reputation: 344Reputation: 344Reputation: 344
Hi there,

Quote:
Originally Posted by ununun View Post
[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 View Post
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 View Post
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?

Quote:
Originally Posted by ununun View Post
3] is [high add] 00100110 00000000 [low add] = hex(38_dec) = 26_hex ?
It's still the very same bit pattern, so: Yes, see above.

Quote:
Originally Posted by ununun View Post
4] is [high add] 00100110 00000000 [low add] = hex(9728_dec) = 2200_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 View Post
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.

Quote:
Originally Posted by ununun View Post
5] is f.data = [high add] 00001010 01000001 [low add] ?
6] is f.data = [high add] 01000001 00001010 [low add] ?
That depends. See explanation of sample 4. On a PC, [5] would be true.

[X] Doc CPU
 
1 members found this post helpful.
Old 11-04-2011, 02:50 PM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,599
Blog Entries: 4

Rep: Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905
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.
 
Old 11-04-2011, 03:19 PM   #4
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
Quote:
Originally Posted by ununun View Post
3] is [high add] 00100110 00000000 [low add] = hex(38_dec) = 26_hex ?

Quote:
Originally Posted by Doc CPU View Post
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 View Post
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 View Post
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.

Last edited by johnsfine; 11-04-2011 at 03:35 PM.
 
Old 11-04-2011, 03:48 PM   #5
Doc CPU
Senior Member
 
Registered: Jun 2011
Location: Stuttgart, Germany
Distribution: Mint, Debian, Gentoo, Win 2k/XP
Posts: 1,099

Rep: Reputation: 344Reputation: 344Reputation: 344Reputation: 344
Hi there,

Quote:
Originally Posted by johnsfine View Post
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.
erm, yes ... Looks like I totally missed the fact that there were now two bytes. Given that, I stand corrected. :-)

[X] Doc CPU
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the meaning of 32 bits x 16 bits in a flash memory? archieval Linux - Embedded & Single-board computer 4 05-25-2011 02:37 PM
This just doesn't make any sense! FreezEy Debian 8 04-18-2006 08:35 PM
How does this make sense? Trinity22 Linux - General 2 03-30-2005 12:45 AM
Does this make sense? (RPM Q:) admstng Mandriva 4 12-30-2004 07:49 AM
Ya sure this make sense Edward78 General 2 09-23-2003 03:00 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 09:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration