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.

In 'comp.lang.c', Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> 
wrote:

>      On a x86 machine, what is the format of a pointer in C?  

<CLC>
The C language doesn't define "the format of a pointer". The answer is 
plateform dependent. Read your compiler manual. 
</CLC>

-- 
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

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:
> 
> >      On a x86 machine, what is the format of a pointer in C?  
> 
> <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 ***

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:
> 
> 
>>In 'comp.lang.c', Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> 
>>wrote:
>>
>>
>>>     On a x86 machine, what is the format of a pointer in C?  
>>
>><CLC>
>>The C language doesn't define "the format of a pointer". The answer is 
>>plateform dependent. Read your compiler manual. 
>></CLC>

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.

> 
> 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.

Daniel Rudy wrote:
> 
> 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:
> >
> >
> >>In 'comp.lang.c', Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789>
> >>wrote:
> >>
> >>
> >>>     On a x86 machine, what is the format of a pointer in C?
> >>
> >><CLC>
> >>The C language doesn't define "the format of a pointer". The answer is
> >>plateform dependent. Read your compiler manual.
> >></CLC>
> 
> 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.
> 
> >
> > 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.
> 


Ahh...  Now I see where you're coming from a little better.

Pointers in C, no matter how they are represented by the
underlying hardware/architecture, always appear as a flat
address memory model.  Pointers in C appear the same way
and are independent of the operating system, i.e.,
Unix, Windows, Mac OS, etc.  In other words, I would
code/use pointers identically on each operating system
(even though the pointer values themselves are different).

Do you _really_ need to know how a given architecture
represents a pointer?  Can you post some C code where
this would be relevant, and possibly readers of this
group may be better able to answer your question?


Stephen

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

>> Ah, forgot about that, my bad :-)  I'm using FreeBSD 4.9-RELEASE.
>> 
>
>
>Ahh...  Now I see where you're coming from a little better.
>
>Pointers in C, no matter how they are represented by the
>underlying hardware/architecture, always appear as a flat
>address memory model.  

This is *NOT* true.  The address space appears flat locally, where
you are allowed to see it, such as inside the contents of a single
array.  You are guaranteed that incrementing and decrementing pointers
will work and refer to the next and previous elements of the array.

If you want to see if it's flat globally, you have to invoke
undefined behavior.  If you do that on, say, MS-DOS using Microsoft's
16-bit C compiler in "large model", you'll notice that pointers
consist of 16 bits of segment number and 16 bits of offset, and in
real mode any pointer with the same value of 16*segment+offset
points to the same byte, even if the pointers don't compare equal.
This is decidedly unlike a flat address space.

>Pointers in C appear the same way
>and are independent of the operating system, i.e.,
>Unix, Windows, Mac OS, etc.  

If the operating system doesn't LET you use a particular mode, it's
awfully hard to use pointers in that mode.  Large-model 32-bit compilers
aren't common, but I suspect they will become more common as the need
for 4GB+ arrays increases.

>In other words, I would
>code/use pointers identically on each operating system
>(even though the pointer values themselves are different).

If you stick to defined behavior, you don't have to CARE whether
the address space is flat globally.  Under the covers, it may
not be.

>Do you _really_ need to know how a given architecture
>represents a pointer?  

If you stick to defined behavior, NO.

>Can you post some C code where
>this would be relevant, and possibly readers of this
>group may be better able to answer your question?

					Gordon L. Burditt

"Stephen L." wrote:
> 
.... snip ...
> 
> Pointers in C, no matter how they are represented by the
> underlying hardware/architecture, always appear as a flat
> address memory model.  Pointers in C appear the same way
> and are independent of the operating system, i.e.,
> Unix, Windows, Mac OS, etc.

That is just NOT so.  That fact is at the root of the ban on
subtracting pointers that do not point within the same object.  It
also the reason that most pointer comparisons can only be for
equal/not-equal.

>....                         In other words, I would
> code/use pointers identically on each operating system
> (even though the pointer values themselves are different).

Yet this sentence is accurate, within the limits prescribed by the
C standard.

-- 
"I'm a war president.  I make decisions here in the Oval Office
 in foreign policy matters with war on my mind." -         Bush.
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.

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

CBFalconer wrote:
> 
> "Stephen L." wrote:
> >
> ... snip ...
> >
> > Pointers in C, no matter how they are represented by the
> > underlying hardware/architecture, always appear as a flat
> > address memory model.  Pointers in C appear the same way
> > and are independent of the operating system, i.e.,
> > Unix, Windows, Mac OS, etc.
>
> That is just NOT so.  That fact is at the root of the ban on
> subtracting pointers that do not point within the same object.

But that's a UNIVERSAL ban across all OS's, correct?

I don't believe I've ever seen a need to do that
(subtract pointers from two different objects)...

> It
> also the reason that most pointer comparisons can only be for
> equal/not-equal.

I'm curious, is this legal -

{
	char	str[ 256 ];
	char	*p1 = str, *p2 = &str[ sizeof (str) ];

	while (p1 < p2) {
		*p1++ = '\0';
	}
}


The point I was making was that code snippet will
run and produce identical results anywhere - I don't
have to change it for x86 to Power PC, etc.

I think much of the confusion comes from inferior
C implementations on segmented architectures (I'm not
trying to start a religious war).  I _do_ understand
many of these choices were made in the interest of
performance - but that was over a decade ago!  Compiler
tweaks that allow the programmer to select this or
that address model are _really_ extensions to the language.
I should not need to worry about segments, etc. in my C code.
Really, the compiler should have been able to figure out how
to best represent my C code on the architecture.  When I
have to start thinking about how the compiler poorly
supports my address space, I'm not programming
in the C language anymore...

I stand by my original statement above.

I believe there are those who state that C isn't really
that much of a high level language - but when you think
of the way C presents pointers to the programmer (as a
person who has programmed x86, 680x0, Sparc, etc.) you
develop a wonderful respect for that _simple_ layer
of abstraction :).


Stephen

>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.

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:
>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.

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

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.

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_link/en_US/a_doc_lib/aixprggd/genprogc/address_space.htm#A9CF64F8555sylv

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.

"Stephen L." wrote:
> CBFalconer wrote:
>> "Stephen L." wrote:
>>>
>> ... snip ...
>>>
>>> Pointers in C, no matter how they are represented by the
>>> underlying hardware/architecture, always appear as a flat
>>> address memory model.  Pointers in C appear the same way
>>> and are independent of the operating system, i.e.,
>>> Unix, Windows, Mac OS, etc.
>>
>> That is just NOT so.  That fact is at the root of the ban on
>> subtracting pointers that do not point within the same object.
> 
> But that's a UNIVERSAL ban across all OS's, correct?
> 
> I don't believe I've ever seen a need to do that
> (subtract pointers from two different objects)...
> 
> > It
> > also the reason that most pointer comparisons can only be for
> > equal/not-equal.
> 
> I'm curious, is this legal -
> 
> {
>         char    str[ 256 ];
>         char    *p1 = str, *p2 = &str[ sizeof (str) ];
> 
>         while (p1 < p2) {
>                 *p1++ = '\0';
>         }
> }

Basic principle - if you have to ask OS questions, the code isn't
portable and doesn't belong here in c.l.c.  And the above is
perfectly legal - there is a special dispensation for pointers to
one item past the end of an array in the standard.

-- 
"I'm a war president.  I make decisions here in the Oval Office
 in foreign policy matters with war on my mind." -         Bush.
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.

And somewhere around the time of 05/16/2004 09:41, the world stopped and
listened as Stephen L. contributed the following to humanity:

> Daniel Rudy wrote:
> 
>>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:
>>>
>>>
>>>
>>>>In 'comp.lang.c', Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789>
>>>>wrote:
>>>>
>>>>
>>>>
>>>>>    On a x86 machine, what is the format of a pointer in C?
>>>>
>>>><CLC>
>>>>The C language doesn't define "the format of a pointer". The answer is
>>>>plateform dependent. Read your compiler manual.
>>>></CLC>
>>
>>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.
>>
>>
>>>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.
>>
> 
> 
> 
> Ahh...  Now I see where you're coming from a little better.
> 
> Pointers in C, no matter how they are represented by the
> underlying hardware/architecture, always appear as a flat
> address memory model.  Pointers in C appear the same way
> and are independent of the operating system, i.e.,
> Unix, Windows, Mac OS, etc.  In other words, I would
> code/use pointers identically on each operating system
> (even though the pointer values themselves are different).

Ah, the flat memory model.  That's exactly what I was looking for.  Thanks.

> Do you _really_ need to know how a given architecture
> represents a pointer?  Can you post some C code where
> this would be relevant, and possibly readers of this
> group may be better able to answer your question?

Actually, it has to do with pointer arithmitic and certian pointer
tricks that I like to do under Pascal.  I'm still learning C, and so far
it doesn't look like that I will need to pull some of those little
tricks like I did with my Pascal compiler to get around certian
limitations of the language.  Also, considering the environment that I
come from, I had to be very mindfull about the format of the pointers in
real mode and protected mode because I coded in x86 Assembler (Still do
to some extent for ROM type code) which gets very close to the CPU
architecture.  So part of it is  just my own paranoia getting to me.

> 
> Stephen


-- 
Daniel Rudy

Remove nospam, invalid, and 0123456789 to reply.

Barry Margolin wrote:
>> ...
>> >      On a x86 machine, what is the format of a pointer in C?  
>> 
>> <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.
> ...

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.

And somewhere around the time of 05/16/2004 17:28, the world stopped and
listened as Chris Torek contributed the following to humanity:

>>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.
> 
> 
> 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:
> 
>>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.

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.

"Stephen L." <sdlnospamar@cast-com.net> wrote:
> > That is just NOT so.  That fact is at the root of the ban on
> > subtracting pointers that do not point within the same object.
>
> But that's a UNIVERSAL ban across all OS's, correct?

It's undefined behaviour according to the C standard, and that applies to
all C implementations. Some OSes may go ahead and try to compute a value
anyway, but any value produced is never going to be meaningful unless you're
writing very platform-specific code.

> I'm curious, is this legal -
>
> {
> char str[ 256 ];
> char *p1 = str, *p2 = &str[ sizeof (str) ];
>
> while (p1 < p2) {
> *p1++ = '\0';
> }
> }

I believe it is legal. The initialisation of p2 could be written more simply
as

  p2 = str + 256;

This pointer value is "one past the end" of the str array, which behaves
according to specific rules in the C standard. You are never allowed to
dereference the value, but you are allowed to
  - add a non-positive integer to it.
  - subtract a non-negative integer from it.
  - perform a subtraction with another pointer into the
    str array (either way around).
  - perform relational comparisons between it and other
    pointers into the str array. (As you do here.)

Once the while loop is over, the p1 and p2 pointer variables both have the
same "one past the end" value.

-- 
Simon.

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

"Stephen L." <sdlnospamar@cast-com.net> writes:
> CBFalconer wrote:
> > "Stephen L." wrote:
> > ... snip ...
> > >
> > > Pointers in C, no matter how they are represented by the
> > > underlying hardware/architecture, always appear as a flat
> > > address memory model.  Pointers in C appear the same way
> > > and are independent of the operating system, i.e.,
> > > Unix, Windows, Mac OS, etc.
> >
> > That is just NOT so.  That fact is at the root of the ban on
> > subtracting pointers that do not point within the same object.
> 
> But that's a UNIVERSAL ban across all OS's, correct?

The C standard says that subtracting pointers that don't point within
the same object (or just past the end of an object) invokes undefined
behavior.  The standard makes no reference to OSs in this context.  So
yes, I guess you could call it a universal ban across all OSs.

[...]
> The point I was making was that code snippet will
> run and produce identical results anywhere - I don't
> have to change it for x86 to Power PC, etc.

Right.  (The code snippet, which I snipped, operates on pointer values
that point within a single object or just past the end of it.)

[...]
> I stand by my original statement above.

Sorry, but your original statement (that C pointers "always appear as
a flat address memory model") is incorrect.  Your code snippet shows
an effectively flat memory model within a single object, but the C
standard is specifically designed to allow either flat or non-flat
memory models beyond single objects.

(Some old compilers implement extensions to support multiple memory
models; that's a separate issue.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

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

In <40A799BB.CC059499@cast-com.net> "Stephen L." <sdlnospamar@cast-com.net> writes:

>Pointers in C, no matter how they are represented by the
>underlying hardware/architecture, always appear as a flat
>address memory model.

In C, each object resides in its own flat address space.  C defines no
metric for pointers to different objects.  As a result of this, two 
arbitrary (but well defined) pointer values can only be compared for 
equality.  The < and > operators (and their friends) require pointers to
the same object as operands.  Otherwise, the program invokes undefined
behaviour, so "it works just fine on every implementation I know of" is 
NOT a *valid* counterargument.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

In <tCYpc.67921$is.27644@newssvr25.news.prodigy.com> Daniel Rudy <dcrudy@invalid.pacbell.nospam.net.0123456789> writes:

>And somewhere around the time of 05/16/2004 09:41, the world stopped and
>listened as Stephen L. contributed the following to humanity:
>
>> Pointers in C, no matter how they are represented by the
>> underlying hardware/architecture, always appear as a flat
>> address memory model.  Pointers in C appear the same way
>> and are independent of the operating system, i.e.,
>> Unix, Windows, Mac OS, etc.  In other words, I would
>> code/use pointers identically on each operating system
>> (even though the pointer values themselves are different).
>
>Ah, the flat memory model.  That's exactly what I was looking for.

It might be exactly what you were looking for, but it's not the right
answer.

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

CBFalconer wrote:
> "Stephen L." wrote:
> 
> ... snip ...
> 
>>Pointers in C, no matter how they are represented by the
>>underlying hardware/architecture, always appear as a flat
>>address memory model.  Pointers in C appear the same way
>>and are independent of the operating system, i.e.,
>>Unix, Windows, Mac OS, etc.
> 
> 
> That is just NOT so.  That fact is at the root of the ban on
> subtracting pointers that do not point within the same object.  It
> also the reason that most pointer comparisons can only be for
> equal/not-equal.

     The ban also arises from the properties of pointer
arithmetic as defined by C: Subtracting two pointers (when
permitted) gives the number of instances of the pointed-to
type that lie between them.  This is the flip side of what
happens when you add an integer to a pointer: Adding one
to a `double*' advances by the sizeof one double, not by
one byte.

     So, consider

	typedef char Buffer[527];
	char *p = malloc(528);      /* assume success */
	Buffer *b1 = (Buffer*)p;
	Buffer *b2 = (Buffer*)(p+1);
	ptrdiff_t d = b2 - b1;      /* bzzzt! */

`b1' and `b2' point to memory locations only one byte
apart, and one is not divisible by 527.  The subtraction
is undefined, because there's no way to define it and
still maintain the properties of pointer arithmetic.

-- 
Eric.Sosman@sun.com

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

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

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:aC7qc.67553$536.10987485@attbi_s03...
> 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.)

Isn't the linear address space still 32-bit even if you have a 48-bit
virtual address space and a 36-bit physical address space?

> Now that Opteron and Athlon 64 prices are coming down, close
> to $200 for the processor, one might just as well support that.

That's ideal, but there's a lot of existing CPUs out there that will be in
service for another decade.  And, of course, Intel and AMD are still
shipping new 32-bit chips.

S

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

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

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:
> 
>>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?
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

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.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

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

Stephen Sprunk wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:aC7qc.67553$536.10987485@attbi_s03...

>>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.)

> Isn't the linear address space still 32-bit even if you have a 48-bit
> virtual address space and a 36-bit physical address space?

Yes, the MMU is still 32 bits.  With OS support, changing page
tables as needed, this could be overcome.

>>Now that Opteron and Athlon 64 prices are coming down, close
>>to $200 for the processor, one might just as well support that.

> That's ideal, but there's a lot of existing CPUs out there that will be in
> service for another decade.  And, of course, Intel and AMD are still
> shipping new 32-bit chips.

There are, but the number of applications that really need
more than 4GB is small enough, and in most case those will
require more than 4GB of real memory.  I don't feel so bad
in that case in requiring one to spend a little
more for a system to run it on.

-- glen

On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:

> 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.

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.

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>...
>
>> 	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. 


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

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:
> 
> > 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.
> 
> 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.
> 
> 

"Eric Sosman" <Eric.Sosman@sun.com> wrote:
>      The ban also arises from the properties of pointer
> arithmetic as defined by C: Subtracting two pointers (when
> permitted) gives the number of instances of the pointed-to
> type that lie between them.  This is the flip side of what
> happens when you add an integer to a pointer: Adding one
> to a `double*' advances by the sizeof one double, not by
> one byte.
>
>      So, consider
>
> typedef char Buffer[527];
> char *p = malloc(528);      /* assume success */
> Buffer *b1 = (Buffer*)p;
> Buffer *b2 = (Buffer*)(p+1);

Is it possible for an array of char to have alignment requirements?

> ptrdiff_t d = b2 - b1;      /* bzzzt! */
>
> `b1' and `b2' point to memory locations only one byte
> apart, and one is not divisible by 527.  The subtraction
> is undefined, because there's no way to define it and
> still maintain the properties of pointer arithmetic.

