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

Groups > comp.arch.embedded > #18717 > unrolled thread

x86 real mode

Back to article view | Back to comp.arch.embedded

Contents

  x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 07:23 -0700
    Re: x86 real mode Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 16:31 +0200
      Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 07:45 -0700
        Re: x86 real mode Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 16:53 +0200
          Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 08:28 -0700
            Re: x86 real mode Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-17 18:35 +0300
            Re: x86 real mode Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 17:36 +0200
              Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 13:54 -0700
                Re: x86 real mode Grant Edwards <invalid@invalid.invalid> - 2014-10-17 21:02 +0000
                  Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 14:54 -0700
                Re: x86 real mode upsidedown@downunder.com - 2014-10-18 10:09 +0300
            Re: x86 real mode Grant Edwards <invalid@invalid.invalid> - 2014-10-17 16:11 +0000
        Re: x86 real mode Stefan Reuther <stefan.news@arcor.de> - 2014-10-17 18:37 +0200
        Re: x86 real mode Les Cargill <lcargill99@comcast.com> - 2014-10-17 12:58 -0500
    Re: x86 real mode David Brown <david.brown@hesbynett.no> - 2014-10-17 16:52 +0200
      Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 16:45 +0000
    Re: x86 real mode Robert Wessel <robertwessel2@yahoo.com> - 2014-10-17 10:03 -0500
    Re: x86 real mode Grant Edwards <invalid@invalid.invalid> - 2014-10-17 16:07 +0000
    Re: x86 real mode upsidedown@downunder.com - 2014-10-17 19:57 +0300
    Re: x86 real mode Les Cargill <lcargill99@comcast.com> - 2014-10-17 12:57 -0500
    Re: x86 real mode Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-17 21:18 +0300
      Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 21:48 +0000
        Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 15:06 -0700
          Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 22:25 +0000
            Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 15:39 -0700
              Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-17 22:47 -0400
                Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 21:10 -0700
                  Re: x86 real mode upsidedown@downunder.com - 2014-10-18 11:32 +0300
              Re: x86 real mode upsidedown@downunder.com - 2014-10-18 11:10 +0300
                Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-18 08:20 -0700
                  Re: x86 real mode upsidedown@downunder.com - 2014-10-18 20:34 +0300
                    Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-18 12:53 -0700
            Re: x86 real mode upsidedown@downunder.com - 2014-10-18 10:30 +0300
            Re: x86 real mode David Brown <david.brown@hesbynett.no> - 2014-10-18 20:22 +0200
        Re: x86 real mode upsidedown@downunder.com - 2014-10-18 10:22 +0300
          Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 09:06 +0000
            Re: x86 real mode Robert Wessel <robertwessel2@yahoo.com> - 2014-10-18 08:43 -0500
            Re: x86 real mode Gerd Brix <gbrix@gmx.eu> - 2014-10-18 16:39 +0200
            Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-18 17:52 -0700
              Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-20 01:35 -0400
                Re: x86 real mode upsidedown@downunder.com - 2014-10-20 10:14 +0300
                  Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-20 14:12 -0400
                Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-20 08:15 -0700
      Re: x86 real mode Les Cargill <lcargill99@comcast.com> - 2014-10-17 18:39 -0500
        Re: x86 real mode Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-18 10:46 +0300
    Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-17 15:29 -0400
      Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-17 14:32 -0700
        Re: x86 real mode Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-18 00:09 +0200
          Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 22:31 +0000
            Re: x86 real mode upsidedown@downunder.com - 2014-10-18 12:04 +0300
              Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:22 +0000
              Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-18 20:59 -0700
        Re: x86 real mode upsidedown@downunder.com - 2014-10-18 11:53 +0300
          Re: x86 real mode Don Y <this@is.not.me.com> - 2014-10-18 09:34 -0700
      Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 22:00 +0000
        Re: x86 real mode Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-18 00:26 +0200
          Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-17 22:36 +0000
        Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-17 21:45 -0400
          Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 03:26 +0000
            Re: x86 real mode Robert Wessel <robertwessel2@yahoo.com> - 2014-10-17 23:26 -0500
              Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 05:42 +0000
            Re: x86 real mode Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-18 10:53 +0300
              Re: x86 real mode glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 09:12 +0000
          Re: x86 real mode Robert Wessel <robertwessel2@yahoo.com> - 2014-10-17 22:40 -0500
        Re: x86 real mode George Neuner <gneuner2@comcast.net> - 2014-10-17 22:07 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#18717 — x86 real mode

Hi,

What are the most conservative, *practical* expectations I can
make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
64K?  BSS in it's own segment?  Or, shared with DATA?

And, how seemlessly will the compiler let me *implicitly* move
those segments around as well as between them?  (e.g., practical
limitations on code/data sizes).  "PC" handled 640K so should
I expect that to be the size of my playground?

[Presumably, any "object" is constrained to fit within a single
segment]

I imagine this will all be accomplished in the linkage editor
(not visible to the source code).

[What a screwed up architecture!]

Thx,
--don

[toc] | [next] | [standalone]

#18718

On 10/17/2014 04:23 PM, Don Y wrote:
> Hi,
>
> What are the most conservative, *practical* expectations I can
> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
> 64K?  BSS in it's own segment?  Or, shared with DATA?
>
> And, how seemlessly will the compiler let me *implicitly* move
> those segments around as well as between them?  (e.g., practical
> limitations on code/data sizes).  "PC" handled 640K so should
> I expect that to be the size of my playground?

It would depend on what tools you use. I remember working with Borland 
tools, and they'd offer a choice of several different memory models.

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

#18719

On 10/17/2014 7:31 AM, Arlet Ottens wrote:
> On 10/17/2014 04:23 PM, Don Y wrote:
>> Hi,
>>
>> What are the most conservative, *practical* expectations I can
>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>> 64K?  BSS in it's own segment?  Or, shared with DATA?
>>
>> And, how seemlessly will the compiler let me *implicitly* move
>> those segments around as well as between them?  (e.g., practical
>> limitations on code/data sizes).  "PC" handled 640K so should
>> I expect that to be the size of my playground?
>
> It would depend on what tools you use. I remember working with Borland tools,
> and they'd offer a choice of several different memory models.

So, the "most conservative" would be to assume a tiny-ish model -- 64K
TOTAL address space? (with everything residing therein)

[I don't really care what it is, just need to know the constraints
before I settle on a design.  E.g., I surely wouldn't use int's
if values would fit in char's and every byte of data "cost" me
a byte of code!!]

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

#18721

On 10/17/2014 04:45 PM, Don Y wrote:

>>> What are the most conservative, *practical* expectations I can
>>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>>> 64K?  BSS in it's own segment?  Or, shared with DATA?
>>>
>>> And, how seemlessly will the compiler let me *implicitly* move
>>> those segments around as well as between them?  (e.g., practical
>>> limitations on code/data sizes).  "PC" handled 640K so should
>>> I expect that to be the size of my playground?
>>
>> It would depend on what tools you use. I remember working with Borland
>> tools,
>> and they'd offer a choice of several different memory models.
>
> So, the "most conservative" would be to assume a tiny-ish model -- 64K
> TOTAL address space? (with everything residing therein)

Here's an overview of the memory models: 
http://en.wikipedia.org/wiki/Intel_Memory_Model

The smallest one is the Tiny model, but I don't know if it makes sense 
to use that as a design constraint, since it's a trivial matter to 
change to another memory model if your tools support it.

> [I don't really care what it is, just need to know the constraints
> before I settle on a design.  E.g., I surely wouldn't use int's
> if values would fit in char's and every byte of data "cost" me
> a byte of code!!]

I would start by looking for a toolchain, and see what it supports.

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

#18724

On 10/17/2014 7:53 AM, Arlet Ottens wrote:
> On 10/17/2014 04:45 PM, Don Y wrote:
>
>>>> What are the most conservative, *practical* expectations I can
>>>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>>>> 64K?  BSS in it's own segment?  Or, shared with DATA?
>>>>
>>>> And, how seemlessly will the compiler let me *implicitly* move
>>>> those segments around as well as between them?  (e.g., practical
>>>> limitations on code/data sizes).  "PC" handled 640K so should
>>>> I expect that to be the size of my playground?
>>>
>>> It would depend on what tools you use. I remember working with Borland
>>> tools,
>>> and they'd offer a choice of several different memory models.
>>
>> So, the "most conservative" would be to assume a tiny-ish model -- 64K
>> TOTAL address space? (with everything residing therein)
>
> Here's an overview of the memory models:
> http://en.wikipedia.org/wiki/Intel_Memory_Model
>
> The smallest one is the Tiny model, but I don't know if it makes sense to use
> that as a design constraint, since it's a trivial matter to change to another
> memory model if your tools support it.

Not a question of toolchain but, rather, what the *environment*
already "expects" (provides).  Hence the "*practical*" qualifier in
my original post.

Thanks!  I can do a LOT in 64K.  Just need to know that "going in"
instead of "after the fact"...

>> [I don't really care what it is, just need to know the constraints
>> before I settle on a design.  E.g., I surely wouldn't use int's
>> if values would fit in char's and every byte of data "cost" me
>> a byte of code!!]
>
> I would start by looking for a toolchain, and see what it supports.
>

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

#18725

On 17.10.14 18:28, Don Y wrote:

> Not a question of toolchain but, rather, what the *environment*
> already "expects" (provides).  Hence the "*practical*" qualifier in
> my original post.
>
> Thanks!  I can do a LOT in 64K.  Just need to know that "going in"
> instead of "after the fact"...
>
>>> [I don't really care what it is, just need to know the constraints
>>> before I settle on a design.  E.g., I surely wouldn't use int's
>>> if values would fit in char's and every byte of data "cost" me
>>> a byte of code!!]
>>
>> I would start by looking for a toolchain, and see what it supports.


One question is whether your target processor is 8086/88/186/188 or
something bigger. The former wrap addresses at 1 MiB, so the old
PC/AT trick to address 65520 bytes above 1048576 works only on
the bigger processors.

Some older 8086 code (including base PC BIOS) used small model
segmenting for ROM just below 1 MiB and RAM at 0. This is the cause
why there is a thing called A20 gate in PC/AT and derivatives.

-- 

Tauno Voipio

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

#18726

On 10/17/2014 05:28 PM, Don Y wrote:

>> Here's an overview of the memory models:
>> http://en.wikipedia.org/wiki/Intel_Memory_Model
>>
>> The smallest one is the Tiny model, but I don't know if it makes sense
>> to use
>> that as a design constraint, since it's a trivial matter to change to
>> another
>> memory model if your tools support it.
>
> Not a question of toolchain but, rather, what the *environment*
> already "expects" (provides).  Hence the "*practical*" qualifier in
> my original post.

The environment is provided by the toolchain startup code, so it is a 
question of toolchain.

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

#18749

On 10/17/2014 8:36 AM, Arlet Ottens wrote:
> On 10/17/2014 05:28 PM, Don Y wrote:
>
>>> Here's an overview of the memory models:
>>> http://en.wikipedia.org/wiki/Intel_Memory_Model
>>>
>>> The smallest one is the Tiny model, but I don't know if it makes sense
>>> to use
>>> that as a design constraint, since it's a trivial matter to change to
>>> another
>>> memory model if your tools support it.
>>
>> Not a question of toolchain but, rather, what the *environment*
>> already "expects" (provides).  Hence the "*practical*" qualifier in
>> my original post.
>
> The environment is provided by the toolchain startup code, so it is a question
> of toolchain.

The environment is defined by the rest of the code which I have to
co-operate.  It is poorly documented -- hence my query as to what I
could likely expect to encounter.

I'm all set, though.  Just have to figure out what I want to shoehorn
in and then find the right sized shoehorn!  Thanks!

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

#18750

On 2014-10-17, Don Y <this@is.not.me.com> wrote:
> On 10/17/2014 8:36 AM, Arlet Ottens wrote:
>> On 10/17/2014 05:28 PM, Don Y wrote:
>>
>>> Not a question of toolchain but, rather, what the *environment*
>>> already "expects" (provides).  Hence the "*practical*" qualifier in
>>> my original post.
>>
>> The environment is provided by the toolchain startup code, so it is a
>> question of toolchain.
>
> The environment is defined by the rest of the code which I have to
> co-operate.  It is poorly documented -- hence my query as to what I
> could likely expect to encounter.

So you wanted us to explain the memory model used by code that we
haven't seen and wasn't even mentioned until now?

-- 
Grant Edwards               grant.b.edwards        Yow! I have a VISION!  It's
                                  at               a RANCID double-FISHWICH on
                              gmail.com            an ENRICHED BUN!!

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

#18756

On 10/17/2014 2:02 PM, Grant Edwards wrote:
> On 2014-10-17, Don Y <this@is.not.me.com> wrote:
>> On 10/17/2014 8:36 AM, Arlet Ottens wrote:
>>> On 10/17/2014 05:28 PM, Don Y wrote:
>>>
>>>> Not a question of toolchain but, rather, what the *environment*
>>>> already "expects" (provides).  Hence the "*practical*" qualifier in
>>>> my original post.
>>>
>>> The environment is provided by the toolchain startup code, so it is a
>>> question of toolchain.
>>
>> The environment is defined by the rest of the code which I have to
>> co-operate.  It is poorly documented -- hence my query as to what I
>> could likely expect to encounter.
>
> So you wanted us to explain the memory model used by code that we
> haven't seen and wasn't even mentioned until now?

