why does 0000:0010 == 0001:0000
Author
Hi, Why I'm reading a chapter in an asm tutorial that explains mem segmentation in real mode. The author is saying that segments overlap and gives this as an example, 0000:0010 same as -> 0001:0000.
Also this " 0000:0010 = 0*16 + 1*16 " i get this part,
but then he goes on 0001:0000: (16 * 1 + 16*0 = 16 + 0 = 16)
I don't get why 0001 == 1*16, doesn't the first bit correspond to 16^0,
so isouldn't it be 1 (16^0 * 1 = 1). Thanks.
It's "address = segment * page size + offset" where in "0000:1111" 0000 is the segment and 1111 is the offset. In this case page size is 16, or 0x10 hex.
Basically it's a waste of the 12 bits that overlap:
0000:0010 = (0 * 16 + 0x10) = 0x10
0001:0000 = (1 * 16 + 0) = 0x10
0001:0002 = (1 * 16 + 2) = 0x12
0001:0200 = (1 * 16 + 0x200) = 0x210
Basically it's a waste of the 12 bits that overlap:
0000:0010 = (0 * 16 + 0x10) = 0x10
0001:0000 = (1 * 16 + 0) = 0x10
0001:0002 = (1 * 16 + 2) = 0x12
0001:0200 = (1 * 16 + 0x200) = 0x210
In the segment:offset model, each segment is a 16bit value. We
always multiply the current segment number by 16 (and add it to offset)
to get the absolute address.
ie:
In your first example, 0000:0010, we multiply using the above formula:
For 0001:0000:
Hence, 0001:0000 = 0000:0010.
The basic idea is to always multiple segment by 16. In the above,
the values given for offset is just the converstion from hex to int
(Which is what you were doing)
This is the way I learned it, anyway [smile]
Hope this helps!
always multiply the current segment number by 16 (and add it to offset)
to get the absolute address.
ie:
segment:offset = segment*16 + offset = absolute addressIn your first example, 0000:0010, we multiply using the above formula:
segment offset absolute address0*16=0 + 0*16 + 1*16 = 16For 0001:0000:
segment offset absolute address1*16 + 0*16 = 16Hence, 0001:0000 = 0000:0010.
The basic idea is to always multiple segment by 16. In the above,
the values given for offset is just the converstion from hex to int
(Which is what you were doing)
This is the way I learned it, anyway [smile]
Hope this helps!
Author
If relying purely on the concept i get it, segment * 16 + offset to get the address, but I don't get how the conversion works
using address 0001:0100
0001 is a word, so is 0010
so 0001h would come out to 16^0 = 1d?
and 0100h would come out to 16^2 = 32d?
but how come you're saying that 0001h = 16d?
then what does 0010h = ?
using address 0001:0100
0001 is a word, so is 0010
so 0001h would come out to 16^0 = 1d?
and 0100h would come out to 16^2 = 32d?
but how come you're saying that 0001h = 16d?
then what does 0010h = ?
What dont you understand?
0x0001:0x0100 =
0x0010:0010 is the same as 0x0001:0x0100, as the following shows:
Notice how both 0x0010:0010 and 0x0001:0x0100 map to the same
absolute address (0x110)
You can easily verify this by using a calculator or Windows debug
to see they both map to the same location in memory:
(Notice the values are exactally the same)
Hope this clairfies it a little[smile]
0x0001:0x0100 =
segment offset0x0001 : 0x0100; multiply segment by 16 decimal (Size of segment)0x0001 * 16 decimal = 16 decimal; add result to offset:16 decimal = 0x100x0100 + 0x10 = absolue address 0x110 (272 decimal)0x0010:0010 is the same as 0x0001:0x0100, as the following shows:
segment offset0x0010 : 0x0001; multiply segment by 160x0010 * 16 (0x10) decimal = 0x100 (256 decimal); add result to offset0x0010 = 16 decimal256 decimal (segment) + 16 decimal (offset) = absolute address 0x110 (272 decimal)Notice how both 0x0010:0010 and 0x0001:0x0100 map to the same
absolute address (0x110)
You can easily verify this by using a calculator or Windows debug
to see they both map to the same location in memory:
-d 0010:00100010:0010 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0010:0020 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0010:0030 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0010:0040 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0010:0050 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..-d 0001:01000001:0100 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0001:0110 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0001:0120 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0001:0130 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..0001:0140 C5 26 00 F0 C5 26 00 F0-C5 26 00 F0 C5 26 00 F0 .&...&...&...&..(Notice the values are exactally the same)
Hope this clairfies it a little[smile]
Author
Thanks :), I understand the concept, but what I was confused about is why 0001h was 16, because if you plug 0001h in a calc and convert to decimal you will get 1. I think that what I was missing is that the segment part of the address is actually a 20bit value, which is stored in 5 hex places, the reason they don't write out the fifth place is because it's always a 0. so 0001:0000 is actually a 00010:0000. Is that right? If so then it makes sense, since 00010 does equal 16 in the decimal system.
Quote:
I think that what I was missing is that the segment part of the address is actually a 20bit value, which is stored in 5 hex places, the reason they don't write out the fifth place is because it's always a 0. so 0001:0000 is actually a 00010:0000.
Hence the reason we multiply the segment by 16[smile]
(I personally didnt know it had a 5th place though)
The reason 0001 = 16 decimal is because it is a segment.
All segments are multplied by 16, so 0x0001 * 16 = 16 decimal (0x10)
(That wouldnt apply if you added the 5th place, though)
Author
Quote:The reason 0001 = 16 decimal is because it is a segment.
All segments are multplied by 16, so 0x0001 * 16 = 16 decimal (0x10)
(That wouldnt apply if you added the 5th place, though)
Are they really multiplied? 0001:0000 is 16 (or 0x10) because 00010 is 16.
So 0010:1010 would be 1* 16^2 + 1*16^3 + 1*16^1 = 1110h?
So I don't think it's simply multiplied it's more like converting the segment into a decimal and converting the offset into a decimal and then adding both.
Quote:from Intro to 80x86 asm and comp archiecture
This means that one segment starts at address 00000, another (overlapping the first)
starts at address 16 (0001016), another starts at address 32 (0002016), etc. Notice that the starting
address of a segment ends in 0 when written in hex. The segment number of a segment consists of the
first four hex digits of its physical address.
Quote:
As an example, 18A3:5B27 refers to the byte that is 5B27 bytes from the beginning of the segment
starting at address 18A30. Add the starting address and the offset to get the five-hex-digit address.
18A30 starting address of segment 18A3
+ 5B27 offset
1E557 five-hex-digit address
There's no converting to decimal involved - you're making this way more complicated than it actually is.
in pseudocode:
That's really all there is to it. The segment registers only hold 16 bits, there isn't an invisible 5 hex digit being stored somewhere. The CPU just does what I described every time it translates a memory address.
in pseudocode:
int Segment = 0x0010;int Offset = 0x1010;SegmentPhysicalAddress = 0x0010<<1 = 0x0100Segment:Offset = SegmentPhysicalAddress+Offset = 0x0100+0x1010 = 0x1110That's really all there is to it. The segment registers only hold 16 bits, there isn't an invisible 5 hex digit being stored somewhere. The CPU just does what I described every time it translates a memory address.
Author
Quote:Original post by cshowe
There's no converting to decimal involved - you're making this way more complicated than it actually is.
in pseudocode:int Segment = 0x0010;int Offset = 0x1010;SegmentPhysicalAddress = 0x0010<<1 = 0x0100Segment:Offset = SegmentPhysicalAddress+Offset = 0x0100+0x1010 = 0x1110
That's really all there is to it. The segment registers only hold 16 bits, there isn't an invisible 5 hex digit being stored somewhere. The CPU just does what I described every time it translates a memory address.
Yeah I got 1110h too, I was just saying for the sakes of clarity, that it's more like converting to a decimal rather then somply multiplying by 16, because if it's a 0010:0000 you would have to multiply by 256.
Actually it's not the final address that bothered me when i first posted but I couldn't get why 0001:0000 is the same thing as 0000:0010, because I didn't know that there's an unwritten 0 after 0001, and I was reading 0001 as 1 byte, when it's really 00010 which makes it 16 bytes. So if you go back from the current segment by 0001h (which is 16bytes) you have to go forward in the offset by the same amount and you will be at the same location except you'll be offsetting from the previous segment.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement