Re: 16:32 far pointers in OpenWatcom C/C++

Discussion in 'C Programming' started by Jonathan de Boyne Pollard, Mar 22, 2010.

  1. >
    >
    > I believe the Watcom 32 bit compilers can (or could, maybe removed by
    > now) large model (16 bit selector, 32 bit offset) code.
    >

    OpenWatcom version 1.9 is currently at its first release candidate.
    16:32 far pointer support is, to the best of my knowledge, still there.
    There's no reason to remove it. Indeed, the far pointer capabilities of
    the compiler have been worked on by the developers for this release.
    (Initialization of 16:16 far pointers with static storage duraction has
    been improved. See the release notes for details.)

    > It might be that OS/2 know what to do with that, I don't believe any
    > other OS does.
    >

    One tends to use that sort of thing for systems programming, rather than
    applications programming. In the case of OS/2, for example, there's not
    much scope for using 16:32 far pointers in applications code, which is
    almost always the Tiny model for 32-bit programs, but in kernel mode
    code there are at least a couple of 32-bit segments that one might want
    to work with using far pointers.
     
    Jonathan de Boyne Pollard, Mar 22, 2010
    #1
    1. Advertising

  2. Jonathan de Boyne Pollard

    Ian Collins Guest

    On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:

    Please stop this asinine cross posting.

    --
    Ian Collins
     
    Ian Collins, Mar 22, 2010
    #2
    1. Advertising

  3. In article <>,
    Ian Collins <> wrote:
    >On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:
    >
    >Please stop this asinine cross posting.


    (Reading in comp.lang.c, the funniest and most entertaining newsgroup on
    the Usenet)

    Yes, I was just about to ask where the CLC topicality police were hiding
    out and why they were ignoring this thread. I was about to make the
    usual comment about the double standard - how only the newbies get
    pounded on for being "OT".

    Thanks Ian - you've restored my faith in (what passes for ... in CLC)
    humanity.

    --
    (This discussion group is about C, ...)

    Wrong. It is only OCCASIONALLY a discussion group
    about C; mostly, like most "discussion" groups, it is
    off-topic Rorsharch revelations of the childhood
    traumas of the participants...
     
    Kenny McCormack, Mar 22, 2010
    #3
  4. >
    >
    > Yes, I was just about to ask where the CLC topicality police were
    > hiding out and why they were ignoring this thread.
    >

    Yes. Heaven forbid that the world should discuss a C compiler and the C
    language in newsgroups relevant to that compiler and the C language!
    Emily PostNews would have a fit. I'm not sure how Ian Collins expects
    the rest of us to stop his so-called "asinine" cross-posting for him,
    though.

    Returning to what we were talking about before the silly diversion, I
    should point out that 32-bit applications programming where the target
    is extended DOS or 32-bit Win16 (with OpenWatcom's extender) will also
    occasionally employ 16:32 far pointers of course. But as I said before,
    regular 32-bit OS/2 or Win32 applications programming generally does
    not, since those both use the Tiny memory model, and 16:32 far pointers
    are generally confined to the realms of systems programming on the
    relevant operating systems. (Systems programming on Windows NT usually
    will not involve them, since the gory details of specialized I/O and
    memory accesses are abstracted away within C/C++ macros and library
    functions for systems programmers on Windows NT. But systems
    programming on DOS-Windows 9x/ME and OS/2 may well.)
     
    Jonathan de Boyne Pollard, Mar 22, 2010
    #4
  5. Jonathan de Boyne Pollard

    Peter Flass Guest

    Jonathan de Boyne Pollard wrote:
    >
    > Returning to what we were talking about before the silly diversion, I
    > should point out that 32-bit applications programming where the target
    > is extended DOS or 32-bit Win16 (with OpenWatcom's extender) will also
    > occasionally employ 16:32 far pointers of course. But as I said before,
    > regular 32-bit OS/2 or Win32 applications programming generally does
    > not, since those both use the Tiny memory model,


    Flat memory model.
     
    Peter Flass, Mar 23, 2010
    #5
  6. Branimir Maksimovic <> writes:

    > On Tue, 23 Mar 2010 06:51:18 -0400
    > Peter Flass <> wrote:
    >
    >> Jonathan de Boyne Pollard wrote:
    >> >
    >> > Returning to what we were talking about before the silly diversion,
    >> > I should point out that 32-bit applications programming where the
    >> > target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
    >> > will also occasionally employ 16:32 far pointers of course. But as
    >> > I said before, regular 32-bit OS/2 or Win32 applications
    >> > programming generally does not, since those both use the Tiny
    >> > memory model,

    >>
    >> Flat memory model.

    >
    > Problem with standard C and C++ is that they assume flat memory
    > model.
    > Eg pointer to char can have more than one type, in different
    > addressing modes.


    I think you mean: "The problem with standard C and C++ is that they
    assume a single memory model. In contrast, hardware pointers come in
    many forms in different addressing modes."

    I don't usually comment on language but I kept re-reading what you
    unable to work out what it was you were saying.

    If this is what you did mean, then I agree and I have no other reason
    to post! If you did mean that C assumes a flat memory model, then I'd
    disagree.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Mar 23, 2010
    #6
  7. Branimir Maksimovic <> writes:

    > On Tue, 23 Mar 2010 12:09:27 +0000
    > Ben Bacarisse <> wrote:

    <snip>
    > My English is not that good, thank you for explaining it .
    >
    >> I don't usually comment on language but I kept re-reading what you
    >> unable to work out what it was you were saying.


    Neither is mine, as I have just spotted by re-reading what I wrote!

    [BTW I don't normally have any trouble understanding what you write.]

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Mar 23, 2010
    #7
  8. >
    >>
    >> Returning to what we were talking about before the silly diversion, I
    >> should point out that 32-bit applications programming where the
    >> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
    >> will also occasionally employ 16:32 far pointers of course. But as I
    >> said before, regular 32-bit OS/2 or Win32 applications programming
    >> generally does not, since those both use the Tiny memory model, [...]
    >>

    > Flat memory model.
    >

    It's the same thing. Think about it. In the flat memory model
    DS=ES=SS=CS (modulo the various required differences between code and
    data segment descriptors) and all pointers are near. That's the
    definition of the tiny memory model. The flat memory model is the tiny
    memory model.

    Since we are discussing OpenWatcom, I point to the OpenWatcom Users
    Guide as one place where you can see this for yourself quite easily. In
    the 16-bit Memory Models section, you'll find a Summary of 16-bit Memory
    Models subsection, with a table. In the 32-bit Memory Models section,
    you'll find a Summary of 32-bit Memory Models subsection, with a table.
    Compare the tables in the twain, and you'll see that the row labelled
    "tiny" in the former is labelled "flat" in the latter.

    There's no real distinction between the twain (apart from some
    implementation-specific pre-defined macros). 32-bit flat model
    programming is 32-bit tiny model programming, and 16-bit tiny model
    programming is 16-bit flat model programming. In all, near pointers to
    automatic storage data, heap storage data, static storage data, and code
    can be casted to one another without differences in assumed segment
    registers causing problems. In all, the code generator doesn't emit
    segment re-loads, or even segment overrides, when using the default
    pointer sizes. In all, near forms of instructions are used.
     
    Jonathan de Boyne Pollard, Mar 23, 2010
    #8
  9. Jonathan de Boyne Pollard

    Nick Guest

    Jonathan de Boyne Pollard <>
    writes:

    PLEASE! Don't cut all the attributions. I've seen you asked this more
    than once in a different newsgroup in the last few days and you've
    ignored the requests. Please listen to them.

    >>
    >>>


    [content snipped]
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
     
    Nick, Mar 23, 2010
    #9
  10. Jonathan de Boyne Pollard

    Richard Bos Guest

    Ian Collins <> wrote:

    > On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:
    >
    > Please stop this asinine cross posting.


    That crossposting was, for once, not asinine. It served as a nice
    example why, even now, Leenux weenies are not correct when they insist
    that C has a flat memory model and all pointers are just numbers.

    Richard
     
    Richard Bos, Mar 23, 2010
    #10
  11. Jonathan de Boyne Pollard

    Guest

    On Mar 23, 12:18 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
    > wrote:
    > >> Returning to what we were talking about before the silly diversion, I
    > >> should point out that 32-bit applications programming where the
    > >> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
    > >> will also occasionally employ 16:32 far pointers of course.  But as I
    > >> said before, regular 32-bit OS/2 or Win32 applications programming
    > >> generally does not, since those both use the Tiny memory model, [...]

    >
    > > Flat memory model.

    >
    > It's the same thing.  Think about it.  In the flat memory model
    > DS=ES=SS=CS (modulo the various required differences between code and
    > data segment descriptors) and all pointers are near.  That's the
    > definition of the tiny memory model.  The flat memory model is the tiny
    > memory model.



    Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
    same selector), CS contains a *different* selector than the other
    three segment registers in flat model. The descriptor for the CS
    selector specifies the same base address and limit (usually), and thus
    overlaps the data descriptor referenced by the other segment
    registers, so all of them address the same memory. But they are not
    interchangeable - while you could load the code selector into DS, an
    attempt to store data would then generate an exception. Conversely
    attempting to load a data selector into CS will trigger an exception.

    This is different from the real-mode "tiny" model, where CS would be
    loaded with the same segment value as DS, ES and SS. So I’d have to
    say that using “tiny model” to mean “flat model” is at least slightly
    incorrect.
     
    , Mar 23, 2010
    #11
  12. In alt.sys.pdp10 Richard Bos <> wrote:
    (snip)

    > That crossposting was, for once, not asinine. It served as a nice
    > example why, even now, Leenux weenies are not correct when they insist
    > that C has a flat memory model and all pointers are just numbers.


    Well, you could also read the C standard to learn that.

    There are additional complications for C on the PDP-10.

    -- glen
     
    glen herrmannsfeldt, Mar 23, 2010
    #12
  13. Jonathan de Boyne Pollard

    Peter Flass Guest

    Branimir Maksimovic wrote:
    > On Tue, 23 Mar 2010 06:51:18 -0400
    > Peter Flass <> wrote:
    >
    >> Jonathan de Boyne Pollard wrote:
    >>> Returning to what we were talking about before the silly diversion,
    >>> I should point out that 32-bit applications programming where the
    >>> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
    >>> will also occasionally employ 16:32 far pointers of course. But as
    >>> I said before, regular 32-bit OS/2 or Win32 applications
    >>> programming generally does not, since those both use the Tiny
    >>> memory model,

    >> Flat memory model.

    >
    > Problem with standard C and C++ is that they assume flat memory
    > model.


    I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
    as I know there's nothing in the C standard that assumes anything about
    pointers, except that they have to be the same size as int, so for 16:32
    pointers I guess you'd need 64-bit ints.

    As far as implementations are concerned, both Watcom and IBM VA C++
    support segmented memory models. These are the ones I'm aware of, there
    are probably more.
     
    Peter Flass, Mar 23, 2010
    #13
  14. >
    >>
    >> It's the same thing. Think about it. In the flat memory model
    >> DS=ES=SS=CS (modulo the various required differences between code and
    >> data segment descriptors) and all pointers are near. That's the
    >> definition of the tiny memory model. The flat memory model is the
    >> tiny memory model.
    >>

    > Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
    > same selector), CS contains a *different* selector than the other
    > three segment registers in flat model. [...]
    >

    That's not being pedantic. That's simply ignoring what I put in the
    parentheses. It's also commits the common "just to be pedantic" error
    of being outright wrong if one really were being pedantic. (-: If you
    look at what an x86 processor actually does with the segment descriptor
    cache in real and v8086 modes, you'll see that in fact there are
    differences between CS on the one hand and DS/ES/SS on the other in
    real/v8086 mode, which you are incorrectly asserting to be the sole
    domain of the tiny model, just as there are differences between the two
    in protected mode, which you are incorrectly asserting to be the sole
    domain of the flat model. Both real/v8086 and protected modes make this
    distinction, and this is not, therefore, something that distinguishes
    the flat model from the tiny model. Processor execution modes and
    program memory models are largely disjoint concepts.

    There are plenty of articles by Robert R. Collins in Dr Dobbs' Journal
    from the late 1990s on this subject that one can read for onesself,
    which I'm not going to laboriously re-hash. A breif précis only then:
    Whilst the documentation may suggest that the descriptor cache is
    ignored in real and v8086 modes, the reality is that in real and v8086
    modes the segment descriptors are still re-loaded with appropriate
    (hardwired) values upon a re-load of any segment register, and the
    values in the descriptor registers are not wholly ignored but are in
    fact still used by the address calculation hardware. The idea that the
    CS segment descriptor is the same as the DS/ES/SS segment descriptors in
    the tiny model, because only the selector register values themselves
    count in real/v8086 modes, is thus a falsehood. The segment descriptors
    have effect in all three of real, v8086, and protected modes. Moreover,
    this effect has much the same split in real/v8086 modes as in protected
    mode. There's special-case processing for the CS segment descriptor in
    real/v8086 modes that differentiates it from the DS/ES/SS segment
    descriptors. The supposed lack of distinction amongst or use of segment
    descriptors, that makes flat model a protected-mode-only thing and tiny
    model a real/v8086-mode-only thing, is bogus. Read Robert R. Collins'
    articles for a lot more on this.

    As I said before, the two are, in reality, only really distinguished by
    some pre-defined macros. Those macros aside, the C/C++ language pointer
    semantics that one sees, with all pointers being near pointers, the
    things that the code generator does, with no selector re-loads or
    segment register overrides employed, and the instruction forms used,
    with all instructions using their near address forms, are the same for
    both flat and tiny models.
     
    Jonathan de Boyne Pollard, Mar 23, 2010
    #14
  15. Jonathan de Boyne Pollard

    Flash Gordon Guest

    Peter Flass wrote:
    > Branimir Maksimovic wrote:
    >> On Tue, 23 Mar 2010 06:51:18 -0400
    >> Peter Flass <> wrote:
    >>
    >>> Jonathan de Boyne Pollard wrote:
    >>>> Returning to what we were talking about before the silly diversion,
    >>>> I should point out that 32-bit applications programming where the
    >>>> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
    >>>> will also occasionally employ 16:32 far pointers of course. But as
    >>>> I said before, regular 32-bit OS/2 or Win32 applications
    >>>> programming generally does not, since those both use the Tiny
    >>>> memory model,
    >>> Flat memory model.

    >>
    >> Problem with standard C and C++ is that they assume flat memory
    >> model.

    >
    > I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
    > as I know there's nothing in the C standard that assumes anything about
    > pointers, except that they have to be the same size as int, so for 16:32
    > pointers I guess you'd need 64-bit ints.


    There is no requirement in the standard that pointers are the same size
    as int. In fact, there is no requirement that there is *any* integer
    type the same size (or as large as) a pointer. There is also no
    requirement that pointers of all types are the same size.

    > As far as implementations are concerned, both Watcom and IBM VA C++
    > support segmented memory models. These are the ones I'm aware of, there
    > are probably more.


    I'm sure there have been a number of processors with segmented
    architectures, and that a number of them will have had C compilers, so
    there are almost certainly more.
    --
    Flash Gordon
     
    Flash Gordon, Mar 23, 2010
    #15
  16. Jonathan de Boyne Pollard

    Seebs Guest

    On 2010-03-23, Peter Flass <> wrote:
    > I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
    > as I know there's nothing in the C standard that assumes anything about
    > pointers, except that they have to be the same size as int, so for 16:32
    > pointers I guess you'd need 64-bit ints.


    Uh, no. Pointers do not have to be the same size as int. It's not even
    strictly guaranteed that there is *ANY* integer type that is the same size
    as a pointer, but if there is an integer that can safely hold pointer
    values, it should be available as intptr_t in C99. In C89, there was nothing.

    So, no, pointer does not have to be the same size as int, and I've used
    plenty of systems where it wasn't.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Mar 23, 2010
    #16
  17. Jonathan de Boyne Pollard

    Guest

    On Mar 23, 5:06 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
    > wrote:
    > >> It's the same thing.  Think about it.  In the flat memory model
    > >> DS=ES=SS=CS (modulo the various required differences between code and
    > >> data segment descriptors) and all pointers are near.  That's the
    > >> definition of the tiny memory model.  The flat memory model is the
    > >> tiny memory model.

    >
    > > Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
    > > same selector), CS contains a *different* selector than the other
    > > three segment registers in flat model. [...]

    >
    > That's not being pedantic.  That's simply ignoring what I put in the
    > parentheses.  It's also commits the common "just to be pedantic" error
    > of being outright wrong if one really were being pedantic.  (-:  If you
    > look at what an x86 processor actually does with the segment descriptor
    > cache in real and v8086 modes, you'll see that in fact there are
    > differences between CS on the one hand and DS/ES/SS on the other in
    > real/v8086 mode, which you are incorrectly asserting to be the sole
    > domain of the tiny model, just as there are differences between the two
    > in protected mode, which you are incorrectly asserting to be the sole
    > domain of the flat model.  Both real/v8086 and protected modes make this
    > distinction, and this is not, therefore, something that distinguishes
    > the flat model from the tiny model.  Processor execution modes and
    > program memory models are largely disjoint concepts.



    OK, to quote you: "In the flat memory model DS=ES=SS=CS (modulo the
    various required differences between code and data segment
    descriptors) and all pointers are near." The last part is certainly
    true ("all pointers are near"), and the parenthetical is reasonably
    correct (the code descriptor must be somewhat different than the data
    descriptor). The pedantic correction has to do with the assertion
    "DS=ES=SS=CS". Without additional comment this is manifestly untrue
    in flat model, as you could execute the following code:

    mov ax,ds
    mov bx,cs
    cmp ax,bx

    and the Z flag will *not* be set. The contents of those registers
    are, to a resonable extent (at least so long as the program avoid
    trying to store via CS) *logically* equivilent, but certainly they are
    not equal. And equality is what is specified by the chosen operators
    in "DS=ES=SS=CS". Practical difficulties aside (as in it's not an
    ASCII character), the triple-bar equivalence symbol would certainly
    make *your* meaning clear, but you simply can't assume that as the
    default interpretation of "=".

    The correction is also pedantic (in the common sense of minutia)
    because most flat model application never attempt to store through CS,
    and never actually inspect or modify the values in the segment
    registers, so for them there is no practical difference between
    equality and equivalence.

    In real mode, ignoring some of the odder effect possible from getting
    unusual values loaded into the descriptor cache, the values in the
    segment register *are* equal (and also logically equivalent, but
    that's trivial).


    (...true but irrelevant stuff about descriptor cache operation
    snipped...)


    > As I said before, the two are, in reality, only really distinguished by
    > some pre-defined macros.  Those macros aside, the C/C++ language pointer
    > semantics that one sees, with all pointers being near pointers, the
    > things that the code generator does, with no selector re-loads or
    > segment register overrides employed, and the instruction forms used,
    > with all instructions using their near address forms, are the same for
    > both flat and tiny models.



    I never disagreed with any of that.
     
    , Mar 24, 2010
    #17
  18. On 23 Mar, 20:56, glen herrmannsfeldt <> wrote:
    > In alt.sys.pdp10 Richard Bos <> wrote:
    > (snip)
    >
    > > That crossposting was, for once, not asinine. It served as a nice
    > > example why, even now, Leenux weenies are not correct when they insist
    > > that C has a flat memory model and all pointers are just numbers.

    >
    > Well, you could also read the C standard to learn that.


    but if you say that you get accused of language lawyering.
    "Since IBM stopped making 360s no C program ever needs to run on such
    a platform"


    > There are additional complications for C on the PDP-10.
     
    Nick Keighley, Mar 24, 2010
    #18
  19. Jonathan de Boyne Pollard

    Dann Corbit Guest

    In article <1e27d5ee-a1b1-45d9-9188-
    >,
    says...
    >
    > On 23 Mar, 20:56, glen herrmannsfeldt <> wrote:
    > > In alt.sys.pdp10 Richard Bos <> wrote:
    > > (snip)
    > >
    > > > That crossposting was, for once, not asinine. It served as a nice
    > > > example why, even now, Leenux weenies are not correct when they insist
    > > > that C has a flat memory model and all pointers are just numbers.

    > >
    > > Well, you could also read the C standard to learn that.

    >
    > but if you say that you get accused of language lawyering.
    > "Since IBM stopped making 360s no C program ever needs to run on such
    > a platform"


    We have customers who are running their business on harware from the mid
    1980s. It may sound ludicrous, but it if solves all of their business
    needs, and runs solid 24x365, why should they upgrade?

    > > There are additional complications for C on the PDP-10.
     
    Dann Corbit, Mar 24, 2010
    #19
  20. Jonathan de Boyne Pollard

    Richard Bos Guest

    Peter Flass <> wrote:

    > Branimir Maksimovic wrote:


    > > Problem with standard C and C++ is that they assume flat memory
    > > model.


    Nonsense.

    > I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
    > as I know there's nothing in the C standard that assumes anything about
    > pointers, except that they have to be the same size as int,


    There is absolutely nothing in the C Standard that requires pointers to
    have the size of int, or even the size of anything whatsoever, except
    that
    - void pointers and char pointers shall have the same representation
    (and therefore size) as one another - _not_ necessarily as any other
    kind of pointer, though since void pointers must be able to be freely
    convertible from and to other object pointers, it takes a perverted
    implementation to make them _smaller_ than other object pointers (but
    perversion, though not advised, is allowed implementation authors);
    - pointers to const <foo> must have the same representation as pointers
    to <foo> and vice versa, and ditto for volatile and restrict;
    - all pointers to struct must have the same representation, and all
    pointers to union (but struct pointers need not be the same as union
    pointers; again, it would usually be silly not to have them be, but
    it's allowed).
    Nothing about ints there.

    Richard
     
    Richard Bos, Mar 24, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rolf Hemmerling
    Replies:
    3
    Views:
    778
    Roger Leigh
    Oct 31, 2003
  2. Andy Dingley
    Replies:
    45
    Views:
    1,686
    Andy Mabbett
    Jun 11, 2006
  3. RC
    Replies:
    2
    Views:
    457
    Chase Preuninger
    Jan 8, 2008
  4. rfasuma
    Replies:
    1
    Views:
    550
    Lionel B
    Feb 25, 2008
  5. Nickolai Leschov

    news://news.openwatcom.org doesn't respond

    Nickolai Leschov, Sep 18, 2008, in forum: C Programming
    Replies:
    0
    Views:
    305
    Nickolai Leschov
    Sep 18, 2008
Loading...

Share This Page