I would have expected the implicit division of 1 by 527 to always round down
to zero in practise. It appears to produce zero on most of my
implementations to hand (lcc-win32, microsoft vc++, borland bcc32), but
surprisingly not on cygwin gcc, where it produces a ptrdiff_t value
of -2086359825. Weird.

<OT> Any explanations? </OT>

-- 
Simon.

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:
>
>> 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.
>
>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

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:
> 
> 
>>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.
> 
> 
> 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.

gordonb.mcc42@burditt.org (Gordon Burditt) wrote in message news:<c88lrp$orh@library1.airnews.net>...
> and in
> real mode any pointer with the same value of 16*segment+offset
> points to the same byte, even if the pointers don't compare equal.
> This is decidedly unlike a flat address space.

I agree with you, that's not flat.

But...

Lots of architectures with MMU's allow the kernel to map multiple addresses
in userland space to the same hardware address.  Is this flat
or not flat?

Many designs without MMU's but with incomplete address decoding
will map two addresses to the same memory cell.

I suspect that "flat" vs "not flat" is sometimes a continuum rather
than a one-or-the-other choice.

Tim.

Ralmin wrote:
> "Eric Sosman" <Eric.Sosman@sun.com> wrote:
> 
>>     The ban also arises from the properties of pointer
>>arithmetic as defined by C: Subtracting two pointers (when
>>permitted) gives the number of instances of the pointed-to
>>type that lie between them.  This is the flip side of what
>>happens when you add an integer to a pointer: Adding one
>>to a `double*' advances by the sizeof one double, not by
>>one byte.
>>
>>     So, consider
>>
>>typedef char Buffer[527];
>>char *p = malloc(528);      /* assume success */
>>Buffer *b1 = (Buffer*)p;
>>Buffer *b2 = (Buffer*)(p+1);
> 
> Is it possible for an array of char to have alignment requirements?

     I don't think so.  It's easy to see that the alignment
requirement for any object must be a divisor of the object's
size (otherwise malloc'ed arrays wouldn't work right), so
in the illustration the alignment for `Buffer' would have
to be 1 or 17 or 31 or 527.  Of these, only 1 (no alignment)
seems a reasonable choice.

     This argument can probably be extended to show that an
array's alignment requirement cannot be stricter than that
of its elements.  While I believe this to be true, I confess
that I wouldn't stake my life on being able to prove it with
perfect rigor.

>>ptrdiff_t d = b2 - b1;      /* bzzzt! */
>>
>>`b1' and `b2' point to memory locations only one byte
>>apart, and one is not divisible by 527.  The subtraction
>>is undefined, because there's no way to define it and
>>still maintain the properties of pointer arithmetic.
> 
> I would have expected the implicit division of 1 by 527 to always round down
> to zero in practise.

     Ordinary integer division does so, of course.  But if
you tried to extend that behavior to pointer subtraction
you'd wind up with things like `b1 + (b2 - b1) != b2'.
One *could* define a language this way -- after all, we've
survived `3 * (5 / 3) != 5' -- but the usefulness would be
questionable.  In any event, C isn't defined this way.

> It appears to produce zero on most of my
> implementations to hand (lcc-win32, microsoft vc++, borland bcc32), but
> surprisingly not on cygwin gcc, where it produces a ptrdiff_t value
> of -2086359825. Weird.
 >
> <OT> Any explanations? </OT>

     A splendid example of undefined behavior ;-)  Or, just
possibly, using the wrong printf() conversion specifier to
display the ptrdiff_t value, and getting away with it on only
three of four implementations ...

-- 
Eric.Sosman@sun.com

In message <cb71e341e82847ce79bdfb2a798152af@news.teranews.com>
          "Ralmin" <news@ralminNOSPAM.cc> wrote:

> "Eric Sosman" <Eric.Sosman@sun.com> wrote:
> > ptrdiff_t d = b2 - b1;      /* bzzzt! */
> >
> > `b1' and `b2' point to memory locations only one byte
> > apart, and one is not divisible by 527.  The subtraction
> > is undefined, because there's no way to define it and
> > still maintain the properties of pointer arithmetic.
> 
> I would have expected the implicit division of 1 by 527 to always round
> down to zero in practise. It appears to produce zero on most of my
> implementations to hand (lcc-win32, microsoft vc++, borland bcc32), but
> surprisingly not on cygwin gcc, where it produces a ptrdiff_t value of
> -2086359825. Weird.
> 
> <OT> Any explanations? </OT>

