Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.assembly > #8 > unrolled thread

Little Big Mode

Back to article view | Back to alt.os.assembly

Contents

  Little Big Mode "Mike Gonta" <mikegonta@gmail.com> - 2016-06-06 05:58 -0400
    Re: Little Big Mode Cecil Bayona <cbayona@cbayona.com> - 2016-06-06 10:00 -0500
      Re: Little Big Mode "wolfgang kern" <nowhere@never.at> - 2016-06-14 09:45 +0200
        Re: Little Big Mode Cecil Bayona <cbayona@cbayona.com> - 2016-06-14 10:08 -0500
          Re: Little Big Mode "wolfgang kern" <nowhere@never.at> - 2016-06-14 21:18 +0200
        Re: Little Big Mode Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-06-14 17:14 -0400
          Re: Little Big Mode "wolfgang kern" <nowhere@never.at> - 2016-06-15 10:00 +0200
    Re: Little Big Mode JJ <jj4public@vfemail.net> - 2016-06-07 13:21 +0700
    Re: Little Big Mode CN <qmbmnp3799@pacbell.net> - 2016-06-15 03:08 -0700

#8 — Little Big Mode

Apparently when using 32 bit instructions in real mode on a
modern PC the 24 bit address calculation (segment register *
16 + offset) utilizes 24 bits of the offset register.
This is an interesting _discovery_.
By using 32 bit instructions and setting the segment
registers to zero the entire 1MB *flat* address space is
accessible in real mode.

http://forum.osdev.org/viewtopic.php?f=1&p=261190#p261190

https://redd.it/4ms6y0


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta 

[toc] | [next] | [standalone]

#9

On 6/6/2016 4:58 AM, Mike Gonta wrote:
> Apparently when using 32 bit instructions in real mode on a
> modern PC the 24 bit address calculation (segment register *
> 16 + offset) utilizes 24 bits of the offset register.
> This is an interesting _discovery_.
> By using 32 bit instructions and setting the segment
> registers to zero the entire 1MB *flat* address space is
> accessible in real mode.
>
> http://forum.osdev.org/viewtopic.php?f=1&p=261190#p261190
>
> https://redd.it/4ms6y0
>
>
> Mike Gonta
> look and see - many look but few see
>
> http://mikegonta.com
> http://tawk.to/mikegonta
>
>
Let me start by saying that I know zip about Intel Assembler code on 
modern CPUs (used to work with the I8085 CPU eons ago) but I'm 
interested in the subject.

I will soon need to write a preamble to a compilers output to set things 
right for the code to follow which is in Protected mode code. Eventually 
I will be looking for a snippet of code to setup the CPU in Protected 
Mode, setup a stack and then proceed to run the compiler code.

At this point I know nothing on the subject and I don't even know if 
other than setting up the Stack Pointer is needed in a Windows program, 
later today I will be looking for books so I can learn about the subject 
of Intel Real/Protected mode assembly language.

I read through the post and the responses and it seems that in accessing 
1 MB in Real Mode the behavior is not consistent on every CPU, so my 
question will display my less than newbie status. Are there instructions 
or registers in the CPU/MMU that can be used to make sure all machines 
work by setting the segment length to be 1 MB in Real Mode? It seems 
that there should be as there is a discussion on maybe the Bios leaving 
the segment length to 1 MB in some cases.

By the way are there any books recommended for a newbie to learn about 
Intel Assembly language and Windows/Linux programming?


Thanks
-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#11

Cecil Bayona wrote:
...
> Let me start by saying that I know zip about Intel Assembler code on 
> modern CPUs (used to work with the I8085 CPU eons ago) but I'm 
> interested in the subject.
 
> I will soon need to write a preamble to a compilers output to set things 
> right for the code to follow which is in Protected mode code. Eventually 
> I will be looking for a snippet of code to setup the CPU in Protected 
> Mode, setup a stack and then proceed to run the compiler code.
 
> At this point I know nothing on the subject and I don't even know if 
> other than setting up the Stack Pointer is needed in a Windows program, 
> later today I will be looking for books so I can learn about the subject 
> of Intel Real/Protected mode assembly language.
 
