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

91–100 of 124 posts

Re: Never Bet Against x86

#91

Post by pseudohadamard »

adrian_b wrote: post #48
davidkwast wrote: post #27

Earlier quoted context omitted.

RISC-V can be essential for this open future

RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed. Any competent computer engineer can design a much better ISA than RISC-V. The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compile…

  I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty
Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard, could leave out overflow detection. I'm not saying it's a good idea, in fact it's complete and utter braindamage, but I can see where they got it from.

Re: Never Bet Against x86

#92

Post by pseudohadamard »

phendrenad2 wrote: post #8

I don't think my gaming PC will ever use an ARM core. When you want true "big iron" you want x86. Intel and AMD have a duopoly on high-performance, no-TDP-spared chips, and they aren't sharing that market with anyone. The reason ARM is making inroads in the server market is we've reached the point where cooling is a significant cost factor in server farms, so lowering TDP is starting to become a relevant factor in to…

Also when the CPU is just an I/O peripheral for the NPU/TPU it doesn't matter so much what the architecture is.

Re: Never Bet Against x86

#93

Post by yjftsjthsd-h »

pabs3 wrote: post #89
mjg59 wrote: post #85

Earlier quoted context omitted.

What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.

Which x86 devices ship with a free UEFI/ACPI? Or even allow users to replace the preinstalled UEFI/ACPI with a free one?

> Which x86 devices ship with a free UEFI/ACPI?

https://doc.coreboot.org/distributions.html seems to say Purism, Star Labs, and System76

(Edit: actually weirdly enough Librem seems to be using a different coreboot payload instead of edk2, but the other 2 stand)

> Or even allow users to replace the preinstalled UEFI/ACPI with a free one?

So many Chromebooks: https://docs.mrchromebox.tech/docs/supported-devices.html

Re: Never Bet Against x86

#94

Post by snvzz »

pseudohadamard wrote: post #91
adrian_b wrote: post #48

Earlier quoted context omitted.

RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed. Any competent computer engineer can design a much better ISA than RISC-V. The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compile…

I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard,…

The premise that the ISA has no means for detecting integer overflow is false.

This is explicitly documented in the spec, even.

e.g.

    add   t2, t0, t1
    bltu  t2, t0, overflow
The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.

Re: Never Bet Against x86

#95

Post by rep_lodsb »

snvzz wrote: post #94
pseudohadamard wrote: post #91

Earlier quoted context omitted.

I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard,…

The premise that the ISA has no means for detecting integer overflow is false. This is explicitly documented in the spec, even. e.g. add t2, t0, t1 bltu t2, t0, overflow The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.

That only works for unsigned integers.

Re: Never Bet Against x86

#96

Post by snvzz »

rep_lodsb wrote: post #95
snvzz wrote: post #94

Earlier quoted context omitted.

The premise that the ISA has no means for detecting integer overflow is false. This is explicitly documented in the spec, even. e.g. add t2, t0, t1 bltu t2, t0, overflow The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.

That only works for unsigned integers.

Refer to the spec for the official idioms to handle every case.

Re: Never Bet Against x86

#97

Post by rep_lodsb »

snvzz wrote: post #96
rep_lodsb wrote: post #95

Earlier quoted context omitted.

That only works for unsigned integers.

Refer to the spec for the official idioms to handle every case.

Yes, you can detect signed overflow that way, but it's a lot more instructions so it won't be used in practice.

The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

Re: Never Bet Against x86

#98

Post by snvzz »

rep_lodsb wrote: post #97
snvzz wrote: post #96

Earlier quoted context omitted.

Refer to the spec for the official idioms to handle every case.

Yes, you can detect signed overflow that way, but it's a lot more instructions so it won't be used in practice. The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

>but it's a lot more instructions so it won't be used in practice.

It will be used when it needs to be handled. e.g. where elsewhere, an exception would actually handle it. Which is seldom the case.

More instructions doesn't mean slower, either. Superscalar machines have a hard time keeping themselves busy, and this is an easily parallelizable task.

>The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

Refer to "Computer Architecture: A Quantitative Approach" by by John L. Hennessy and David A. Patterson, for the actual methodology followed.

Re: Never Bet Against x86

#99

Post by camel-cdr »

rep_lodsb wrote: post #95
snvzz wrote: post #94

Earlier quoted context omitted.

The premise that the ISA has no means for detecting integer overflow is false. This is explicitly documented in the spec, even. e.g. add t2, t0, t1 bltu t2, t0, overflow The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.

That only works for unsigned integers.

Signend 64-bit is the worst case. When I tried to enable overflow checking thr overhead of RISC-V and Arm was comparable: https://news.ycombinator.com/item?id=46588159#46668916

Re: Never Bet Against x86

#100

Post by beagle3 »

pjmlp wrote: post #82
beagle3 wrote: post #77

Earlier quoted context omitted.

No, but Microsoft are also going arm. Where the us goes, the world goes eventually.

Microsoft keeps trying to go ARM for a decade already, most Windows devs and consumers don't care, backwards compatibility rules on PC world, regardless of Prism and ARM64EC. Additionally beware what to wish for, as CoPilot+ PC are locked down with Pluton security processor, from XBox and Azure Sphere.

The x86 emulation for fallback is (I’ve heard - not tried) usable for the first time.

Microsoft tried in the past without a Rosetta equivalent; Apple succeeded twice with Rosetta. They did not try to switch cold turkey the way Microsoft did.

Post reply on HN