XPost: alt.folklore.computers, openwatcom.users.c_cpp   
   From: cross@spitfire.i.gajendra.net   
      
   In article <7r6sgktd4p0ae1e3p97hc7h89nloaldbrj@4ax.com>,   
   Paul S Person   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   wrote:   
   >>>On 11/4/25 08:20, Scott Lurndal wrote:   
   >>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:   
   >>>>> On 2025-11-03, Peter Flass  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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)