> I read through the post and the responses and it seems that in accessing 
> 1 MB in Real Mode the behavior is not consistent on every CPU, so my 
> question will display my less than newbie status. Are there instructions 
> or registers in the CPU/MMU that can be used to make sure all machines 
> work by setting the segment length to be 1 MB in Real Mode? 

After checking I can say that all (386+) Intel/AMD CPUs work identical 
in TrueRealMode, that mean segments are limited to 64Kb (aka 16bit).
There aren't single instructions to override this limits, but we got 
the well known trick to have Unreal Mode:

1. check if A20 is ON (only 1 MB available if OFF) 
2. enter PM32 and set segment limits, ie: base 0 and full 4GB range.
3. switch to PM16 (just far jump) for a 16-bit code-segment limit *).
4. go back to RM without restoring the data segment limits.

in this mode all memory up to 4GB is accessible by 32-bit addressing.

*) to add to the confusion there is also BIG real 32-bit code-segment 
possible, but I wont recommend to use it.

> It seems 
> that there should be as there is a discussion on maybe the Bios leaving 
> the segment length to 1 MB in some cases.

No, I wont blame the BIOS, it seems to come from bootloaders, emulators 
and tools (like in my case).   
 
> By the way are there any books recommended for a newbie to learn about 
> Intel Assembly language and Windows/Linux programming?

I haven't seen books which talk about modern CPUs ...
You might find ASM-tutorials in FASM and NASM foren. Both Intel and AMD 
support us with pdf-books about all available instructions for free.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#12

On 6/14/2016 2:45 AM, wolfgang kern wrote:
>
> Cecil Bayona wrote:
> ...
>> Let me start by saying that I know zip about Intel Assembler code on
>> modern CPUs (used to work with the I8085 CPU eons ago) but I'm
>> interested in the subject.
>
>> I will soon need to write a preamble to a compilers output to set
>> things right for the code to follow which is in Protected mode code.
>> Eventually I will be looking for a snippet of code to setup the CPU in
>> Protected Mode, setup a stack and then proceed to run the compiler code.
>
>> At this point I know nothing on the subject and I don't even know if
>> other than setting up the Stack Pointer is needed in a Windows
>> program, later today I will be looking for books so I can learn about
>> the subject of Intel Real/Protected mode assembly language.
>
>> I read through the post and the responses and it seems that in
>> accessing 1 MB in Real Mode the behavior is not consistent on every
>> CPU, so my question will display my less than newbie status. Are there
>> instructions or registers in the CPU/MMU that can be used to make sure
>> all machines work by setting the segment length to be 1 MB in Real Mode?
>
> After checking I can say that all (386+) Intel/AMD CPUs work identical
> in TrueRealMode, that mean segments are limited to 64Kb (aka 16bit).
> There aren't single instructions to override this limits, but we got the
> well known trick to have Unreal Mode:
>
> 1. check if A20 is ON (only 1 MB available if OFF) 2. enter PM32 and set
> segment limits, ie: base 0 and full 4GB range.
> 3. switch to PM16 (just far jump) for a 16-bit code-segment limit *).
> 4. go back to RM without restoring the data segment limits.
>
> in this mode all memory up to 4GB is accessible by 32-bit addressing.
>
> *) to add to the confusion there is also BIG real 32-bit code-segment
> possible, but I wont recommend to use it.
>
>> It seems that there should be as there is a discussion on maybe the
>> Bios leaving the segment length to 1 MB in some cases.
>
> No, I wont blame the BIOS, it seems to come from bootloaders, emulators
> and tools (like in my case).
>> By the way are there any books recommended for a newbie to learn about
>> Intel Assembly language and Windows/Linux programming?
>
> I haven't seen books which talk about modern CPUs ...
> You might find ASM-tutorials in FASM and NASM foren. Both Intel and AMD
> support us with pdf-books about all available instructions for free.
> __
> wolfgang

So what would be the advantage in Unreal Mode over using Protected Mode? 
Does it save code space compared to Protected Mode?

