Hacker News Reader

_chris_on RISC-V: They Should Have Known Better

1B through 15B variable length instruction mess, for one. Which still yields a worse than average 4-5B per instruction average.

_chris_on My thoughts on renting versus buying

Longer time horizon -- mortage inflates away. In the short-term, only need to beat the property tax bill, especially if the interest rate is <3% and the property is increasing in value faster than that.

_chris_on Branch prediction: Why CPUs can't wait?

A BPU needs to predict 3 things:

  - 1) Is there a branch here?
  - 2) If so, is it taken?
  - 3) If so, where to?

If a conditional branch is never taken, then it's effectively a NOP, and you never store it anywhere, so you treat (1) as "no there isn't a branch here." Doesn't get cheaper than that.

Of course, (1) and (3) are very important, so you pick your hashes to reduce aliasing to some low, but acceptable level. Otherwise you just have to eat mispredicts if you alias too much.

Note: (1) and (3) aren't really functions of history, they're functions of their static location in the binary (I'm simplifying a tad but whatever). You can more freely alias on (2), which is very history-dependent, because (1) will guard it.

_chris_on Branch prediction: Why CPUs can't wait?

> A lot of the time this is a hint to the compiler on what the expected paths are so it can keep those paths linear. IIRC, this mainly helps instruction cache locality.

The real value is that the easiest branch to predict is a never-taken branch. So if the compiler can turn a branch into a never-taken branch with the common path being straight line code, then you win big.

And it takes no space or effort to predict never taken branches.

_chris_on Branch prediction: Why CPUs can't wait?

> The thing holding back VLIW was compilers were too dumb

That’s not really the problem.

The real issue is that VLIW requires branches to be strongly biased, statically, so a compiler can exploit them.

But in fact branches are very dynamic but trivially predicted by branch predictors, so branch predictors win.

Not to mention that even vliw cores use branch predictors, because the branch resolution latency is too long to wait for the branch outcome to be known.

_chris_on Pi-hole v6

Wouldn’t a smart tv do something ... smarter than just using the default dns given to it by the network?

I’m not up to speed on this stuff but I thought pihole only blocked the simplest stuff from devices that play nice?

_chris_on T1: A RISC-V Vector processor implementation

It’s not that hard to debug— your signal names and register names all carry through. Sure, lots of temp wires get generated but that’s never where your bug is.

_chris_on Intel Honesty

> allow to select the purchase price within the last 2 years

I don't think that's true. My reading of that is "you lock in the price on your start date and can keep that for the next 2 years going forward". That doesn't help anybody joining at >$1k / share. :D (and that's only ESPP, not standard stock compensation).

_chris_on The Itanic Saga: The History of VLIW and Itanium

> I’d be interested in understanding why the compilers never panned out but have never seen a good writeup on that. Or why people thought the compilers would be able to succeed in the first place at the mission.

It's a fundamentally impossible ask.

Compilers are being asked to look at a program (perhaps watch it run a sample set) and guess the bias of each branch to construct a most-likely 'trace' path through the program, and then generate STATIC code for that path.

But programs (and their branches) are not statically biased! So it simply doesn't work out for general-purpose codes.

However, programs are fairly predictable, which means a branch predictor can dynamically learn the program path and regurgitate it on command. And if the program changes phases, the branch predictor can re-learn the new program path very quickly.

Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work.

_chris_on How to Design an ISA

> L1i matters, people!

RISC-V consistently wins on L1i footprint.

The complaining is about number of dynamic instructions ("path length"), which can hit you if you don't fuse. Of course, path length might not actually be the bottleneck to raw performance, but it's an easy metric to argue, so a lot of people latch on to it.

_chris_on Cascade: CPU fuzzing via intricate program generation

> > Cascade discovered 4 bugs in BOOM and CVA6 that produce wrong output val- ues regardless of the microarchitectural state

> These are unacceptable bugs, showing a lack of architectural tests. It means no one ever ran those instructions and checked the result. The community should be able to fix this.

