Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18771
| 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> |
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
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