One advantage I can see is that you can still access the Bios calls 
without going through an act of congress, while accessing a lot more 
memory, so it benefits small to medium size programs, I'm inferring this 
but not 100% sure.

I have purchased several books on x86 Assembly language and most of 
these books barely mention Windows Protected Mode programming, one does 
in one chapter out of 24 chapters.

It basically mentions that I don't have to do much of anything, Windows 
sets things up, and all I have to do is setup the assembler to use the 
.586 instructions set, use the Flat model, and use the Windows DLLs to 
do the interaction to the OS, no mention of access to the Bios.

I will keep searching, but some of the other books I have coming deal 
specifically with Windows and Win32 programs, one is about Windows/Linux 
Protected Mode assembler usage.

Is this the right forum? or should I use the c.l.a.x86 instead, I see a 
lot of subjects there, this one is empty.


-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#13

Cecil Bayona wrote:

>>> Let me start by saying that I know zip about Intel Assembler code on
>>> modern CPUs (used to work with the I8085 CPU eons ago) but I'm
>>> interested in the subject.

>>> I will soon need to write a preamble to a compilers output to set
>>> things right for the code to follow which is in Protected mode code.
>>> Eventually I will be looking for a snippet of code to setup the CPU in
>>> Protected Mode, setup a stack and then proceed to run the compiler code.

>>> At this point I know nothing on the subject and I don't even know if
>>> other than setting up the Stack Pointer is needed in a Windows
>>> program, later today I will be looking for books so I can learn about
>>> the subject of Intel Real/Protected mode assembly language.

>>> I read through the post and the responses and it seems that in
>>> accessing 1 MB in Real Mode the behavior is not consistent on every
>>> CPU, so my question will display my less than newbie status. Are there
>>> instructions or registers in the CPU/MMU that can be used to make sure
>>> all machines work by setting the segment length to be 1 MB in Real Mode?

>> After checking I can say that all (386+) Intel/AMD CPUs work identical
>> in TrueRealMode, that mean segments are limited to 64Kb (aka 16bit).
>> There aren't single instructions to override this limits, but we got the
>> well known trick to have Unreal Mode:

>> 1. check if A20 is ON (only 1 MB available if OFF) 2. enter PM32 and set 
>> segment limits, ie: base 0 and full 4GB range.
>> 3. switch to PM16 (just far jump) for a 16-bit code-segment limit *).
>> 4. go back to RM without restoring the data segment limits.

>> in this mode all memory up to 4GB is accessible by 32-bit addressing.
>>
>> *) to add to the confusion there is also BIG real 32-bit code-segment
>> possible, but I wont recommend to use it.

>>> It seems that there should be as there is a discussion on maybe the
>>> Bios leaving the segment length to 1 MB in some cases.

>> No, I wont blame the BIOS, it seems to come from bootloaders, emulators
>> and tools (like in my case).
>>> By the way are there any books recommended for a newbie to learn about
>>> Intel Assembly language and Windows/Linux programming?

>> I haven't seen books which talk about modern CPUs ...
>> You might find ASM-tutorials in FASM and NASM foren. Both Intel and AMD
>> support us with pdf-books about all available instructions for free.

> So what would be the advantage in Unreal Mode over using Protected Mode?

I use Ureal RM for direct write to Text/Graphic sreens while in RM.
The Graphics LFB is usually far above in the 4th GB (ie: 0xD000_0000).

> Does it save code space compared to Protected Mode?

yes. RM Code is shorter and faster (no paraniod protection checks).

The main advantage from RM over PM is that there are no protection
checks and only hardware covered limits which make RM much faster than
any PM. Even Windoze and Loonix have to fallback to RM BIOS calls
when they dont got a hint from to be installed "drivers".

> One advantage I can see is that you can still access the Bios calls 
> without going through an act of congress, while accessing a lot more 
> memory, so it benefits small to medium size programs, I'm inferring this 
> but not 100% sure.

