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


Groups > comp.arch.embedded > #18771

Re: x86 real mode

From glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups comp.arch.embedded
Subject Re: x86 real mode
Date 2014-10-18 03:26 +0000
Organization Aioe.org NNTP Server
Message-ID <m1smlk$o3o$1@speranza.aioe.org> (permalink)
References <m1r8pj$che$1@speranza.aioe.org> <pcn24a9869skgfal4rqrpn32mgu8dk5201@4ax.com> <m1s3h1$j46$1@speranza.aioe.org> <8ge34a5hkcilgnct8bqih579ot832378m2@4ax.com>

Show all headers | View raw


George Neuner <gneuner2@comcast.net> wrote:

(snip, someone wrote)

>>> different segments can't reasonably be compared.  If you are using
>>> multiple data segments and you need to compare pointers, you have to
>>> use normalized "huge" pointers.  Do be aware that huge pointer
>>> arithmetic can be quite a bit slower due to (re)normalization of the
>>> results.

(then I wrote)
>>You don't say what language you use, but C only allows comparison
>>of pointers to different objects as equal or not equal. With large
>>model, objects (arrays and structs) can't get larger than 64K.
>>(For C, they can't even equal 64K.)  A C compiler should generate
>>properly comparable (for equal or not equal) pointers in large
>>model.
 
> No, actually it won't - at least not in the "large" model with Intel
> or Micro$oft compilers.
 
> Far pointers are constructed by left shifting the segment value by 4
> bits and adding a 16 bit offset - i.e. they are a 20 bit address
> expressed as 4:16.  In real mode there are no reserved segment values
> so there are 4096 possible far pointers for *every* location in memory
> (with wraparound arithmetic there is a possible segment base every
> 16-bytes within -32K..+32K of the location).

Yes, but the compiler should make sure that only one of those
is ever used. That is, unless you cheat and change them yourself.
 
> Huge pointers are 16:4, the 20 bit address normalized to a 16 bit
> segment and a 4 bit offset.  This ensures that every distinct huge
> pointer value references a unique location in the 1MB space.

I tried to avoid huge, but yes. 

Actually, no. I am pretty sure that at least MSC 6.x, which is what
I used at the time, generated segment selectors 4K apart and
16 bit offsets.  The other way doesn't work right with OS/2. 
You don't want to allocates a segment selector for every 16 bytes.

The compilers ran under either DOS or OS/2, and generated the
same code in either case. I even used to generate bound executables
which run under either DOS or OS/2.

But in any case, it is the responsibility of the compiler to
make it work, if you follow the C standard. Normalizing them
yourself isn't standard C.  Casting a huge pointer to a far
pointer isn't, either. 

I don't think I ever tried arrays of struct of unusual size. 
It might have padded them out.  I did use large model pretty much
all the time, and never had any problems. 
 
> The problem is that normalization is costly (a few extra instructions)
> and compilers don't do it unless you explicitly ask for it by using
> the huge model or by using huge pointers in other models.

And I pretty much never used it. But a 4K entry array of pointers
to 8K doubles allows for 32MB which was big for a 286.
 
>>In many cases, I have used 2D arrays, actual C arrays of pointers
>>to arrays.  As long as the array of pointers and pointed-to arrays
>>fit in 64K, you can get plenty big enough. 

>>I believe in the OS/2 1.x days, I had 16M on my system before
>>converting to OS/2 2.x and appropriate compilers.
 
> OS/2 1.x operated in 80286 protected mode, which has other issues that
> are not relevant to Don's question.
 
> That said, you are absolutely correct that there are ways to get
> around the limitations of 16-bit segments.
 
>>There is medium and compact, and I forget which is which.
 
> Yeah, I don't recall which is which just now, but one is 64K code +
> 1MB data and the other is the reverse.  
 
> The "large" model allows 1MB code+data using unnormalized pointers.
> The "huge" mode is the same but using normalized pointers.

Actually, large allows for a lot more than 1MB. And OS/2 will swap
whole segments to/from disk, so you can do really large arrays.

OS/2 1.x allowed for 8K segment selectors for a user process,
each could be up to 64K, so 512MB.  With DOS, only 640K, or if
you use the right display board, you can go up a litle more.

I started OS/2 1.0 in 1990, and tried not to use DOS after that.

-- glen

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web