Yes. Because the compiler knows that b2 and b1 must be pointing to elements
of the same array, it knows that the difference must be a multiple of 527,
so the division is exact. It exploits this knowledge to turn the division
into a (faster) modulo multiplication, as described in a paper by Granlund &
Montgomery (1994).

In this case, it is performing a modulo-2^32 multiplication by 0x83A4ACEF
(-2086359825), which is equivalent to dividing by 527, but ONLY if the
division is exact.

An excellent example of a compiler optimisation taking advantage of being
allowed to produce undefined behaviour for incorrect code.

-- 
Kevin Bracey, Principal Software Engineer
Tematic Ltd                                   Tel: +44 (0) 1223 503464
182-190 Newmarket Road                        Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom            WWW: http://www.tematic.com/

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:
>
>> 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.

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

>> and in
>> real mode any pointer with the same value of 16*segment+offset
>> points to the same byte, even if the pointers don't compare equal.
>> This is decidedly unlike a flat address space.
>
>I agree with you, that's not flat.
>
>But...
>
>Lots of architectures with MMU's allow the kernel to map multiple addresses
>in userland space to the same hardware address.  Is this flat
>or not flat?

I'd say it's not flat if the multiple mappings are visible to a
single userland program e.g. sharing the C runtime library between
multiple programs doesn't make it non-flat; mmap()ing the same file
into the same program multiple times makes it non-flat.  However,
this is something the program does to itself normally; the OS or
the hardware wouldn't do this on its own.

>Many designs without MMU's but with incomplete address decoding
>will map two addresses to the same memory cell.

Ok, but the 16*segment+offset business is a bit more complex than
simply ignoring some bits.  And you CAN reasonably come up with
pointers to the same place with different segment/offset by invoking
undefined behavior breaking C rules about out-of-bounds pointer
math.

>I suspect that "flat" vs "not flat" is sometimes a continuum rather
>than a one-or-the-other choice.

I'll agree here.  One not-that-obvious non-flattedness present on
many x86-based protected-mode OSs is mapping code space and data
space into the same set of memory, but this is really required to
get what is ordinarily called a flat address space.

						Gordon L. Burditt

gordonb.91ylz@burditt.org (Gordon Burditt) wrote in message news:<c8di83$g6l@library1.airnews.net>...
> >I suspect that "flat" vs "not flat" is sometimes a continuum rather
> >than a one-or-the-other choice.
> 
> I'll agree here.  One not-that-obvious non-flattedness present on
> many x86-based protected-mode OSs is mapping code space and data
> space into the same set of memory, but this is really required to
> get what is ordinarily called a flat address space.

I think the C language specification should work fine on either a
Harvard or von Neumann architecture... I space and D space pointers
can clearly be very different animals.  Given that the original
architectures with C compilers were all von Neumann maybe this is
just happy coincidence, but the more I think about it maybe it's really
a good clean well-thought-out design.

The later PDP-11's had split I/D, which didn't hurt, but none of the
C compilers at that time would complain at all if you did pointer
arithmetic between different spaces.  That's not saying much because
they let you do just about anything without making useful warnings,
and there was no ANSI spec to say what was undefined behavior, that's for
sure :-)

Tim.

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

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.

"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 ...

In <40AC7FD3.7070806@oz.quest.com> Gary Schmidt <Gary.Schmidt@oz.quest.com> writes:

>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).

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

On Tue, 18 May 2004 00:02:39 -0600
August Derleth <see@sig.now> wrote:

> On Mon, 17 May 2004 23:53:07 +0000, Rich Teer wrote:
>=20
> > On Mon, 17 May 2004, Nils O. Sel=E5sdal wrote:
> >=20
> >> > How many Unices for the 8086 and 286 have you seen?
> >> None. And I've neither touched AIX as someone else mentioned here.
> >=20
> > Don't forget SCO's XENIX; that was available for the 80286, IIRC.
>=20
> 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.)
I worked on a Microsoft Xenix port to a Raytheon machine back in 1981.=20
--=20
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9