Yeah you got it right, while you are in true RM you can use all BIOS
and VBIOS functions without fear to break or end up in the wild.
And with Unreal mode you can also use BIOS functions (better have
all register highwords zeroed during it) as long functions supported.

But be aware that most BIOS dont like or even use itself Unreal mode
so you bettter call BIOS functions with clean 16-bit (zeroed upper reg)
and some functions may not accept Unreal settingd at all (depends on
the BIOS variant) .

> I have purchased several books on x86 Assembly language and most of these 
> books barely mention Windows Protected Mode programming, one does in one 
> chapter out of 24 chapters.

I hope you didn't step into the HLA/AoA trap :)
"Sandpile.org" is a good place to look for many important info.

> It basically mentions that I don't have to do much of anything, Windows 
> sets things up, and all I have to do is setup the assembler to use the 
> .586 instructions set, use the Flat model, and use the Windows DLLs to do 
> the interaction to the OS, no mention of access to the Bios.

Windoze and Loonix are heavy restricted environments and wont even
know how to access hardware without a hint from so called "drivers".
they use a HAL (Hardware Abstruction Layer) to talk with devices!

But yes, you can write code in ASM for it with many different tools.

> I will keep searching, but some of the other books I have coming deal 
> specifically with Windows and Win32 programs, one is about Windows/Linux 
> Protected Mode assembler usage.

> Is this the right forum? or should I use the c.l.a.x86 instead, I see a 
> lot of subjects there, this one is empty.

CLAX is a moderated group, so be patient to see your own post in time.

AOD isn't a forum, it rather is a place to ask questions about OS 
programming and the like. Our group is multilingual ordered :)

I'm the machine-code hardwarefreak and know nothing about Loonix nor
Windoze, while other long time posters are better in finding (instead
of searching) useful info on the net and others seem to work in the
museum and know everything about older standards.

If you got questions not covered elsewhere you are welcome in
either AOD or ALA. AOA seem to be dead already.

looks like you know what you are searching for, so your questions
will be answered in a logical way.

__
wolfgang  (welcome to the jungle of truth) 

[toc] | [prev] | [next] | [standalone]

#14

On Tue, 14 Jun 2016 09:45:07 +0200
"wolfgang kern" <nowhere@never.at> wrote:

> After checking I can say that all (386+) Intel/AMD CPUs work
> identical in TrueRealMode, that mean segments are limited to 64Kb
> (aka 16bit). There aren't single instructions to override this
> limits, but we got the well known trick to have Unreal Mode:
> 
> 1. check if A20 is ON (only 1 MB available if OFF) 
> 2. enter PM32 and set segment limits, ie: base 0 and full 4GB range.

By "enter PM32" do you mean set CR0.PE? ...

Did you mean "enter PM" here instead of "enter PM32"?

As I understand it, neither PM16 or PM32 is activated until the far
jump, but access to hidden PM features is enabled via setting CR0.PE.

> 3. switch to PM16 (just far jump) for a 16-bit code-segment limit *).

Is a far jump to activate PM (either PM16 or PM32) necessary for this?

My understanding was that once CR0.PE was set, then you could change
limits and return to RM16, i.e., no far is jump required to activate
PM, or for unreal mode.

I've not attempted this. That is just based on what I've read.

As a side note, normally, we minimize the instructions between setting
CR0.PE and executing a PM far jump instruction.  PM activates (either
PM16 or PM32) only with a far jump after PM is enabled via CR0.PE being
set, correct?  Do BIOS calls use far jumps frequently?  So, I'm
wondering how long you can execute code in RM16 after enabling PM via
CR0.PE.  Do BIOS calls use far jumps frequently?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#15

Rod Pemberton wrote:
 
>> After checking I can say that all (386+) Intel/AMD CPUs work
>> identical in TrueRealMode, that mean segments are limited to 64Kb
>> (aka 16bit). There aren't single instructions to override this
>> limits, but we got the well known trick to have Unreal Mode:
 
>> 1. check if A20 is ON (only 1 MB available if OFF) 
>> 2. enter PM32 and set segment limits, ie: base 0 and full 4GB range.
 