*I* haven't seen the code, either.  Please note the wording of my initial post:
     "What are the most conservative, *practical* expectations I can
     make living in x86 real mode:"

expectation:  a strong belief that something will happen or be the
               case in the future

Had I a *choice* in defining the implementation, I would have asked what
POSSIBILITIES were available to me in making that choice.  *THAT* is a
question to which I can easily get an answer without relying on folks'
"experiences".

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

#18778

On Fri, 17 Oct 2014 13:54:25 -0700, Don Y <this@is.not.me.com> wrote:

>On 10/17/2014 8:36 AM, Arlet Ottens wrote:
>> On 10/17/2014 05:28 PM, Don Y wrote:
>>
>>>> Here's an overview of the memory models:
>>>> http://en.wikipedia.org/wiki/Intel_Memory_Model
>>>>
>>>> The smallest one is the Tiny model, but I don't know if it makes sense
>>>> to use
>>>> that as a design constraint, since it's a trivial matter to change to
>>>> another
>>>> memory model if your tools support it.
>>>
>>> Not a question of toolchain but, rather, what the *environment*
>>> already "expects" (provides).  Hence the "*practical*" qualifier in
>>> my original post.
>>
>> The environment is provided by the toolchain startup code, so it is a question
>> of toolchain.
>
>The environment is defined by the rest of the code which I have to
>co-operate.  It is poorly documented -- hence my query as to what I
>could likely expect to encounter.
>
>I'm all set, though.  Just have to figure out what I want to shoehorn
>in and then find the right sized shoehorn!  Thanks!

The best guess is to look at the available RAM (for loadable programs)
or the amount of RAM and ROM. If you have less than 64 KiB total or
less than 64 KiB+64 KiB, the answer would be pretty obvious :-)

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

#18728

On 2014-10-17, Don Y <this@is.not.me.com> wrote:

> Not a question of toolchain

How are you going to use a memory model that isn't supported by your
toolchain?

> but, rather, what the *environment* already "expects" (provides).

What do you mean by "environment"?

Are you asking how the CPU instructions and addressing modes work?

Are you asking how much physical RAM your platform has?

> Hence the "*practical*" qualifier in my original post.

I've no clue what you mean by "practical" if you're not going to take
into account what your toolchain supports.

-- 
Grant Edwards               grant.b.edwards        Yow! I joined scientology
                                  at               at a garage sale!!
                              gmail.com            

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

#18737

Don Y wrote:
> On 10/17/2014 7:31 AM, Arlet Ottens wrote:
>> On 10/17/2014 04:23 PM, Don Y wrote:
>>> What are the most conservative, *practical* expectations I can
>>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>>> 64K?  BSS in it's own segment?  Or, shared with DATA?
>>>
>>> And, how seemlessly will the compiler let me *implicitly* move
>>> those segments around as well as between them?  (e.g., practical
>>> limitations on code/data sizes).  "PC" handled 640K so should
>>> I expect that to be the size of my playground?
>>
>> It would depend on what tools you use. I remember working with Borland
>> tools, and they'd offer a choice of several different memory models.
> 
> So, the "most conservative" would be to assume a tiny-ish model -- 64K
> TOTAL address space? (with everything residing therein)

Depends on how you want to be "most conservative".

TINY model means you can effectively ignore segment registers and work
with 16-bit flat addresses. Of course this is an assumption that doesn't
hold everywhere. Being "conservative" from this standpoint would mean
you have to assume that every object is in a different segment, i.e.
LARGE / HUGE model.


  Stefan

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

#18741

