Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > openwatcom.users.c_cpp > #3676

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

Cross-posted to 3 groups.

Show all headers | View raw

In article <7r6sgktd4p0ae1e3p97hc7h89nloaldbrj@4ax.com>,
Paul S Person  <psperson@old.netcom.invalid> wrote:
>On Fri, 7 Nov 2025 15:50:53 -0000 (UTC), cross@spitfire.i.gajendra.net
>(Dan Cross) wrote:
>
>>In article <10eda8d$3pd45$1@dont-email.me>,
>>Peter Flass  <Peter@Iron-Spring.com> wrote:
>>>On 11/4/25 08:20, Scott Lurndal wrote:
>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>> On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
>>>>>> On 11/3/25 13:24, Lynn McGuire wrote:
>>>>>
>>>>> When I saw this subject line, I thought it was some necroposting to
>>>>> threads from 1990.
>>>>>
>>>>> Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
>>>> 
>>>> There are still people on the internet who swear that the 286 is
>>>> better than sliced bread and refuse to recognize that modern
>>>> architectures are superior.
>>>> 
>>>
>>>I was thinking, are there any segmented architectures today? Most 
>>>disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.)
>>
>>x86_64 is still nominally segmented; what "code segment" the
>>processor is running in matters, even in long mode.  But most of
>>the segment data is ignored by hardware (e.g., base and limits)
>>in 64-bit mode.
>>
>>Of course, it retains a notion of segmentation for a) 16- and
>>32-bit code compatibility, and b) startup, where the processor
>>(still!!) comes out of reset in 16-bit real mode.
>>
>>Intel had a proposal to do away with 16-bit mode and anything
>>other than long mode for 64-bit, but it seems to have died.  So
>>it seems like we'll be stuck with x86 segmentation --- at least
>>for compatibility purposes --- for a while longer still.
>
>This is all very interesting as a summary of where-we-are. Thanks.
>
>Didn't Intel, at one time, plan to replace all xxx8x processors with
>one of the new! shiny! RISC processor?

Well, Itanium was going to sweep all that came before it into
the dustbin of history.

>Only to be defeated when it was pointed out that a whole lot of
>software would have to run on it. Software written for their xxx8x
>processors, segmentation and all.

Nah, that wasn't that big of an issue.  By then, segmentation
was already mostly legacy and systems that really relied on it
had been designed in an era of slow CPUs that could be emulated
in software if you really needed them for installed base
compatibility.

The heyday of x86 segmentation was really over by 1985.  The
80386 was intended to be a processor for the Unix workstation
market, and supported a paged, flat 32-bit address space.  They
shoehorned that into the segmented model by a) increasing the
size of the segment limit and b) adding the "granularity" bit in
segment descriptors that allowed segments to be defined in units
of 4KiB, rather than single bytes.  The upshot was that a
segment could cover the full 32-bit virtual address space; so
the intended use case was that OSes would set up a couple 4GiB
segments at boot, point the segmentation registers at those, and
then work in terms of the paged virtual address space after
that; all of the nasty pre-386 segment stuff would be relegated
to a relatively small part of the system.  So most software that
really used the segmentation stuff had been written for the 286
or earlier, when CPUs were pretty slow and pokey, making
emulation a reasonable path for backwards compatibility.

The bigger problem for Itanium was that, in order to really
perform well, they needed super-smart compilers that could do
the instruction scheduling needed to take advantage of its VLIW
architecture.  Those never came, and so the realized performance
just wasn't there relative to the promises Intel had made for
the architecture.  Meanwhile, a bunch of ex-DEC people went to
AMD and did the AMD64 extensions for x86, which a) performed
pretty decently (at a much lower price-point than Itanium), and
b) was directly backwards compatible with 32-bit x86.  Within,
what, a year or so, Intel had no choice but to copy the design
with their own offering, and the market ran with it.

This was all in the last 90s/early 2000s, but by 2003 or there
abouts it was clear that Itanium was never going to reach its
promises.