> By "enter PM32" do you mean set CR0.PE? ...
> Did you mean "enter PM" here instead of "enter PM32"?

Yes, just enter PM, but load data-segments with full-range decriptors 
right after the far jump. This far jump could be either 16 or 32 bit.
 
> As I understand it, neither PM16 or PM32 is activated until the far
> jump, but access to hidden PM features is enabled via setting CR0.PE.

I once tried to load segment registers after setting PE without a far 
jump and I remember restrictions and some mad behave (see below). 

>> 3. switch to PM16 (just far jump) for a 16-bit code-segment limit *).
 
> Is a far jump to activate PM (either PM16 or PM32) necessary for this?

it's told so by AMD-docs, and I better stay on the safe side.

> My understanding was that once CR0.PE was set, then you could change
> limits and return to RM16, i.e., no far is jump required to activate
> PM, or for unreal mode.
> I've not attempted this. That is just based on what I've read.

me too saw code snips which enter unreal without this jmp, but any IRQ 
will immediate enter PM then and crash. So you need to disable IRQs 
during all unreal actions and BIOS functions cant be called anyway.
 
> As a side note, normally, we minimize the instructions between setting
> CR0.PE and executing a PM far jump instruction.  PM activates (either
> PM16 or PM32) only with a far jump after PM is enabled via CR0.PE being
> set, correct? 

Yeah, that's how I see and use it without problems.

> Do BIOS calls use far jumps frequently?  So, I'm wondering how long 
> you can execute code in RM16 after enabling PM via CR0.PE.  
> Do BIOS calls use far jumps frequently?

Oh no, the first BIOS call make it crash, INTx 'is' a FAR CALL ;)
I'd recommend to use only a clean RM->UnReal switch.

Go_Unreal:
RM: 
 CLI
 LGDT...        ;hope you already prepared it right before.
 set PE         ;OR CR0,1 by eax
 jmpf PM        ;must use a PL0 CS
PM:
 load DS,ES...  ;with FLAT data descriptor, but keep SS. 
 clr PE         ; 
 jmpf Unreal     
Unreal:         ;
 load segregs.. ;
 STI
 ...
clear register highwords are required for some BIOS calls
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#10

On Mon, 6 Jun 2016 05:58:49 -0400, Mike Gonta wrote:

> Apparently when using 32 bit instructions in real mode on a
> modern PC the 24 bit address calculation (segment register *
> 16 + offset) utilizes 24 bits of the offset register.
> This is an interesting _discovery_.
> By using 32 bit instructions and setting the segment
> registers to zero the entire 1MB *flat* address space is
> accessible in real mode.
> 
> http://forum.osdev.org/viewtopic.php?f=1&p=261190#p261190
> 
> https://redd.it/4ms6y0
> 
> Mike Gonta
> look and see - many look but few see
> 
> http://mikegonta.com
> http://tawk.to/mikegonta

Why only 24-bit addressing and only 1MB is accessible?
AFAIK, with the Page Granularity flag enabled, we should have access to 4GB
using 32-bit addressing, right?

[toc] | [prev] | [next] | [standalone]

#16

On 6/6/2016 2:58 AM, Mike Gonta wrote:
> Apparently when using 32 bit instructions in real mode on a
> modern PC the 24 bit address calculation (segment register *
> 16 + offset) utilizes 24 bits of the offset register.
> This is an interesting _discovery_.
> By using 32 bit instructions and setting the segment
> registers to zero the entire 1MB *flat* address space is
> accessible in real mode.

I didn't follow the links, but this sounds wrong. In fact, the range of 
memory you can access in real mode with 32-bit instructions depends on 
the segment limit. By default, segment limits are 64KB in real mode, so 
when you attempt to use an offset that is greater than 64KB, you get a 
GPF. The trick is, therefore, to set the segment limits to 4GB by 
entering protected mode, loading the segment registers from a GDT with 
4GB limits, then going back to real mode. Voila, you can access the 
entire 32-bit address space from real mode using instructions with the 
"address size" prefix. This is called "big real mode" or "unreal mode".

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.assembly

csiph-web