Don Y wrote:
> On 10/17/2014 7:31 AM, Arlet Ottens wrote:
>> On 10/17/2014 04:23 PM, Don Y wrote:
>>> Hi,
>>>
>>> What are the most conservative, *practical* expectations I can
>>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>>> 64K?  BSS in it's own segment?  Or, shared with DATA?
>>>
>>> And, how seemlessly will the compiler let me *implicitly* move
>>> those segments around as well as between them?  (e.g., practical
>>> limitations on code/data sizes).  "PC" handled 640K so should
>>> I expect that to be the size of my playground?
>>
>> It would depend on what tools you use. I remember working with Borland
>> tools,
>> and they'd offer a choice of several different memory models.
>
> So, the "most conservative" would be to assume a tiny-ish model -- 64K
> TOTAL address space? (with everything residing therein)
>
> [I don't really care what it is, just need to know the constraints
> before I settle on a design.

The point is that you have choices.

>  E.g., I surely wouldn't use int's
> if values would fit in char's and every byte of data "cost" me
> a byte of code!!]
>
>

Okay then.

-- 
Les Cargill

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

#18720

On 17/10/14 16:23, Don Y wrote:
> Hi,
> 
> What are the most conservative, *practical* expectations I can
> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
> 64K?  BSS in it's own segment?  Or, shared with DATA?

It should, I think be possible to have DS, CS and SS each pointing to a
different 64 KB segment.  But .bss and .data would both be part of the
data segment.  Access to other segments (including pointers to stack
data, if SS is not the same as DS) is via "far pointers".

> 
> And, how seemlessly will the compiler let me *implicitly* move
> those segments around as well as between them?  (e.g., practical
> limitations on code/data sizes).  "PC" handled 640K so should
> I expect that to be the size of my playground?
> 

I believe in real mode you can get 1 MB of address space total.  I am
not sure if things like video cards get mapped into that space at all,
or are only accessible with I/O instructions.

> [Presumably, any "object" is constrained to fit within a single
> segment]

It doesn't have to be - but it is going to be a little complex to access
objects that span 64K segments.

> 
> I imagine this will all be accomplished in the linkage editor
> (not visible to the source code).
> 
> [What a screwed up architecture!]
> 

Yes, x86 was screwed up the day it arrived on the market.

But the real question, which you knew someone was bound to ask, is /why/
are you using real mode on the x86?  The chips boot in real mode, but
you would normally jump to protected mode after a few instructions to
set it up (unless you really are using an 8086 processor).

I believe I read somewhere that in modern x86 chips, the cache can be
configured to work as ram (basically, you have a write-back cache but
disable writing back to external memory), so that if you are working
with x86 code this small, you don't need any external memory.

You might find more useful information on the www.coreboot.org or
www.freedos.org websites.

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

#18730

David Brown <david.brown@hesbynett.no> wrote:
> On 17/10/14 16:23, Don Y wrote:

(snip)
>> What are the most conservative, *practical* expectations I can
>> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>> 64K?  BSS in it's own segment?  Or, shared with DATA?
 
> It should, I think be possible to have DS, CS and SS each pointing to a
> different 64 KB segment.  But .bss and .data would both be part of the
> data segment.  Access to other segments (including pointers to stack
> data, if SS is not the same as DS) is via "far pointers".

Some instructions, such as CALL, use a far pointer.

Others use a segment override prefix.

Most use DS: for accessing data, but you can put a CS:, ES:,
FS:, or GS: prefix on the instruction (or on the data operand),
and it will use the specified segment instead. 

If you have a far pointer, you load it into a segment register,
index register pair, and then use the appropriate prefix.

-- glen

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

#18722

On Fri, 17 Oct 2014 07:23:40 -0700, Don Y <this@is.not.me.com> wrote:

>Hi,
>
>What are the most conservative, *practical* expectations I can
>make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>64K?  BSS in it's own segment?  Or, shared with DATA?
>
>And, how seemlessly will the compiler let me *implicitly* move
>those segments around as well as between them?  (e.g., practical
>limitations on code/data sizes).  "PC" handled 640K so should
>I expect that to be the size of my playground?
>
>[Presumably, any "object" is constrained to fit within a single
>segment]
>
>I imagine this will all be accomplished in the linkage editor
>(not visible to the source code).
>
>[What a screwed up architecture!]


Typically compilers would offer several memory models you could use.
One code (text) and one data segment was "small" model.  You also had
large (code and data could both be more than one segment, but no
object could be bigger than a segment), and medium (one data, multiple
code) was very common.  Rarely did you see compact (one code, multiple
data).  The pointer sizes obviously varied between the models, and the
larger pointers had performance impacts.

There would be some limitations even with the large data models
(beyond the single-object size limit).  Invariably your stack could
still not exceed 64KB, and some compilers insisted on putting some
data (and usually the stack as well) in one "primary" data segment
(usually called DGROUP), and it was occasionally possible to run out
of space there if you had masses of initialized storage (you could
usually tell the compiler to put initialized items elsewhere).