For BOOM it looks like the only 2 bugs found were miscounting on the inst-retired perf counter if software over-wrote it, and a fdiv.s/fsqrt.s that always listened to the dynamic rounding mode instead of the statically provided rounding mode, when specified. Not great, but recoverable.

_chris_on Cascade: CPU fuzzing via intricate program generation

Looks like from Appendix D that only 2 bugs were found in BOOM:

> 1. Inaccurate instruction count when minstret is written by software

I don't know what that means, but having minstret written by software was definitely not something I ever tested. In general, perf counters are likely to be undertested.

> 2. Static rounding is ignored for fdiv.s and fsqrt.s

A mistake was made in only listening to the dynamic rounding mode for the fdiv/sqrt unit. This is one of those bugs that is trivially found if you test for it, but it turns out that no benchmarking ever cared about this and from all of the fuzzers I used when I worked on BOOM, NONE of them hit it (including commercial ones...). Ooops.

Fixed here: https://github.com/riscv-boom/riscv-boom/pull/629/files

_chris_on RISC-V Origins and Architecture, Part 1

If you want to do some further archeology, check out the SMIPS ISA, which I believe dates back to 2005 (which itself gradually evolved from the T0/Scale/6.371 MIPS ISAs; and the earliest, T0, was derived from MIPS-II).

_chris_on RISC-V Origins and Architecture, Part 1

I also get a permission error: but I think this (https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-ris...) is the same file, and functionally the same as the fa11 version?

I think RDNPC is what I was thinking of, but I can't at all remember what was perceived as "risky" about it. I may be overblowing something from memory. AUIPC is better anyways.

_chris_on RISC-V Origins and Architecture, Part 1

To add to this, Andrew et. al. at Berkeley built SPARC cores, so they were well aware of what it took to implement hardware to run SPARC software. I believe some of the really annoying challenges were at the system/privileged architecture level, including issues where off-the-shelf privileged software was either not obeying the specification or instead relied on undefined/underdefined corner cases. I believe RISCV's atomic read/modify/write CSR behavior was informed from some of these experiences.

_chris_on RISC-V Origins and Architecture, Part 1

I believe early on there was a change to a pre-AUIPC instruction due to potential infringement fears (for PC-relative indexing); but everything else was understood to be following well-worn paths.

_chris_on Advanced Performance Extensions (APX)

And adds non-destructive instructions.

> "In addition, legacy integer instructions now can also use EVEX to encode a dedicated destination register operand – turning them into three-operand instructions and reducing the need for extra register move instructions."

Overall, APX is providing 10% fewer instructions, 10% fewer loads and more than 20% fewer stores.

Also adding pop2/push2 instructions for moving state faster.

And adding more powerful conditional instructions (loads/stores/compares) and flag-suppression.

_chris_on It's done in hardware so it's cheap (2012)

> their clean orthogonal instruction encoding is so inefficient (e.g. it wastes a lot of instruction cache)

Perhaps, although ARMv8 is fixed 4 bytes and x86-64 averages more than 4 bytes an instruction despite each x86 instruction mapping to more than 1.0 uops on average. Oops.

_chris_on Adding custom RISC-V instructions to an open-source rv32 SoC

Custom opcodes have a protected spot in the opcode map; but there's nothing that prevents two different CPUs from using the same custom opcode pattern to mean two different instructions.

Conceivably, you could trap, look up something like the mvendor/march CSRs to triangulate CPUID, and Do the Right Thing, but you usually added a custom opcode because you believe your performance/use-case depends on it.

Basically, your Option #3: "don't distribute binaries with custom instructions." If it's so important, it should get pushed through the standards process and then the binaries can be portable.

_chris_on RISC-V Int. Ratifies 15 New Specs, Opening Up New RISC-V Design Possibilities

Very different. RISC-V's vectors (RVV) are "variable length", so the programmer can request a length and the machine tells you what it can give you. Different machine versions can change the underlying vector size and the code Will Just Work.

This is different from "fixed-width SIMD" which has a hard-coded vector length. To make things more challenging for the programmer/compiler, I believe most x86 SIMD versions also don't provide a "mask" register, so you're stuck with using all vector elements (AVX512 added masks).

