Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never Bet Against x86

osnews.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Never Bet Against x86

#61

Post by mifydev »

M95D wrote: post #50
cmrdporcupine wrote: post #40

Earlier quoted context omitted.

Really when people say x86 now tho they don't mean that. They really mean the variant introduced with the 386 which has a linear memory model, memory protection, etc. Or x86_64 which is philosophically akin to the 386 but really a new ISA. So it's really more like mid-80s or early 2000s, not late 70s.

^ that! You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.

You can just boot freedos to run them, it will execute in real mode which has the same cpu instructions as 40 years ago.

Re: Never Bet Against x86

#62

Post by pjmlp »

trvz wrote: post #2

Seems like a silly thing to say right when x86 is getting pummelled to death by Apple and Valve, maybe slowly, but steadily, while the rest of the gang also watches on.

People should look into consumer market share numbers before commenting.

Re: Never Bet Against x86

#63

Post by pjmlp »

beagle3 wrote: post #21
gaigalas wrote: post #13

Earlier quoted context omitted.

That is actually addressed in the article. Several architectures "pummelled" x86 before. PowerPC, for example. They did not stood the test of time though.

What they did not win was the popularity contest, mostly thanks to Windows - the Wintel market was just too massive to compete with. But that’s changed somewhat - Apple has managed a larger mind and market share (while switching into ARM). The vast majority of uses are now available on the web, which is CPU agnostic, and there is a huge amount of open source software available. The only things for which x86 still shi…

Most people outside US, and similar G8 countries, aren't going to pay Apple.

Re: Never Bet Against x86

#64

Post by M95D »

fragmede wrote: post #57
M95D wrote: post #49

Earlier quoted context omitted.

> my worry is that ARM devices will bring an end to such an open platform like modern PCs are. Modern PCs are NOT open platform anymore. Not since signed bootloaders, UEFI, secure boot. ARM on the other hand, as long as they don't require signed bootloaders (like phones) or a closed source driver for GPU or something, are in fact open.

You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.

I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .

Re: Never Bet Against x86

#66

Post by M95D »

anthk wrote: post #56
M95D wrote: post #50

Earlier quoted context omitted.

^ that! You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.

No, you are wrong. DOS COM files if 16 bit can't be run on 64 bit CPU's but 32 bit DOS binaries can be run under 32 bit GNU/Linux installs with DosEMU straight by just emulating the BIOS part, the rest is native.

You actually confirmed what I said. :)

Re: Never Bet Against x86

#67

Post by M95D »

mifydev wrote: post #61
M95D wrote: post #50

Earlier quoted context omitted.

^ that! You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.

You can just boot freedos to run them, it will execute in real mode which has the same cpu instructions as 40 years ago.

UEFI switches the CPU into 32bit v86 mode or directly in 64bit mode and you can't go back to real mode without a CPU reset, which v86 won't allow (you don't have ring -2 privileges) and 64bit mode can't do at all. I don't have a UEFI system, so I might be wrong (I even hope I'm wrong - it would mean slightly more freedom still exists), but from what I read about it, I'm 90% certain it's not possible.

Re: Never Bet Against x86

#68

Post by M95D »

anthk wrote: post #51

ARM device trees suck. ACPI for sure it's hell, but a DTB per device it's a damn disaster. U-Boot it's open, but it sucks at having to plug a damn USB-serial cable in 2026 in order to get a prompt . That should come builtin, and with an easy builting help or some text based menu.

It's either a DTB per device or a firmware blob per device. I'll take the open source device tree anytime!

Re: Never Bet Against x86

#69

Post by rep_lodsb »

M95D wrote: post #67
mifydev wrote: post #61

Earlier quoted context omitted.

You can just boot freedos to run them, it will execute in real mode which has the same cpu instructions as 40 years ago.

UEFI switches the CPU into 32bit v86 mode or directly in 64bit mode and you can't go back to real mode without a CPU reset, which v86 won't allow (you don't have ring -2 privileges) and 64bit mode can't do at all. I don't have a UEFI system, so I might be wrong (I even hope I'm wrong - it would mean slightly more freedom still exists), but from what I read about it, I'm 90% certain it's not possible.

You're confusing several things here. The only x86 processor that didn't allow returning to real mode was the 16-bit 80286 - on all later ones it's as simple as clearing bit 0 of CR0 (and also disabling paging if that was enabled).

Nothing more privileged than ring 0 is required for that.

"v86" is what allowed real mode to be virtualized under a 32-bit OS. This is no longer available in 64-bit mode, but the CPU still includes it (as well as newer virtualization features which could be used to do the same thing).

Re: Never Bet Against x86

#70

Post by craftkiller »

M95D wrote: post #60
craftkiller wrote: post #28

Earlier quoted context omitted.

> can you even have something similar to IBM PC with ARM Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.

Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.

The person I was replying to was specifically asking for ACPI for ARM and they specifically stated their negative opinion of device tree.
Post reply on HN