Usually the compiler would include libraries compiled for each model,
so all would work pretty much as expected.

Typically you'd select the memory model with a command line switch.

Some folks also supported "huge" model, which was like large, except
objects bigger than 64K were supported (the generated code was often
painful, but it worked).  Tiny existed as well, which was the old
single segment (".com") model, although that was more a mangling of
small model in most cases.

In most cases you could explicitly deal with larger pointers in code,
for example by declaring a pointer as "far".  Although that would
usually have library issues that you'd have to manually deal with (for
example, a program compiled medium model would have nominal small data
pointers, and while you could allocate additional "far" data, and
access it via far pointers, you couldn't pass those addresses to a
"normal" library function like strcpy(), which, in medium mode, would
be expecting only small pointers).

But most serious compilers, and pretty much all C compilers,
support(ed) large model just fine, and you basically see no oddities
accessing the entire 640KB (or more, in 16-bit protected mode),
although there is a performance hit.  Nor were there usually any
oddities with the other memory models (other than sometimes having
different size code and data pointers).  You did see some stuff if you
built a mixed model application, where, as I mentioned, you'd have
explicit "far"s in you code.  If you *don't* do mixed model, it's just
another platform.

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

#18727

On 2014-10-17, Don Y <this@is.not.me.com> wrote:

> What are the most conservative, *practical* expectations I can
> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
> 64K?  BSS in it's own segment?  Or, shared with DATA?

It depends on the compiler and on the memory model you selected when
invoking the compiler.

Real-mode compilers usually had at least 4 memory models, sometimes
more.  It was a _long_ time ago I think the last time I used the
Microsoft DOS C compiler there were 5:

 tiny
 small
 medium
 large
 huge
 
I think tiny meant everything was in the same 64K segment (all segment
registers were equal and never changed).  That may have only been used
for .com files rather than .exe files.  All pointers were 16 bits.

IIRC, small meant there was a single 64K text segment, and a single 64K
data segment.  All pointers were 16 bits.

In medium, I think each function (or file?) had it's own text segment,
but there was still a single 64K data segment (pointer to function was
32 bits, pointer to data was 16 bits).  Or was that large.

In huge every function (or file?) had its own text segment and its own
data segment.  All pointers were 32 bit.

Or something like that.

And then there was paging/overlay support you could add into the mix.

> [What a screwed up architecture!]

Yup.

-- 
Grant Edwards               grant.b.edwards        Yow! Jesus is my POSTMASTER
                                  at               GENERAL ...
                              gmail.com            

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

#18731

On Fri, 17 Oct 2014 07:23:40 -0700, Don Y <this@is.not.me.com> wrote:

>What are the most conservative, *practical* expectations I can
>make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
>64K?  BSS in it's own segment?  Or, shared with DATA?

The smallest would be putting into a single 64 KiB segment. That would
be equivalent to a 1960/70's minicomputer.

Putting 64 KiB of TEXT in one segment and DATA+BSS in an other 64 KiB
would be equivalent to code/data address space of some minicomputers.
Some had issues with self modifying code, but unless you did something
exotic, there should not have been much issues even on the x86.

Those small modes could be easily programmed in assembler, but with
larger data models with segment overrides and long pointer made
assembly programming really ugly, so it is understandable that high
level support were developed.
 

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

#18740

Don Y wrote:
> Hi,
>
> What are the most conservative, *practical* expectations I can
> make living in x86 real mode:  TEXT of 64K and DATA of (disjoint)
> 64K?  BSS in it's own segment?  Or, shared with DATA?
>

Go find out how tiny, small, (medium?) large and huge models
worked in Borland and M$ tools.

It's all about how the compiler treats the segment registers. And then 
there's extended memory, expanded memory, exalted* memory.

*I made that last one up.

> And, how seemlessly will the compiler let me *implicitly* move
> those segments around as well as between them?  (e.g., practical
> limitations on code/data sizes).  "PC" handled 640K so should
> I expect that to be the size of my playground?
>
> [Presumably, any "object" is constrained to fit within a single
> segment]
>
> I imagine this will all be accomplished in the linkage editor
> (not visible to the source code).
>
> [What a screwed up architecture!]

It fit well enough into memory prices for the time. But yeah.
We know :)

>
> Thx,
> --don

--
Les Cargill

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

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web