|
Home > Archive > Unix Programming > May 2004 > Format of Pointers in Unix
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Format of Pointers in Unix
|
|
| Daniel Rudy 2004-05-16, 7:33 am |
| Hello,
On a x86 machine, what is the format of a pointer in C? I know for a
fact that the x86 p-mode uses a /selector:offset/ notation where the
selector is defined in either the GDT or LDT. Does that carry over into
the pointer, or does Unix use the flat memory model?
--
Daniel Rudy
Remove nospam, invalid, and 0123456789 to reply.
| |
|
|
| Barry Margolin 2004-05-16, 10:34 am |
| In article <Xns94EB8F0D1511Fhsnoservernet@212.27.42.72>,
Emmanuel Delahaye <emdelYOURBRA@noos.fr> wrote:
> In 'comp.lang.c', Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789>
> wrote:
>
>
> <CLC>
> The C language doesn't define "the format of a pointer". The answer is
> plateform dependent. Read your compiler manual.
> </CLC>
He said "on a x86" and mentioned "Unix" in the Subject line, so he seems
to realize it's platform dependent.
It's probably not in the compiler manual -- the format of pointers (and
other data types) is typically dictated by the operating system's ABI.
Otherwise, you wouldn't be able to use applications compiled with a
different compiler than the system's libraries.
However, since there's more than one vendor of Unix for x86 platforms,
and they're not required to be binary-compatible with each other, the
answer may be specific to the particular version of Unix the OP is
using. Since he didn't say, we can't even give a good answer for this
in comp.unix.programmer.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Daniel Rudy 2004-05-16, 11:34 am |
| And somewhere around the time of 05/16/2004 07:34, the world stopped and
listened as Barry Margolin contributed the following to humanity:
> In article <Xns94EB8F0D1511Fhsnoservernet@212.27.42.72>,
> Emmanuel Delahaye <emdelYOURBRA@noos.fr> wrote:
>
>
Emmanuel, way back when in the early 90's, I was programming under DOS
using Pascal and Assembler using a DOS extender. In the 386P-Mode, the
pointer format is 16 bit selector with a 32 bit offset for a 48 bit
pointer. In 286P-Mode, both selector and offset is 16 bit. The
selectors are indices into either the Global Discriptor Table or the
Local Descriptor Table. This is denoted by the x86 hardware. I have NO
idea what the format is on a X86 machine with PAX enabled.
Besides, I *DID* look in the compiler manual for cc and it doesn't say.
Which is why I'm asking in the first place. Also, does Unix use the
segmented or flat memory model. I'm asking because I don't know and the
docs on my system don't really give a straight answer either way.
[vbcol=seagreen]
>
> He said "on a x86" and mentioned "Unix" in the Subject line, so he seems
> to realize it's platform dependent.
>
> It's probably not in the compiler manual -- the format of pointers (and
> other data types) is typically dictated by the operating system's ABI.
> Otherwise, you wouldn't be able to use applications compiled with a
> different compiler than the system's libraries.
>
> However, since there's more than one vendor of Unix for x86 platforms,
> and they're not required to be binary-compatible with each other, the
> answer may be specific to the particular version of Unix the OP is
> using. Since he didn't say, we can't even give a good answer for this
> in comp.unix.programmer.
>
Ah, forgot about that, my bad :-) I'm using FreeBSD 4.9-RELEASE.
--
Daniel Rudy
Remove nospam, invalid, and 0123456789 to reply.
| |
| subnet 2004-05-16, 3:34 pm |
| Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> wrote in message news:<IYHpc.49594$BL6.33066@newssvr29.news.prodigy.com>...
> On a x86 machine, what is the format of a pointer in C? I know for a
> fact that the x86 p-mode uses a /selector:offset/ notation where the
> selector is defined in either the GDT or LDT. Does that carry over into
> the pointer, or does Unix use the flat memory model?
Several mainstream OSes (including linux and freebsd, I think) use a
flat memory model. In linux, look at
/usr/src/linux/arch/i386/kernel/head.S for the gdt map. Basically, it
uses 4 main "flat" segments (ie, starting at 0x0 and ending at
0xffffffff) for kernel code, kernel data, user code, user data. Of
course, since segmentation in the x86 can't be disabled, the cpu
internally still accesses memory using a selector:offset pair, but
since the selector always refers to a 4GB segment, this effectively
results in practice in a flat memory model. The four different
selectors are employed to enforce different memory access privileges
for kernel mode and user mode.
AFAIK, what you call a "pointer" in C is (on IA32) just a 4-byte
variable that holds the "offset" part in the selector:offset pair (the
selectors are usually preset by the OS, and user programs can't modify
them). Furthermore, keep in mind that all modern OSes use _virtual_
memory, so you'll probably find that two different pointers in two
different programs can hold the same value, but that's normal, since
they are virtual addresses.
HTH
| |
| Nils O. Selåsdal 2004-05-16, 7:34 pm |
| And Daniel Rudy said...
>
> Besides, I *DID* look in the compiler manual for cc and it doesn't say.
> Which is why I'm asking in the first place. Also, does Unix use the
> segmented or flat memory model. I'm asking because I don't know and the
> docs on my system don't really give a straight answer either way.
All unixes I've seen use a flat memory model for user space applications.
--
Nils Olav Selåsdal <NOS@Utel.no>
System Developer, UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
| |
| Chris Torek 2004-05-16, 9:34 pm |
| >And Daniel Rudy said...
This helps illustrate why cross-posting is often a bad idea. :-)
In article <news:pan.2004.05.16.23.08.46.586902@Utel.no>
Nils O. Selåsdal <NOS@Utel.no> writes:[vbcol=seagreen]
>All unixes I've seen use a flat memory model for user space applications.
Unix (or more specifically POSIX, although there are a number of
standards one can use to define "Unix" as well) imposes some
constraints that make life extremely difficult for anyone who wants
to use a non-uniform / "non-flat" per-process memory layout.
Specifically, the mmap() interface and functions like dlsym() even
manage to rule out all but a weakened form of Harvard architectures
("separate I&D").
Older (V6 and/or V7) Unixes did in fact run on PDP-11/70s with
truly separate I&D spaces, so that:
char *p;
void (*q)();
p = (void *)0x1234;
q = (void (*)())p;
had "p" and "q" pointing to different *physical* memory, even though
the two addresses were clearly identical. (In effect, addresses
were 17, not 16, bits long, with the "topmost" bit being "0 for
read/write-access, 1 for execute-access". Hence *p referred to
what one might call "address 0x01234", while (*q)() referred to
"0x11234".) The idea that one can mmap() an executable file and
then call into it, however, pretty much rules this right out.
The C language is much less restrictive than a typical Unix-like
system, however, so C can run on all kinds of machines that Unix
can never use. This is both good and bad: a less-restrictive system
can run on more hardware, but a more-restrictive system offers much
more "concreteness" to the programmer and is thus much easier to
write code for.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
| |
| Erik Max Francis 2004-05-16, 10:34 pm |
| Chris Torek wrote:
> Older (V6 and/or V7) Unixes did in fact run on PDP-11/70s with
> truly separate I&D spaces, so that:
>
> char *p;
> void (*q)();
> p = (void *)0x1234;
> q = (void (*)())p;
>
> had "p" and "q" pointing to different *physical* memory, even though
> the two addresses were clearly identical.
This is illegal in Standard C, anyway: data pointers and function
pointers are not compatible. Unix extensions allow (require, in the
case of dlsym) this, but it is not standard conforming to convert data
pointers to function pointers or vice versa.
--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ You cannot step into the same river once.
-- Cratylus
| |
|
| From: joe@invalid.address
Message-ID: <m3wu3bkagu.fsf@invalid.address>
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: 24.1.98.54
X-Complaints-To: abuse@comcast.net
X-Trace: attbi_s54 1084763907 24.1.98.54 (Mon, 17 May 2004 03:18:27 GMT)
NNTP-Posting-Date: Mon, 17 May 2004 03:18:27 GMT
Organization: Comcast Online
Date: Mon, 17 May 2004 03:18:27 GMT
Xref: number1.nntp.dca.giganews.com comp.lang.c:595449 comp.unix.programmer:146253
Nils O. Selåsdal <NOS@Utel.no> writes:
> And Daniel Rudy said...
>
[vbcol=seagreen]
> All unixes I've seen use a flat memory model for user space applications.
Take a look at AIX, where 32 bit pointers get converted to a 52 bit
virtual address by having the MMU use the most significant 4 bits to
refer to segment registers, and going from there.
http://publib.boulder.ibm.com/doc_l...A9CF64F8555sylv
Joe
--
"Surprise me"
- Yogi Berra when asked where he wanted to be buried.
| |
| Andrey Tarasevich 2004-05-17, 2:36 am |
| Barry Margolin wrote:
>
> He said "on a x86" and mentioned "Unix" in the Subject line, so he seems
> to realize it's platform dependent.
> ...
Strictly speaking, it is implementation dependent. If some
implementation cares to use its own pointer format (not necessarily
compatible with the format imposed by the hardware), it is free to do
so. The same applies to all other formats of internal representation,
such as, for example, integral and floating-point formats.
And the OP didn't mention any concrete compilers.
Best regards,
Andrey Tarasevich.
| |
| Daniel Rudy 2004-05-17, 2:36 am |
| And somewhere around the time of 05/16/2004 17:28, the world stopped and
listened as Chris Torek contributed the following to humanity:
>
>
> This helps illustrate why cross-posting is often a bad idea. :-)
>
My appoligies about that, but because of the nature of my question, I
believe that it would be best to invite individuals from both groups as
my question deals with C programming on the Unix platform, specifically
FreeBSD on IA32 hardware.
> In article <news:pan.2004.05.16.23.08.46.586902@Utel.no>
> Nils O. Sel?dal <NOS@Utel.no> writes:
>
>
>
> Unix (or more specifically POSIX, although there are a number of
> standards one can use to define "Unix" as well) imposes some
> constraints that make life extremely difficult for anyone who wants
> to use a non-uniform / "non-flat" per-process memory layout.
> Specifically, the mmap() interface and functions like dlsym() even
> manage to rule out all but a weakened form of Harvard architectures
> ("separate I&D").
>
> Older (V6 and/or V7) Unixes did in fact run on PDP-11/70s with
> truly separate I&D spaces, so that:
>
> char *p;
> void (*q)();
> p = (void *)0x1234;
> q = (void (*)())p;
>
> had "p" and "q" pointing to different *physical* memory, even though
> the two addresses were clearly identical. (In effect, addresses
> were 17, not 16, bits long, with the "topmost" bit being "0 for
> read/write-access, 1 for execute-access". Hence *p referred to
> what one might call "address 0x01234", while (*q)() referred to
> "0x11234".) The idea that one can mmap() an executable file and
> then call into it, however, pretty much rules this right out.
>
> The C language is much less restrictive than a typical Unix-like
> system, however, so C can run on all kinds of machines that Unix
> can never use. This is both good and bad: a less-restrictive system
> can run on more hardware, but a more-restrictive system offers much
> more "concreteness" to the programmer and is thus much easier to
> write code for.
Now here's an interesting peice of code that I wrote earlier today
complete with the compile and run:
strata:/home/dcrudy/c 1027 $$$ ->cat ptr_test1.c
/*
Pointer Test Code. Not in Book
*/
#include <stdio.h>
int thing_var; /* This is the actual thing */
int *thing_ptr; /* This is a pointer to thing */
int **thing_ptr_2; /* This is a pointer to pointer thing_ptr */
main()
{
/* Initial value of thing_var */
thing_var = 4;
printf("Value of thing_var is %d\n\n", thing_var);
/* Load pointer with address of variable thing_var */
thing_ptr = &thing_var;
printf("Address of thing_var is %x\n", &thing_var);
printf("Value of pointer is %x\n\n", thing_ptr);
/* Assign value to thing using pointer */
*thing_ptr = 5;
printf("New value of thing_var is %d\n\n", thing_var);
/* Load pointer with address of pointer thing_ptr */
thing_ptr_2 = &thing_ptr;
printf("Address of thing_ptr is %x\n", &thing_ptr);
printf("Contents of thing_ptr_2 %x\n\n", thing_ptr_2);
/* Change thing_var by referencing thing_ptr_2 */
**thing_ptr_2 = 6;
printf("Value of thing_var is %d\n\n", thing_var);
/* Lets do a pointer programming error... */
thing_ptr_2 = 7;
printf("Address of thing_ptr is %x\n", &thing_ptr);
printf("Contents of thing_ptr_2 %x\n\n", thing_ptr_2);
/* This will probably seg_fault the program. */
printf("Contents of thing via our blown ptr %d\n", **thing_ptr_2);
}
strata:/home/dcrudy/c 1031 $$$ ->cc -g -optr_test1 ptr_test1.c
ptr_test1.c: In function `main':
ptr_test1.c:38: warning: assignment makes pointer from integer without a
cast
strata:/home/dcrudy/c 1032 $$$ ->./ptr_test1
Value of thing_var is 4
Address of thing_var is 8049834
Value of pointer is 8049834
New value of thing_var is 5
Address of thing_ptr is 8049830
Contents of thing_ptr_2 8049830
Value of thing_var is 6
Address of thing_ptr is 8049830
Contents of thing_ptr_2 7
Memory fault (core dumped)
strata:/home/dcrudy/c 1033 $$$ ->gdb -se ptr_test1 -c ptr_test1.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read
called at /usr/src/gnu/usr.bin/binutils/
gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in
elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933 i
n fill_symbuf
Core was generated by `ptr_test1'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x80485b1 in main () at ptr_test1.c:43
43 printf("Contents of thing via our blown ptr %d\n",
**thing_ptr_2);
(gdb) quit
strata:/home/dcrudy/c 1034 $$$ ->
***
As you can see, the program cored because it did not like the address
that I assigned to thing_ptr_2, which would suggest a segmented memory
model? I am having a problem with this because if it was a true flat
memory model, then I would be able to read data from other process which
I have nothing to do with. There was a mention in the kernel options
about allowing a program to modify it's own LDT, which implies that
FreeBSD does use a segmented memory model of some sort.
--
Daniel Rudy
Remove nospam, invalid, and 0123456789 to reply.
| |
| Måns Rullgård 2004-05-17, 3:34 am |
| OT for c.l.c, followup set.
Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> writes:
> Now here's an interesting peice of code that I wrote earlier today
> complete with the compile and run:
[...]
> /* Lets do a pointer programming error... */
> thing_ptr_2 = 7;
> printf("Address of thing_ptr is %x\n", &thing_ptr);
> printf("Contents of thing_ptr_2 %x\n\n", thing_ptr_2);
>
> /* This will probably seg_fault the program. */
> printf("Contents of thing via our blown ptr %d\n", **thing_ptr_2);
[...]
> Memory fault (core dumped)
[...]
> As you can see, the program cored because it did not like the address
> that I assigned to thing_ptr_2, which would suggest a segmented memory
> model?
Unix uses virtual memory. On every memory access the CPU will look up
the physical address corresponding to the virtual address being
accessed. This mapping has been set up by the OS for each process.
For efficiency the mapping is done in pages of typically 4k or 8k
bytes. If there is no mapping for the virtual address being accessed,
your program tries to access the CPU will signal an error, and the OS
will kill the process. This is what happened in your case.
--
Måns Rullgård
mru@kth.se
| |
| Dan Pop 2004-05-17, 9:52 am |
| NNTP-Posting-Host: lxplus033.cern.ch
X-Trace: sunnews.cern.ch 1084795478 27122 (None) 137.138.4.220
X-Complaints-To: news@sunnews.cern.ch
User-Agent: nn/6.6.2
Xref: number1.nntp.dca.giganews.com comp.lang.c:595498 comp.unix.programmer:146266
In <pan.2004.05.16.23.08.46.586902@Utel.no> =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?= <NOS@Utel.no> writes:
>All unixes I've seen use a flat memory model for user space applications.
How many Unices for the 8086 and 286 have you seen?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
| |
| glen herrmannsfeldt 2004-05-17, 2:36 pm |
| Barry Margolin wrote:
(snip)
> He said "on a x86" and mentioned "Unix" in the Subject line, so he seems
> to realize it's platform dependent.
> It's probably not in the compiler manual -- the format of pointers (and
> other data types) is typically dictated by the operating system's ABI.
> Otherwise, you wouldn't be able to use applications compiled with a
> different compiler than the system's libraries.
The Watcom, and I believe now the OpenWatcom compilers support
large model 32 bit code, with 16 bit selector 32 bit offset,
for pointers. I don't know if any OS support running them, though.
In that case, the compiler manual does describe them because it
describes the selection between small and large model.
> However, since there's more than one vendor of Unix for x86 platforms,
> and they're not required to be binary-compatible with each other, the
> answer may be specific to the particular version of Unix the OP is
> using. Since he didn't say, we can't even give a good answer for this
> in comp.unix.programmer.
Crossposted to comp.lang.c, though...
I used to think that large model would be a good way to
get past the 4GB limit on 32 bit processors. (Many IA32
processors have a 36 bit physical address bus but only a 32 bit
MMU.) Now that Opteron and Athlon 64 prices are coming down, close
to $200 for the processor, one might just as well support that.
-- glen
| |
| Victor Wagner 2004-05-17, 2:36 pm |
| In comp.unix.programmer glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
: I used to think that large model would be a good way to
: get past the 4GB limit on 32 bit processors. (Many IA32
It is rather terrible way. I remeber days of DOS programming, it was
a pain to deal with segments and selectors. And it is also was awfully
slow. Intersegment calls was several times slower in 286 protected mode
that in real mode, not mentioning "short" calls.
: processors have a 36 bit physical address bus but only a 32 bit
: MMU.) Now that Opteron and Athlon 64 prices are coming down, close
: to $200 for the processor, one might just as well support that.
Now, Unixes already support flat 64-bit model on those processors.
Several Linux distributions are released, FreeBSD supports them too,
64-bit Solaris for x86-64 is on the way. So, better get rid of this
outdated 32-bit crap.
--
- DDD no longer requires the librx library. Consequently, librx
errors can no more cause DDD to crash.
-- DDD
| |
|
| From: James Kanze <kanze@gabi-soft.fr>
Date: 17 May 2004 21:58:23 +0200
Message-ID: <868yfqygf4.fsf@lns-th2-14-82-64-63-6.adsl.proxad.net>
Organization: James Kanze
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.93
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Lines: 21
NNTP-Posting-Date: 17 May 2004 21:56:02 MEST
NNTP-Posting-Host: 82.64.63.6
X-Trace: 1084823762 news2-e.free.fr 13009 82.64.63.6:32781
X-Complaints-To: abuse@proxad.net
Xref: number1.nntp.dca.giganews.com comp.lang.c:595606 comp.unix.programmer:146279
Nils O. Selåsdal <NOS@Utel.no> writes:
|> And Daniel Rudy said...
|> > Besides, I *DID* look in the compiler manual for cc and it doesn't
|> > say. Which is why I'm asking in the first place. Also, does Unix
|> > use the segmented or flat memory model. I'm asking because I don't
|> > know and the docs on my system don't really give a straight answer
|> > either way.
|> All unixes I've seen use a flat memory model for user space
|> applications.
That's because your just a youngster. My first exposure to Unix was on
an 8086 based system which used segmented pointers.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
| |
| Nils O. Selåsdal 2004-05-17, 5:38 pm |
| And Dan Pop said...
> In <pan.2004.05.16.23.08.46.586902@Utel.no>
> =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?= <NOS@Utel.no> writes:
>
>
> How many Unices for the 8086 and 286 have you seen?
None. And I've neither touched AIX as someone else mentioned here.
I might have given the impression that *all* unixes uses
flat memory, that was not the intention though ;)
--
Nils Olav Selåsdal <NOS@Utel.no>
System Developer, UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
| |
| Rich Teer 2004-05-17, 8:35 pm |
| On Mon, 17 May 2004, Nils O. Selåsdal wrote:
> None. And I've neither touched AIX as someone else mentioned here.
Don't forget SCO's XENIX; that was available for the 80286, IIRC.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| glen herrmannsfeldt 2004-05-17, 9:34 pm |
| Victor Wagner wrote:
> In comp.unix.programmer glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
> : I used to think that large model would be a good way to
> : get past the 4GB limit on 32 bit processors. (Many IA32
>
> It is rather terrible way. I remeber days of DOS programming, it was
> a pain to deal with segments and selectors. And it is also was awfully
> slow. Intersegment calls was several times slower in 286 protected mode
> that in real mode, not mentioning "short" calls.
I don't think it is quite that bad. It depends much on the
problems you are working on, but many that need more than 4GB
total don't need more than 4GB for any one object.
If processors cached segment descriptors, it wouldn't be so
slow. I have been told that some did, but have never seen
it in the documentation. In any case, it made possible what
otherwise might not have been possible.
> : processors have a 36 bit physical address bus but only a 32 bit
> : MMU.) Now that Opteron and Athlon 64 prices are coming down, close
> : to $200 for the processor, one might just as well support that.
> Now, Unixes already support flat 64-bit model on those processors.
> Several Linux distributions are released, FreeBSD supports them too,
> 64-bit Solaris for x86-64 is on the way. So, better get rid of this
> outdated 32-bit crap.
I probably agree now, but I didn't last year.
-- glen
| |
| August Derleth 2004-05-18, 2:36 am |
| On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:
> On Mon, 17 May 2004, Nils O. Selåsdal wrote:
>
>
> Don't forget SCO's XENIX; that was available for the 80286, IIRC.
And, I think, Microsoft made XENIX for the 8086. (One of my older UNIX
books mentions it, in a discussion of how far the *nix idea had gone by
the mid-80s.)
How did that work on a 16-bit chip without an MMU? (That is, how did it
differ from MS-DOS aside from the API/ABI and command shell being
different?)
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
| |
| Villy Kruse 2004-05-18, 3:34 am |
| On 16 May 2004 12:01:13 -0700,
subnet <sunglo@katamail.com> wrote:
> Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> wrote in message news:<IYHpc.49594$BL6.33066@newssvr29.news.prodigy.com>...
>
>
> Several mainstream OSes (including linux and freebsd, I think) use a
> flat memory model.
The few unix versions that did run on 286 did use segment:offset style
pointers just like MSDOS programs did. The only way to avoid this
given the 286 hardware was to use the small model, that is, pointers
were 16 bits and the size of a program therfore must be less than 64K.
With the ability of using 32 bit pointers in 386 made it just natural
to use a flat memory model just like the numerous unix versions that
ran on motorola 68k. That made porting a whole lot easier.
Followup-To: comp.unix.programmer
Villy
| |
| Stephen SM WONG 2004-05-18, 9:18 am |
| I'd run SCO Xenix on 80286 PC/AT, should be around 1988.
Xenix on 80286 uses segmentation model, which a code segment
can be no larger than 64kBytes, and a data segment can be no
larger than 64kBytes, though a program can have more than
one segments. IIRC, Xenix supported virtual memory, ie.
swap the whole segment in/out from swap space. And in fact,
I think it's the more correct usage of "swap" instead of
"page (partition)". Well, at the same period of time, there
were Sun 3s running on 68020/68030 (SunOS 4), and supported
X Windows with Open Look Window Manager (olwm). In the lab
I worked for, we were amazed to run Unix(-like) OS on a PC,
and equally amazed to run remote X Windows applications on
Sun 3s and displayed on a VGA Xenix workstation (X Windows)
through a coaxial 10Mbps LAN! That's old story though.
Stephen Wong @ Hong Kong
On Tue, 18 May 2004, August Derleth wrote:
> On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:
>
>
> And, I think, Microsoft made XENIX for the 8086. (One of my older UNIX
> books mentions it, in a discussion of how far the *nix idea had gone by
> the mid-80s.)
>
> How did that work on a 16-bit chip without an MMU? (That is, how did it
> differ from MS-DOS aside from the API/ABI and command shell being
> different?)
>
> --
> yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
> To email me, rot13 and convert spelled-out numbers to numeric form.
> "Makes hackers smile" makes hackers smile.
>
>
| |
| Daniel Rudy 2004-05-18, 12:42 pm |
| And somewhere around the time of 05/17/2004 23:02, the world stopped and
listened as August Derleth contributed the following to humanity:
> On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:
>
>
>
>
> And, I think, Microsoft made XENIX for the 8086. (One of my older UNIX
> books mentions it, in a discussion of how far the *nix idea had gone by
> the mid-80s.)
>
> How did that work on a 16-bit chip without an MMU? (That is, how did it
> differ from MS-DOS aside from the API/ABI and command shell being
> different?)
>
On the 8086, a memory page is 16 bytes. Every segment starts and ends
on a 16 byte boundary. This is why that 3186:3DE0 = 35640 & 3187:3DD0
also = 35640. It was much easier to send the CPU out into the weeds and
crash those machines because there was *NO* memory protection enforced
by the hardware. AFAIK, there was no swap either because the paging
mechanism doesn't exist on that ancient hardware.
--
Daniel Rudy
Remove nospam, invalid, and 0123456789 to reply.
| |
| Dan Pop 2004-05-18, 12:42 pm |
| In <pan.2004.05.18.06.02.39.144548@sig.now> August Derleth <see@sig.now> writes:
>On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:
>
>
>And, I think, Microsoft made XENIX for the 8086. (One of my older UNIX
Right, Xenix started its life as a Microsoft product.
>How did that work on a 16-bit chip without an MMU? (That is, how did it
>differ from MS-DOS aside from the API/ABI and command shell being
>different?)
Multiuser/multitasking capabilities and I think it was supporting
swapping (a whole process could be moved to the swap partition, when the
system was short of memory).
Of course, since user processes executed in kernel mode, user code had
full control over the machine.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
| |
| Dan Pop 2004-05-18, 2:50 pm |
| In <k6pqc.979$6C3.967@newssvr27.news.prodigy.com> Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> writes:
>And somewhere around the time of 05/17/2004 23:02, the world stopped and
>listened as August Derleth contributed the following to humanity:
>
>
>On the 8086, a memory page is 16 bytes. Every segment starts and ends
>on a 16 byte boundary. This is why that 3186:3DE0 = 35640 & 3187:3DD0
>also = 35640. It was much easier to send the CPU out into the weeds and
>crash those machines because there was *NO* memory protection enforced
>by the hardware. AFAIK, there was no swap either because the paging
>mechanism doesn't exist on that ancient hardware.
You don't need any paging mechanism to implement swapping. PDP-11 Unix
supported swapping, despite the lack of a paging mechanism.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
| |
| James Kanze 2004-05-20, 5:38 am |
| Rich Teer <rich.teer@rite-group.com> writes:
|> On Mon, 17 May 2004, Nils O. Selåsdal wrote:
|> > > How many Unices for the 8086 and 286 have you seen?
|> > None. And I've neither touched AIX as someone else mentioned here.
|> Don't forget SCO's XENIX; that was available for the 80286, IIRC.
You mean Microsoft's XENIX, don't you. And it was available not only
for the 80286, but even for the 8086.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
| |
| Gary Schmidt 2004-05-20, 7:34 am |
| James Kanze wrote:
> Rich Teer <rich.teer@rite-group.com> writes:
>
> |> On Mon, 17 May 2004, Nils O. Selåsdal wrote:
>
> |> > > How many Unices for the 8086 and 286 have you seen?
> |> > None. And I've neither touched AIX as someone else mentioned here.
>
> |> Don't forget SCO's XENIX; that was available for the 80286, IIRC.
>
> You mean Microsoft's XENIX, don't you. And it was available not only
> for the 80286, but even for the 8086.
>
No, he means SCO Xenix.
As I recall, there was Microsoft Xenix, IBM Xenix, and SCO Xenix.
("SCO" in this context is the "Santa Cruz Operation," not the "SCO
Group" of recent infamy).
I used IBM Xenix and SCO Xenix on the 80286 way back in the dark ages of
1986.
SCO Xenix was quite a usable product, much better than the IBM variant
(which vague memory says was just a re-badge of MS Xenix).
It was strange coming from VAXen and 68000 systems to this weird
segmented stuff, but I had been used to the 64K limit (and 16-bit
addressing) on the PDP-11, so it was the lack of an overlaying linker
that left me scratching my head.
I think I've even got the 5 1/4 inch floppies somewhere...
Cheers,
Gary B-)
--
Speaking strictly for myself.
| |
| J. J. Farrell 2004-05-22, 10:28 pm |
|
"Gary Schmidt" <Gary.Schmidt@oz.quest.com> wrote in message
news:40AC7FD3.7070806@oz.quest.com...
>
> ("SCO" in this context is the "Santa Cruz Operation," not the "SCO
> Group" of recent infamy).
The SCO Group includes most of the legacy of the Santa Cruz Operation
along with the remains of Caldera. It was renamed back to the SCO
brand since the majority of its software products derive from the SCO
heritage.
And much of their code is written in C ...
| |
| Dan Pop 2004-05-22, 10:28 pm |
| In <40AC7FD3.7070806@oz.quest.com> Gary Schmidt <Gary.Schmidt@oz.quest.com> writes:
>James Kanze wrote:
>
>No, he means SCO Xenix.
>
>As I recall, there was Microsoft Xenix, IBM Xenix, and SCO Xenix.
>("SCO" in this context is the "Santa Cruz Operation," not the "SCO
>Group" of recent infamy).
>
>I used IBM Xenix and SCO Xenix on the 80286 way back in the dark ages of
>1986.
>
>SCO Xenix was quite a usable product, much better than the IBM variant
>(which vague memory says was just a re-badge of MS Xenix).
Didn't SCO buy Xenix from Microsoft and then continued developing it
independently?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
|
|
|
|
|