Each has its advantages and disadvantages (esp. on the design complexity vs programmer/compiler interface complexity).

RVV also provides a mechanism to reconfigure the register file, ganging logical registers together to get longer effective vector lengths.

_chris_on Nios V – Intel's RISC-V Processor

> They said "5 stage", which sounds to me like no out-of-order fancy stuff of the sort we've been used to.

That's inefficient for an FPGA softcore; wires are too expensive, CAMs are straight up awful, and memory latencies aren't too far off relative to the core clock frequencies to justify OOO stuff in the normal case.

> Well, I wrote a little 5 stage CPU FPGA program once (In Haskell compiled to Verilog :), but that's another story). It wasn't very hard.

Writing a 5 stage is easy.

Writing a 5 stage with no bugs is much harder.

Writing a 5 stage that talks industry standard busses and provides Debug/JTAG Support at high frequency and small gate counts is, well, an actual job.

Not saying you can't do better, but it's not a trivial effort.

_chris_on A Historical Look at the VAX: Microprocessor Economics (2006)

> I wonder if we're ever going to see a 8wide decoder RISC-V.

Considering there are 6-wide x86 cores on the market, I wouldn't be too concerned about RISC-V going wide. The instruction length decode is a 2-bit dependency chain; whereas the renamer-dependency logic builds off of 5-bit register values, which will be the bigger bottleneck.

Note that RISC-V's compressed instructions are trivially decoded with the first 2-bits; there is no further wonkiness about needing to decode the whole instruction before you can know it's true length that can be seen in other ISAs.

_chris_on Intelligence on Sick Staff at Wuhan Lab Fuels Debate on Covid-19 Origin

Lying all the time has consequences.

_chris_on ARM vs. RISC-V Vector Extensions

>> The RISC-V vector registers are in a separate register file not shared with the scalar floating point registers.

> Honestly... in hardware, they probably are actually in the same register file. It just now means you have two sets of architectural registers that rename to the same register file.

You could have a single unified pool of physical registers that can be handed out to any register, but there's only some advantage to do so and a lot of advantages in keeping them separate. Either way, that's a micro-architectural detail that the designers have the freedom to choose (or not choose) to do.

From the software's point of view, there's a lot of advantages in keeping different architectural registers separate.

_chris_on ARM vs. RISC-V Vector Extensions

It looks like RVV will be going up for ratification this summer, so (https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado...) is pretty close to the final version.

_chris_on ARM vs. RISC-V Vector Extensions

> Quote from their white paper: "this is not friendly to deeply pipelined processor architecture."

There is zero reason you can't rename the VL register. "Speculating" that it doesn't change is only one design point.

_chris_on Glacial – Microcoded RISC-V core designed for low FPGA resource utilization

It takes years for tooling to improve and for industry designs to start making it out into the world. As more designs make it into end-users' hands, the tooling has even more motivation to improve.

I feel like that slow evolution can make it appear "suddenly popular" despite being around for a few years. =)

_chris_on Apple’s M1 processor and the full 128-bit integer product

x86-64 code density is more than 4 bytes / instruction.

_chris_on 51 Star Flag (2011)

>> Is there not any wisdom to giving rural areas a counterweight to heavily populated urban areas?

> The founders thought so. It's called the US Senate.

No, they were trying throw a bone to states like Connecticut, Rhode Island and New Jersey, which were land-locked out of Western expansion. It was the more 'rural' states that actually preferred to balance Congressional power on population.

[ed: As the more rural states saw their own populations likely to increase over time. The Senate's existence had absolutely nothing to do about balancing rural vs urban interests].

_chris_on Qualcomm to Acquire Nuvia: A CPU Magnitude Shift

But if you sell out after Series A you should have a ton of equity still left with little dilution?

In this case, it looks like they did a $50M Series A and a $240M Series B. IIRC, 5x is respectable, but I can imagine the VCs might be on multipliers here and eat away quite a bit of the common stock.