[HN Gopher] Intel mulls cutting 16 and 32-bit support, booting s...
___________________________________________________________________
Intel mulls cutting 16 and 32-bit support, booting straight into
64-bit mode
Author : rwmj
Score : 131 points
Date : 2023-05-25 17:15 UTC (5 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| Dwedit wrote:
| Confusingly, cutting out 32-bit mode does not break WOW64, and
| you can still run 32-bit applications. It keeps the ability to
| use the very simplified use of segmentation registers that Win32
| programs use.
| GuB-42 wrote:
| That's fine, but for me, it stops being x86 if it can't run
| legacy code.
|
| A 64-bit only CPU may be a sensible thing, and we can use
| emulators for old stuff, but when we are at it, do we really need
| x86 at all? If we are to break compatibility, couldn't we just
| switch to ARM, RISC-V, or something else? I mean, that's what
| Apple do, they did it successfully, and more than once (68k, PPC,
| x86, ARM), but Apple is Apple, and x86 is (was?) all about
| backwards compatibility.
| CalChris wrote:
| Intel should gut as much cruft as possible, 16+32 bit support is
| cruft for anything with 64 bit, and also double the general
| purpose register set with another REX prefix trick. Indeed, AMD
| should have done this back in 1999.
| mschuster91 wrote:
| > Intel should gut as much cruft as possible
|
| Gutting 32-bit support will kill off a _lot_ of legacy
| applications. Apple could only do it because there aren 't that
| many enterprise applications and they provided reasonably well
| working tooling to ease the effort.
| jcranmer wrote:
| They're not killing userland 32-bit support; they're instead
| killing the 32-bit stuff that doesn't look like modern 64-bit
| stuff from a kernel perspective. (Basically, they're killing
| it at the kernel level, not the user level).
| arcticbull wrote:
| > Gutting 32-bit support will kill off a lot of legacy
| applications.
|
| Nah, they can be emulated. Just as Apple continues to support
| x86 apps on ARM, and supported PowerPC apps on Intel, and
| m68k apps on PowerPC.
| bakugo wrote:
| Except Apple doesn't support 32-bit applications on newer
| versions of macOS regardless of the underlying
| architecture, they effectively killed gaming on Apple
| computers when they decided to remove 32-bit support.
| danudey wrote:
| There is a _huge_ amount of Windows software that 's still
| 32-bit (or at least, installs into `Program Files (x86)`),
| so unless Microsoft is going to start handling that kind of
| emulation natively in their OS (which they may decide to
| do), it's going to break a huge amount of stuff.
|
| Removing 16-bit and 32-bit _OS_ support, on the other hand,
| makes perfect sense.
| danieldk wrote:
| It works both ways. Axing 32-bit support is going to make
| it impossible to use a large collection of software. On
| the other hand, supporting legacy architectures, legacy
| APIs, etc. for decades also makes developers and users
| lazy. There needs to be some balance.
| rstat1 wrote:
| >>so unless Microsoft is going to start handling that
| kind of emulation natively
|
| They already do, and have since the x64 version of XP.
|
| Its called WoW64.
| profile53 wrote:
| WoW64 just handles DLL loading/memory mapping/kernel
| interfaces. It doesn't do binary translation of the user
| code at all. Windows x86 on Windows ARM does binary
| translation.
| lamp987 wrote:
| wow64 is just windows equivalent of linux /lib32/*
| arcticbull wrote:
| Yes, it would have to be done at the OS level. I don't
| see that as a blocker.
| howinteresting wrote:
| Killing off 32-bit x86 support broke many games on Apple
| devices.
|
| A friend of mine loved playing a specific game on her Mac
| that broke, and she was pissed about it for _years_. She
| later built a Windows gaming PC.
| arcticbull wrote:
| I'm not saying Apple executed perfectly, I'm saying Apple
| demonstrates how you can simply and easily emulate older
| systems at the OS level and that we shouldn't block
| hardware development on this. If she wants to play an old
| game there are a ton of options.
| howinteresting wrote:
| Clearly Apple does _not_ demonstrate how you can "simply
| and easily" emulate older systems, given that they broke
| a bunch of games that were merely 5-6 years old at the
| time. They wouldn't have broken compatibility if it was
| "simple" or "easy".
|
| The people that actually demonstrate this to any extent
| are Valve, Microsoft and the people working on Fex.
| Definitely not Apple, and it's definitely not simple, But
| it's still worth doing.
|
| The fact is that if everyone did what Apple did, she
| wouldn't be able to play the game on modern PCs any more.
| I think that is not an acceptable outcome: for archival
| purposes if nothing else, it is important that every game
| ever made be playable forever.
|
| Deprecating 32-bit support means that macOS is never
| going to be a serious gaming platform again. Many games
| are done and never see updates again. At least Asahi is
| going to support older games so you can still use the
| hardware.
| fredoralive wrote:
| The current proposal seems to keep 32 bit support for
| applications (running in Ring 3), just removing support for
| having 32 bit operating systems (in Ring 0).
| somerandomqaguy wrote:
| Wouldn't that kill any hardware that only has 32 bit
| drivers as well?
| kevin_thibedeau wrote:
| Plus all cards with 32-bit option ROMs.
| fredoralive wrote:
| Seeing as Windows 11 joins Mac OS in being 64 bit only
| (at an OS release / kernel level), the hardware is
| presumably already effectively "dead" in terms of being
| able to run on current operating systems anyway.
| drewg123 wrote:
| My understanding is that this kills 32-bit OS support. Eg,
| you can't run a 32-bit Linux / Windows / BSD distro on it.
| However, you can still run legacy 32-bit applications in your
| 64-bit OS.
| MarkusWandel wrote:
| There are ancient 32-bit things that still run on modern
| operating systems, that you simply can't get a 64-bit version of.
| On my Linux machine, one specific such thing is the Brother
| printer driver. Brother laser printers are awesome. Cheap,
| reliable, inexpensive aftermarket toner etc. But to make them
| work (in my experience, and certainly for the scanner function)
| you need their binary driver and it has not (last I looked) been
| updated in years, and it's 32-bit. No problem, install the 32 bit
| compatibility libraries and go.
|
| On a pure 64 bit CPU, unless the 32-bit compatiblity problem is
| solved with emulation at the OS level, all this old 32-bit stuff
| is history. Or does "cutting 32-bit mode" not mean that, i.e.
| 32-bit binaries still run in the 64 bit mode?
| creatonez wrote:
| Intel's press release has a chart explaining that 32-bit
| compatibility will still be possible in Ring 3, but not in Ring
| 0. Not sure what this entails for 32-bit kernel drivers since
| Linux uses a mix of Ring 0 and Ring 3. But I assume this means
| that 32-bit user-mode applications and some drivers will still
| work.
| fweimer wrote:
| 64-bit Linux does not have 32-bit kernel modules.
| bonzini wrote:
| Printer drivers are in user space. 32-bit user programs remain.
| larrik wrote:
| The article says they are dropping support for 32 bit OS's but
| not 32 bit programs, essentially. You'll also still be able to
| emulate 32 bit OS's. they just can't own the hardware at boot.
| circuit10 wrote:
| From another comment:
|
| > You will also still be able to run x86-32 binaries and apps
| in ring three on your 64-bit OS in ring zero - so long as the
| operating system provides the appropriate libraries and APIs,
| of course.
| BaseballPhysics wrote:
| > On a pure 64 bit CPU, unless the 32-bit compatiblity problem
| is solved with emulation at the OS level, all this old 32-bit
| stuff is history.
|
| And you've already answered your own question. Virtualization
| and emulation is precisely how this will be cared for. Heck, in
| a lot of cases, that's _already_ how old 16- and 32-bit
| software is run, as you also need associated compatible
| operating systems, not to mention clock timings and so forth in
| the case of games, and it 's a lot easier and more accurate to
| just fire up DOS or Windows 3.11 in a VM than to run the code
| natively with OS-level compatibility.
| Dwedit wrote:
| 32 bit windows software is not emulated, you call a 32-bit
| API function and it forwards to 64-bit mode at the system
| call level. Basically instead of SYSENTER you proceed back to
| 64-bit mode to perform the system call.
| fallat wrote:
| Time to RE.
| markrages wrote:
| The traditional approach to proprietary printer drivers is to
| found a software movement that reimplements the entire
| operating system from scratch, and invent licenses that
| prevent distributors from keeping their changes to the system
| secret.
|
| This approach has been somewhat successful.
| CrLf wrote:
| "Since its introduction over 20 years ago, the Intel(r) 64
| architecture became the dominant operating mode."
|
| This is how Intel takes credit for AMD's x86-64.
| deaddodo wrote:
| I still shake my head at how they were able to successfully
| rebrand it from amd64 to x86-64; yet ia32 is still semi-
| accepted as the "official" name of x86.
| ghshephard wrote:
| Without going through various repos, I'm struggling to recall
| ever even seeing "x86-64" - It's always amd64 that I look for
| - so the rebrand wasn't that successful.
| milsorgen wrote:
| I remember it a fair bit right after 64 bit became
| mainstream. In the excitement phase it was generally amd64
| then as it became fully established and adopted it was most
| often referred to as x86-64, at least in the press.
| zamadatix wrote:
| I think both are pretty common. E.g. uname -a says x86_64
| and GCC/Clang use x86-64 for defining the target while, on
| the other hand, MSVC (and a lot of Microsoft stuff in
| general) uses amd64 as do many BSDs.
| 908B64B197 wrote:
| > MSVC (and a lot of Microsoft stuff in general) uses
| amd64 as do many BSDs.
|
| That's partly because Microsoft had support for ia32
| (x86) and ia64 (Itanium). So amd64 was to differentiate
| the architecture (and it was unclear Intel would ever
| extend x86).
| viraptor wrote:
| Debian-based systems are slightly confused with dpkg
| architecture returning amd64 and uname returning x86_64.
| usefulcat wrote:
| Compiler explorer (godbolt.org) uses x86-64, as do the man
| pages for gcc and clang. I suspect there are plenty of
| other places too.
| m463 wrote:
| But my filesystem is full of references like
| /usr/lib/x86_64-linux-gnu
| bombcar wrote:
| It makes it clearly different from arm64 at least, which
| may be part of it.
| CodeArtisan wrote:
| AMD64 is specific to AMD, then Intel released EM64T. x86-64
| is the common subset between the two.
| filmor wrote:
| x86-64 was the original name by AMD, they rebranded it
| shortly before commercial availability to AMD64. Kernels and
| compilers had already been updated at that time and just kept
| the "old" name.
| cesarb wrote:
| > I still shake my head at how they were able to successfully
| rebrand it from amd64 to x86-64
|
| It's the opposite: the original name was x86-64, and amd64 is
| a later rebranding. See, for instance, the original web site
| for this (then) new architecture: https://web.archive.org/web
| /20000829042251/http://www.x86-64...
| shiomiru wrote:
| I get the opposite impression: amd64 is something I see quite
| often, while ia32 is pretty much exclusively referred to as
| x86. (Even though for the average user, ia32 would be much
| easier to recognize as "32-bit", and amd64 as "64-bit", both
| of which are often found on download buttons.)
| bombcar wrote:
| Don't forget arm64 which is now appearing.
| askvictor wrote:
| amd64 looks much too similar to arm64 (though that's the
| latter's fault)
| alfalfasprout wrote:
| there'a also `aarch64`
| pgeorgi wrote:
| arm64's official name is AArch64
| naikrovek wrote:
| I don't think that's the case anymore. at the very least
| they are interchangeable names, and I believe that
| "arm64" is the name going forward.
|
| I read this somewhere a couple weeks back, but I don't
| remember the source.
| JoshTriplett wrote:
| amd64 was an attempt to "brand" the 64-bit version of x86,
| just as ia32 was an attempt to "brand" the 32-bit version of
| x86. Many people rejected _both_ and just say x86 and x86-64
| as generic names.
| roqi wrote:
| > amd64 was an attempt to "brand" the 64-bit version of x86
|
| The "64-bit version of x86" is actually the new ISA created
| by AMD that was backwards compatible with x86 and added a
| 64-bit mode.
|
| I'm sure that you agree that the company that creates a ISA
| has the right to name it.
| ed25519FUUU wrote:
| I'm not sure they've been successful. The string amd64 is
| everywhere.
| brundolf wrote:
| Earlier today I used `arch -x86_64` on my mac to run
| something in Rosetta (Intel mode)
| sidewndr46 wrote:
| My understanding is that the cross licensing agreement with AMD
| allows them to license the technology and brand it as their
| own.
| quantified wrote:
| Thank Microsoft for holding up 64-bit Windows until Intel had a
| chip.
| meekaaku wrote:
| First 64 bit windows was running on DEC Alpha. Not Intel or
| AMD
| rbanffy wrote:
| That's true, but most Microsoft software was never ported
| to Alpha. Or Itanium.
|
| So, you could get a 64-bit computer running Windows, but
| you wouldn't be able to play Pinball, or read your emails,
| or run some other software you needed to work.
|
| Oddly enough, the situation was much better with 64-bit
| Unix, where your usual tools worked flawlessly.
| bombcar wrote:
| One of the unsung advantages of having the source
| available; you just need a compiler and some libraries
| and suddenly you have a ton of software even in an
| entirely new architecture.
| macjohnmcc wrote:
| They were doing Windows NT for the Itanium. They were holding
| out hoping that this thing would take off.
| rbanffy wrote:
| I remember they didn't port a lot of stuff to it - it was
| running mostly the BackOffice family of server apps.
|
| I don't think one could run Outlook on them.
| DaiPlusPlus wrote:
| Windows XP x64 Edition was released for AMD64 around
| 2003-2004 before Intel's x64 chips were out, the only CPUs
| were Athlon64.
| lancebeet wrote:
| I recall using XP x64 edition on an Athlon64. I remember it
| having such poor software support that it was barely
| usable. I heard it was actually a version of Windows Server
| that they put the XP GUI on top of, but I'm not sure if
| that's true (Wikipedia only seems to partially corroborate
| it).
| bombcar wrote:
| Windows Server and Client were always much closer than
| appeared at first glance, as long as you lined up the
| versions. So it almost certainly was as described.
| DaiPlusPlus wrote:
| I ran Windows XP x64 on my personal desktop until 2013.
| It was solid and dependable for me, though I did heavily
| customise it (custom Visual Styles themes, disabling
| features I didn't like, some hacks to bring-forward sone
| features from Windows 7, etc)
| RulerOf wrote:
| >I heard it was actually a version of Windows Server that
| they put the XP GUI on top of
|
| In a way, yes. It used the kernel from Server 2003.[1]
| Server/client kernels were unified for Vista SP1 and
| Server 2008, and not sooner just because the 2008 release
| lagged behind Vista's debut.
|
| Prior to Vista, this kernel difference meant drivers for
| Windows server and client often had to be different
| builds. An anecdote that I recall was that although xp64
| and 2003x64 could share drivers, it was typical to see
| drivers "not provided" for xp64, so the people who wanted
| that kernel just ran Windows Server as a desktop OS
| instead.
|
| 1: https://en.wikipedia.org/wiki/Windows_XP_Professional_
| x64_Ed...
| MrBuddyCasino wrote:
| previously: https://news.ycombinator.com/item?id=36006446
| donatj wrote:
| > only two mainstream PC OSes ever actually used more than these
| two rings. One was IBM's OS/2
|
| I'm curious, would this also then affect ArcaOS?
| JdeBP wrote:
| If it's still using IBM code, then it definitely will. IBM's
| OS/2 kernel, even the 32-bit one from 2.0 onwards, had 16-bit
| code and the extra ring usage for IOPL.
|
| Then there's the fact that the rest of it is 32-bit. (-:
| agrover wrote:
| I doubt it. This is probably talking about early versions of
| OS/2, like, pre-2.0.
| fredoralive wrote:
| According to https://www.os2world.com/wiki/index.php/Databook
| _for_OS/2_%E... OS/2 Warp 4 uses Rings 0, 2 and 3.
| bonzini wrote:
| 32-bit Xen also used ring 1.
| creatonez wrote:
| ArcaOS is doomed, to put it mildly. Arca and eComStation were
| never given access to IBM source, so everything is bolted on
| through binary patching.
| xnx wrote:
| Intel gets a lot of criticism for its management, and Apple get a
| lot of credit for the M1, but it's worth keeping in mind the
| tradeoffs/sacrifices for backward compatibility. I'm guessing
| Intel could create something radically more power efficient and
| performant if they gave up on decades worth of drop-in
| compatibility.
| danieldk wrote:
| That's fair. On the other hand, you can still run x86_64
| applications on Apple Silicon through Rosetta. Sure, it's not
| 32-bit x86, but there are ways to provide backwards
| compatibility without supporting decades of legacy in hardware.
| [deleted]
| jeffbee wrote:
| That seems very unlikely. How much overhead do you believe
| there to be? Intel is about equal to apple silicon in
| performance and work per joule and per watt. If either of them
| could do much better, they would.
| brucethemoose2 wrote:
| > create something radically more power efficient
|
| Lots of the M1's efficiency comes from business decisions.
| Apple chooses to use an expensive, low clock TSMC node. They
| use a lot of expensive die area on wide cores and cache, so
| they can keep clocks and voltages (relatively) low. And they
| use packaged memory for efficiency, but at higher cost and with
| no modularity.
|
| Not saying it isn't a great design, but Intel/AMD could make a
| _far_ more efficient CPU if they had the right market
| incentives to try. We have already seen a hint of this with Van
| Gogh (the Steam Deck chip) and their rumored "premium" laptop
| chips with big GPUs and an M1 Pro-like memory bus.
| tracker1 wrote:
| I don't know enough technically to comment on, but am curious
| how this plays into the mobile gaming device SOC/CPUs from
| AMD. I can say, really like my M1 air, generally good enough
| battery life and great i/o responsiveness in general. Of
| course, then I price out a M2 mini, and once I add enough
| storage/ram it's no longer feels worth the price. Why they
| even sell a model with under 512gb storage or 16gb memory
| other than to have a lower "starting from", and even getting
| to 1tb disk and 16gb or 32gb memory already feels like way
| too much of a price hike.
| brucethemoose2 wrote:
| > mobile gaming device SOC/CPUs from AMD
|
| There are none! Van Gogh (in the Steam Deck) was the first
| and last one!
|
| AMD had a whole family of low power (~9W), graphics heavy
| chips on their roadmap... And when the time for the first
| one came, not a _single_ laptop maker picked it up. So AMD
| seemingly canceled the line, but Valve swooped in and used
| the only survivor in their handheld.
|
| What you see in the ROG Zephyrus and such are rebranded
| high power laptop chips, which is why they suck so much
| battery compared to the Steam Deck (even though the Deck
| chip is much older).
| vlovich123 wrote:
| A not insignificant part comes from the fact that they can
| better parallelize instruction decoding because ARM is
| simpler and more regular than x86. x86's compressed variable
| length representation hurts it here. They try to make up for
| it but there's meaningful benefit from Apple's approach. The
| other bit is that ARM concurrency is better aligned with how
| HW wants to work/better able to optimize performance than x64
| is (ability for acquire/release semantics vs sequential)
|
| That being said, it's not like we're talking about
| deprecating that part of the instruction set which they
| really should do (i.e. build your application for x64.risc
| which tells the CPU the instruction set is going to be an
| alternate fixed-representation x64). Could maybe even have a
| special instruction where you can switch out of it
| temporarily so that you have back-compat with normal assembly
| to give software writers time to port.
|
| I'm all in favor of this though. Getting rid of cruft that's
| more than 20 years old is well beyond time.
| masklinn wrote:
| > I'm guessing Intel could create something radically more
| power efficient and performant if they gave up on decades worth
| of drop-in compatibility.
|
| Like the success of IA-64?
| meepmorp wrote:
| I think Itanium was a success for Intel in some respects. It
| effectively killed off PA-RISC, Alpha, and MIPS (outside of
| network hardware).
| JustSomeNobody wrote:
| A lot of this has to do with keeping Microsoft happy, probably.
|
| Once MS skips to ARM, let's see what Intel does.
| vezycash wrote:
| >Once MS skips to ARM
|
| MS has tried at least twice move to ARM and failed woefully -
| Windows RT, Windows 10 on ARM
| tracker1 wrote:
| I think their mistake wasn't necessarily with ARM, so much
| as an exclusive contract with Qualcomm iirc.
| vezycash wrote:
| Here's more
|
| They made the marketing blunder of calling the ARM OS
| "windows" when it couldn't run existing software. It's
| borderline fraud. Many people, (probably most) returned
| their RT devices to the store because of this.
|
| Windows ARM laptops were more expensive, slower, & under-
| speced than x86 ones.
|
| Microsoft restricted software download to store only -
| pretty dumb to me.
|
| x86 Emulation was eventually released after win10 arm was
| released but it was slow and probably wasn't reliable.
|
| Summary, high price but low performance, dumb os
| restrictions, & non existent ecosystem killed ms ARM
| efforts.
| nullindividual wrote:
| They were somewhat successful with WinCE from the late '90s
| to the early '00s.
| skunkworker wrote:
| In my mind I've always been curious what Intel could do with
| fixed width instructions with a newer 64bit ISA.
| bjourne wrote:
| Not much, see https://chipsandcheese.com/2021/07/13/arm-
| or-x86-isa-doesnt-...
| nomoreusernames wrote:
| [dead]
| peterfirefly wrote:
| It is also about removing some I/O instructions entirely and
| removing all others from ring 3 ("userspace"). Removing 16-bit
| addressing support frees up the 67h address size override prefix.
| They also suggest having CS/DS/ES/SS segment override prefixes do
| the same as in 64-bit mode: nothing, which should allow for
| repurposing those 4 entries in the primary opcode map some years
| down the line.
|
| They are suggesting freeing up 5 bytes in primary opcode map in
| all modes (4 for string I/O, 1 for 67h address size override)
| plus 8 bytes in ring 3 (userspace) plus making it possible to
| free up 4 more (segment override prefixes). That means 13 (17)
| free bytes for userspace!
|
| I think part of the plan is to enable more compact encoding of
| certain existing instructions (and allow for compact encoding of
| future instructions).
|
| I think they want to do that to enable wider instruction decoders
| -- more compact encodings => more instructions per
| 16-byte/24-byte/32-byte/whatever size window the decoders look
| at. Wide decoders are inherently harder for x86 than for
| architectures like ARM because there are so many possible
| instruction lengths (all values between 1 and 15 inclusive), so
| they need all the juice they can squeeze out here.
|
| I am surprised they didn't suggest getting rid of the BOUND
| instruction (which is used for the EVEX prefix in 64-bit mode).
|
| And what about HLT? It isn't allowed in ring 3, anyway, so maybe
| they are looking at repurposing that as well?
|
| And INT1, too?
| dontlaugh wrote:
| Wider decoders seems like the most plausible motivation for
| this, yes.
| jcranmer wrote:
| From what I can tell, they're not actually planning on
| reclaiming the opcode space. Instead, they're mapping those
| things to #UD, which allows a hypervisor to emulate those
| instructions for 32-bit guest OSes.
| danudey wrote:
| It still blows my mind that a 64-bit i9-13900K with 24 cores, 36
| MB of cache, and a turbo speed of 5.8 GHz has to pretend to be a
| 16-bit 8086, which had a clock speed of 5-10 MHz and was
| discontinued in 1998, just to properly boot itself.
|
| (An exaggerated oversimplification I know, but still)
| jeffbee wrote:
| Yeah but who, other than the person responsible for the
| firmware that boots the system, cares? These simplifications
| will have zero observable benefits to you. They won't save a
| lot of die space or cost.
|
| The complexity of the far past is so small that it is
| inconsequential today. The PS1 was implemented in spare die
| area of the PS2's USB controller. Time marches on and die space
| becomes free.
| shpx wrote:
| I care. I want to learn the entire thing I'm using, which
| means I appreciate things that are simpler and faster to
| learn. You can say I am a stupid or irrational person not
| worthy of consideration for wanting this but I am who I am
| and I want to spend money on computers that cater to me.
| citrin_ru wrote:
| It very similar to chip die space - modern technologies are
| so complex that to learn how 8086 works is a very small
| effort compare to learning how the latest intel CPUs work.
| And emulation of older generations is a small part of this
| complexity.
| jacquesm wrote:
| In that case you should probably not look at x86 at all.
| It's one of the most convoluted architectures out there,
| especially because it lugs all of that legacy stuff along.
| tedunangst wrote:
| Do you want a computer architecture that replaces and
| obsoletes everything you've previously learned or one that
| evolves and adds new features on top?
| phendrenad2 wrote:
| When people say "who cares?" they generally mean "what non-
| vanishingly-small percentage of people care?" and I think
| that's still an unanswered question!
| bdamm wrote:
| Then you are obviously running OpenBSD on ARM.
| kibwen wrote:
| True that it's invisible to end-users, but it's still a pain
| in the ass to people writing OSes. Lowering the barrier to
| entry even a little bit will be appreciated by hobbyists.
| DSMan195276 wrote:
| From a hobbies point of view I'd actually argue the
| opposite. The nice thing about the old stuff (Ex. the 8259
| PIC support they're removing here) is that it's much
| simpler to get going. They have very large limitations, but
| those don't matter when just starting, and they serve as a
| good stepping stone and learning opportunity before
| eventually moving on to the modern and more complicated
| stuff. Additionally if you're using a bootloader then the
| bulk of this is already solved for you anyway.
| rbanffy wrote:
| The modern stuff is only more complicated because it had
| to be built around and on top of dozens of dead
| civilisations under it.
| t0b1 wrote:
| How so? The bootloader already runs in long mode with UEFI
| and it also takes care of bringing up other cores so this
| is not really a problem in my experience.
| JoshTriplett wrote:
| Linux still needs to use a Startup IPI to bring up other
| CPUs, which starts them running in 16-bit mode at an
| address under 1MB.
|
| Having a fully 64-bit way to bring up other CPUs would
| simplify that.
| monocasa wrote:
| UEFI doesn't really take care of bringing up the other
| cores. There's a way to get access to them, but you have
| to give them back to UEFI before exiting boot services,
| so that doesn't really help your kernel. You still need
| to do the SIPI into x86-16 code to really take control of
| the AP cores.
|
| Even the new way (that isn't actually implemented AFAIK)
| just SIPIs into long mode code, it doesn't use the UEFI
| multicore stuff.
| jkingsman wrote:
| > The PS1 was implemented in spare die area of the PS2's USB
| controller
|
| Whoah, that is WILD. Any info about where I can learn more
| about this?
| nateguchi wrote:
| https://www.copetti.org/writings/consoles/playstation-2/
|
| Under heading "I/O"
| tobz1000 wrote:
| It sounds more like the I/O firmware was running on
| dedicated PS1 hardware:
|
| https://www.theguardian.com/technology/2013/dec/12/ps4-and-
| x...
|
| > The PlayStation 2, meanwhile, had the original
| PlayStation chipset built in, so it ran pretty much any
| PSone title - and when that chip wasn't being used for
| backwards compatibility it doubled as an input/output
| processor, which was pretty canny.
| helf wrote:
| I can't find _anything_ claiming this. This is literally
| the first time I have ever seen this claim.
|
| The original fat PS2 including majority of the PS1 hardware
| physically in the machine. More and more of it got
| offloaded to pure software emulation with later model
| revisions.
|
| I, too, would like to see info on this supposed "spare die
| space on the USB controller" claim. Because it would be
| really neat if true lol
| mikeponders wrote:
| https://www.copetti.org/writings/consoles/playstation-2/#io
|
| Essentially the thicc PS2s include the PS1 chip and
| normally use it for IO and also for PS1 compatibility.
| amluto wrote:
| The OS cares, sadly. When the OS, running one one CPU,
| instructs another CPU to start (which happens -- your system
| boots into your OS and also resumes from suspend with only
| one CPU running OS code), it sends a message called SIPI to
| that CPU. The CPU responds by running OS code, in real mode,
| at an address <1MB. So the OS needs to find valid memory
| below 640kB that doesn't conflict with any other horrible
| legacy use.
|
| Also, the "LA57" 5-level page table design has a little
| whoopsie: you can't switch between 4 and 5 level page tables
| without exiting paged mode entirely.
| meepmorp wrote:
| > The PS1 was implemented in spare die area of the PS2's USB
| controller.
|
| This really confused me until figured out you weren't talking
| about the IBM PS/1 and PS/2.
| Narishma wrote:
| I don't think they are. IBM PS/2 was more than a decade
| before USB.
|
| But then, the PS2 console didn't have USB either, so I'm
| not sure what they're talking about.
| circuit10 wrote:
| > The PlayStation 2 also features two USB ports
|
| https://en.wikipedia.org/wiki/PlayStation_2
| GenerWork wrote:
| PS2 had 2 USB ports on the front, did it not?
| ace2358 wrote:
| Yeh and the original had a FireWire port too!
| meepmorp wrote:
| IIRC, when you boot linux on a mainframe, you load your kernel
| and initrd into a virtual reader device so the machine can load
| it in 80-column punchcard sized chunks.
| rbanffy wrote:
| Fun to think that it's more or less how zVM starts stuff. It
| took me a while to mentally accept the concept of VM that zVM
| (in reality, I was playing with VM/370) has, which is not
| like anything non-mainframe users would be familiar with.
|
| But you can also run Linux directly on an LPAR under the thin
| hypervisor (which I forgot the name) that runs zVM.
|
| The indignity of the mainframe is that it's booted under
| control of an x86 machine that itself boots up as an 8086. At
| least these days the service elements run Linux.
| skissane wrote:
| > But you can also run Linux directly on an LPAR under the
| thin hypervisor (which I forgot the name) that runs zVM.
|
| The name is PR/SM - which, from what I've heard, actually
| started life as a modified version of VM
|
| > The indignity of the mainframe is that it's booted under
| control of an x86 machine that itself boots up as an 8086.
| At least these days the service elements run Linux.
|
| Poor OS/2, no more booting mainframes for it anymore,
| unless they are very old ones
| projektfu wrote:
| And on the PDP-10, it contains a virtual robot to toggle the
| virtual switches on the virtual PDP-11, to load a loader that
| runs the virtual tape drive to load the startup program for
| the PDP-10.
|
| j/k I have no idea how linux boots on Z.
| cbm-vic-20 wrote:
| This actually isn't too far from the truth. The VAX 8800
| series of minicomputers used a cut-down PDP-11 to boot it,
| and to act as a console.
|
| https://en.wikipedia.org/wiki/VAX_8000#VAX_Console
| ithkuil wrote:
| It's even worse than that. If it was just the CPU...
|
| It also simulate an old keyboard controller for the purpose of
| enabling the A20 gate which enables an address line.
|
| https://en.m.wikipedia.org/wiki/A20_line
| bonzini wrote:
| Emulation of the keyboard controller is done by the firmware.
| The processor's support for A20 was tied to port 92h.
| Dwedit wrote:
| The A20 line was famously used to hack the original XBox. By
| clearing A20, you prevent the XBox from booting from the
| hidden ROM, and it boots from regular flash ROM instead.
|
| Some great videos about that on YouTube if you want to look.
| armada651 wrote:
| Support for the A20 gate was actually already dropped as per
| the article you linked:
|
| > Intel no longer supports the A20 gate, starting with
| Haswell.
| jylam wrote:
| It was not needed anymore in Haswell, but the support was
| still there. It isn't supported at all anymore.
| deaddodo wrote:
| The A20 gate was deprecated (and made software-based) in
| Nehalem, then was removed completely in Haswell. It's never
| been a feature of the Zen uarch(s).
| 2OEH8eoCRo0 wrote:
| Slightly off topic but it blows my mind that the 13900K only
| supports 2 memory channels. My 10 year old i7 supported 4 (with
| 8 slots)!
| adgjlsfhk1 wrote:
| this is only kind of true. the 13900k supports 2 channels but
| for ddr5, each channel ends up being split into two smaller
| channels.
| tracker1 wrote:
| Partly to simplify design and reduce cost, partly for market
| segmentation.
| paulddraper wrote:
| What are the downsides of this?
| jacquesm wrote:
| Slow.
| agumonkey wrote:
| I used to rant over this but I kinda like vestigial
| retrocompatibility of that sort.
| russdill wrote:
| Really it is a vast oversimplication. It's only what the system
| is made to look like it's doing, it's actually doing something
| completely different.
|
| https://mjg59.dreamwidth.org/66109.html
| m463 wrote:
| I guess people got used to the 286 rebooting itself to access
| high memory and have allowed these sorts of things ever since.
| layer8 wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=36013257
| kibwen wrote:
| For those wondering about the impact of removing 32-bit support:
|
| _> It will still be possible to start up an x86-32 operating
| system inside a VM - these have to emulate system firmware in any
| case, alongside the emulated graphics cards, network cards and so
| on that they must provide._
|
| _> You will also still be able to run x86-32 binaries and apps
| in ring three on your 64-bit OS in ring zero - so long as the
| operating system provides the appropriate libraries and APIs, of
| course._
| gavaw wrote:
| I'm sure those options will be dog slow and unreliable.
|
| I buy wintel so I can run my software from 15 years ago without
| interference. Literally the only reason I don't buy a mac. If
| they want to take that away, well, good luck to them
| Sohcahtoa82 wrote:
| Considering Intel is merely _considering_ it at this stage
| means they 're probably still several years away from
| actually releasing chips without 16/32-bit support.
|
| By that time, CPUs will be faster, and Intel will have had
| plenty of time to figure out the emulation layer.
|
| These days, how much performance-critical software is even
| being built in 32-bit?
___________________________________________________________________
(page generated 2023-05-25 23:02 UTC)