Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Wrap around" in protected mode ?
37 views
Skip to first unread message
Lars Erdmann
May 13, 2012, 4:24:03 AM5/13/12
to
Sorry if this is the wrong newsgroup:
I have a question about protected mode under x86:
Consider this instruction:
mov eax, ds:[bx] (mov eax, [bx])
talking about "normal" (not expand down) segments and for sake of simplicity
a segment with 1-byte limit granularity:
the limit of a segment is compared against the OFFSET specified in say a
"mov" instruction.
But what if the segment BASE (of for example DS) is say 0xFFFFFFFF and the
limit (of for example BX) is say 0xFFFFF ?
In this case, can't I create a resulting linear address that will wrap
around into the low address space (say the first 16 MB) : 0xFFFFFFFF +
0xFFFFF = 0x1000FFFFE = 0xFFFFE ?
Lars
I have a question about protected mode under x86:
Consider this instruction:
mov eax, ds:[bx] (mov eax, [bx])
talking about "normal" (not expand down) segments and for sake of simplicity
a segment with 1-byte limit granularity:
the limit of a segment is compared against the OFFSET specified in say a
"mov" instruction.
But what if the segment BASE (of for example DS) is say 0xFFFFFFFF and the
limit (of for example BX) is say 0xFFFFF ?
In this case, can't I create a resulting linear address that will wrap
around into the low address space (say the first 16 MB) : 0xFFFFFFFF +
0xFFFFF = 0x1000FFFFE = 0xFFFFE ?
Lars
Lars Erdmann
May 13, 2012, 4:55:23 AM5/13/12
to
For the example, make that spell:
mov al, ds:[ebx]
The question remains the same.
Lars
"Lars Erdmann" <lars.e...@nospicedham.arcor.de> schrieb im Newsbeitrag
news:4faf6fa3$0$6635$9b4e...@newsspool2.arcor-online.net...
mov al, ds:[ebx]
The question remains the same.
Lars
"Lars Erdmann" <lars.e...@nospicedham.arcor.de> schrieb im Newsbeitrag
news:4faf6fa3$0$6635$9b4e...@newsspool2.arcor-online.net...
Tim Roberts
May 14, 2012, 1:59:41 AM5/14/12
to
"Lars Erdmann" <lars.e...@nospicedham.arcor.de> wrote:
>
>I have a question about protected mode under x86:
>
>Consider this instruction:
>
>mov eax, ds:[bx] (mov eax, [bx])
>...
>
>I have a question about protected mode under x86:
>
>Consider this instruction:
>
>mov eax, ds:[bx] (mov eax, [bx])
>But what if the segment BASE (of for example DS) is say 0xFFFFFFFF and the
>limit (of for example BX) is say 0xFFFFF ?
>In this case, can't I create a resulting linear address that will wrap
>around into the low address space (say the first 16 MB) : 0xFFFFFFFF +
>0xFFFFF = 0x1000FFFFE = 0xFFFFE ?
No. If the sum of the segment base plus the offset produces an overflow,
>limit (of for example BX) is say 0xFFFFF ?
>In this case, can't I create a resulting linear address that will wrap
>around into the low address space (say the first 16 MB) : 0xFFFFFFFF +
>0xFFFFF = 0x1000FFFFE = 0xFFFFE ?
that causes a general protection fault.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Rod Pemberton
May 14, 2012, 3:32:12 AM5/14/12
to
"Tim Roberts" <ti...@nospicedham.probo.com> wrote in message
news:1871r71o2auaml9fj...@4ax.com...
Are you sure?
What causes the overflow to trigger the GP fault?
DJGPP uses 4GB segments with a base address of 1MB. You can access from 1MB
upto 4GB (as offset 0 to 4GB-1MB) and then wrap and access from 0 to 1MB (as
offset 4GB-1MB+1 to 4GB).
I've done that with DJGPP. That's one of a few methods of accessing
below 1MB with DJGPP.
At the moment, I don't see what is different from that and
Lar's question ... (?)
If the limit is 0xFFFFF and the base is 0xFFFFFFFF, then Lars should be able
to access 0xFFFFFFFF (base+offset of 0) as well as the range 0 to 0xFFFFE
(base+offset 1 to base+offset 0xFFFFE). Yes?
Rod Pemberton
news:1871r71o2auaml9fj...@4ax.com...
What causes the overflow to trigger the GP fault?
DJGPP uses 4GB segments with a base address of 1MB. You can access from 1MB
upto 4GB (as offset 0 to 4GB-1MB) and then wrap and access from 0 to 1MB (as
offset 4GB-1MB+1 to 4GB).
I've done that with DJGPP. That's one of a few methods of accessing
below 1MB with DJGPP.
At the moment, I don't see what is different from that and
Lar's question ... (?)
If the limit is 0xFFFFF and the base is 0xFFFFFFFF, then Lars should be able
to access 0xFFFFFFFF (base+offset of 0) as well as the range 0 to 0xFFFFE
(base+offset 1 to base+offset 0xFFFFE). Yes?
Rod Pemberton
wolfgang kern
May 14, 2012, 4:44:07 AM5/14/12
to
Tim Roberts replied to Lars Erdmann:
>>I have a question about protected mode under x86:
>>Consider this instruction:
>>mov eax, ds:[bx] (mov eax, [bx])
>>...
>>But what if the segment BASE (of for example DS) is say 0xFFFFFFFF and the
>>limit (of for example BX) is say 0xFFFFF ?
>>In this case, can't I create a resulting linear address that will wrap
>>around into the low address space (say the first 16 MB) : 0xFFFFFFFF +
>>0xFFFFF = 0x1000FFFFE = 0xFFFFE ?
> No. If the sum of the segment base plus the offset produces an overflow,
> that causes a general protection fault.
I have to confess that I never checked rollover on PM16 in practice...
(in opposition to RM-rollover it looks impossible with PM32 anyway)
even such a rollover condition can be setup in a segment-decriptor, it seems
that all PC-hardware I had in hand act quite strange (fully lock)
on any attempt to read above a certain address also without rollover.
There are 'firmware-hubs' and 'mapped-away' regions at the end of 4G RAM,
these seem to be owned by hardware and not meant to be accessed by CPU.
I once tried to remap this memory-range as readable, but then the whole
thing didn't work any more (just locked up, by any luck no smoke, and
most BIOS-settings were messed up and needed a master-reset to recover).
__
wolfgang
Tim Roberts
May 16, 2012, 1:08:24 AM5/16/12
to
"Rod Pemberton" <do_no...@nospicedham.notemailntt.cmm> wrote:
>
>Are you sure?
I was, but I'm not any more. ;)
>What causes the overflow to trigger the GP fault?
It's certainly trivially easy to have an overflow status bit from a 32-bit
adder. My memory, and my interpretation of the documentation, told me that
there WAS such an overflow bit, and the firing of that bit caused a GP
fault.
>DJGPP uses 4GB segments with a base address of 1MB. You can access from 1MB
>upto 4GB (as offset 0 to 4GB-1MB) and then wrap and access from 0 to 1MB (as
>offset 4GB-1MB+1 to 4GB).
>
>I've done that with DJGPP. That's one of a few methods of accessing
>below 1MB with DJGPP.
>
>At the moment, I don't see what is different from that and
>Lar's question ... (?)
That is correct. If that's what you saw, then my memory and my
interpretation are wrong.
>
>Are you sure?
I was, but I'm not any more. ;)
>What causes the overflow to trigger the GP fault?
adder. My memory, and my interpretation of the documentation, told me that
there WAS such an overflow bit, and the firing of that bit caused a GP
fault.
>DJGPP uses 4GB segments with a base address of 1MB. You can access from 1MB
>upto 4GB (as offset 0 to 4GB-1MB) and then wrap and access from 0 to 1MB (as
>offset 4GB-1MB+1 to 4GB).
>
>I've done that with DJGPP. That's one of a few methods of accessing
>below 1MB with DJGPP.
>
>At the moment, I don't see what is different from that and
>Lar's question ... (?)
interpretation are wrong.
Lars Erdmann
May 25, 2012, 1:46:11 AM5/25/12
to
Your answer answers my question. It's what I wanted to know.
And it confirms that a wraparound happens.
Lars
"Rod Pemberton" <do_no...@nospicedham.notemailntt.cmm> schrieb im
Newsbeitrag news:joqccn$ft1$1...@speranza.aioe.org...
And it confirms that a wraparound happens.
Lars
"Rod Pemberton" <do_no...@nospicedham.notemailntt.cmm> schrieb im
Newsbeitrag news:joqccn$ft1$1...@speranza.aioe.org...
0 new messages