Speculating about alternate historical timelines is always fun.
Had IBM chosen the 68k two decades before Itanium, I suspect the
world would be very different: Moto didn't try to push that
design beyond the 68060, which was competitive with the Pentium
at roughly the same time, but didn't have a pipelined FPU;
perhaps it would if Moto had had the kind of capital resources
Intel could bring to bear for Pentium and beyond.  I suspect,
however, that Moto would have dumped the 68k architecture and
we'd all be using some kind of RISC ISA directly.

One final note about Itanium: Intel had tried the VLIW thing
before with the i860, and ran into the same problem: the
compilers of that era just weren't there to make it competitive
for general-purpose compute.  You'd think they'd have learned
that lesson for Itanium, and either done the compiler work
themselves, or funded it externally, _before_ betting so big on
it.

	- Dan C.

Back to openwatcom.users.c_cpp | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: 16:32 far pointers in OpenWatcom C/C++ Peter Flass <Peter@Iron-Spring.com> - 2025-11-02 13:20 -0700
  OT: 2010 posts (was: Re: 16:32 far pointers in OpenWatcom C/C++) Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-03 14:58 +0000
  Re: 16:32 far pointers in OpenWatcom C/C++ Lynn McGuire <lynnmcguire5@gmail.com> - 2025-11-03 14:24 -0600
    Re: 16:32 far pointers in OpenWatcom C/C++ Peter Flass <Peter@Iron-Spring.com> - 2025-11-03 16:25 -0700
      Re: 16:32 far pointers in OpenWatcom C/C++ Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 00:26 +0000
        Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 15:20 +0000
          Re: 16:32 far pointers in OpenWatcom C/C++ Peter Flass <Peter@Iron-Spring.com> - 2025-11-04 09:39 -0700
            Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 17:14 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 17:32 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 17:38 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ David Brown <david.brown@hesbynett.no> - 2025-11-04 21:23 +0100
                Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 22:04 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ David Brown <david.brown@hesbynett.no> - 2025-11-05 08:50 +0100
                Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-05 15:15 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ David Brown <david.brown@hesbynett.no> - 2025-11-06 08:51 +0100
            Re: 16:32 far pointers in OpenWatcom C/C++ Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-04 22:17 +0000
            Re: 16:32 far pointers in OpenWatcom C/C++ cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 15:50 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-07 16:08 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 16:54 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ Paul S Person <psperson@old.netcom.invalid> - 2025-11-07 08:22 -0800
                Re: 16:32 far pointers in OpenWatcom C/C++ cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 17:22 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ Michael S <already5chosen@yahoo.com> - 2025-11-09 11:15 +0200
                Re: 16:32 far pointers in OpenWatcom C/C++ cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-10 09:08 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ scott@slp53.sl.home (Scott Lurndal) - 2025-11-07 17:43 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-07 19:40 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ Peter Flass <Peter@Iron-Spring.com> - 2025-11-08 08:45 -0700
          Re: 16:32 far pointers in OpenWatcom C/C++ Richard Heathfield <rjh@cpax.org.uk> - 2025-11-04 17:12 +0000
            Re: 16:32 far pointers in OpenWatcom C/C++ geodandw <geodandw@gmail.com> - 2025-11-04 12:15 -0500
              Re: 16:32 far pointers in OpenWatcom C/C++ Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 17:21 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-04 22:19 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ rbowman <bowman@montana.com> - 2025-11-05 00:13 +0000
              Re: 16:32 far pointers in OpenWatcom C/C++ cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 16:46 +0000
                Re: 16:32 far pointers in OpenWatcom C/C++ Peter Flass <Peter@Iron-Spring.com> - 2025-11-08 08:47 -0700
                Re: 16:32 far pointers in OpenWatcom C/C++ John Levine <johnl@taugh.com> - 2025-11-08 21:17 +0000
        Re: 16:32 far pointers in OpenWatcom C/C++ Paul S Person <psperson@old.netcom.invalid> - 2025-11-04 08:29 -0800
    Re: 16:32 far pointers in OpenWatcom C/C++ Paul S Person <psperson@old.netcom.invalid> - 2025-11-04 08:32 -0800

csiph-web