cwzwarich

Rust actually already does this to some degree, using LLVM’s noalias annotations (after many years of exposing latent LLVM bugs and having to disable them). There’s more that can be done here, see e.g.

https://github.com/rust-lang/rust/issues/16515

There are also soundness issues around async/await:

https://github.com/rust-lang/rust/issues/63818

LLVM’s aliasing model isn’t really optimal for a language like Rust with very precise memory dependence information, but using anything else would mean making a whole new optimizer/backend from scratch.

The Rust compiler has several unsoundness bugs that are years old. If you trusted Rust language security in the kernel, these would all be security holes.

Even though AMD filed the patent a few years later, this was actually from NextGen, who AMD acquired:

https://en.wikipedia.org/wiki/NexGen

Here's an old BYTE article from 1994:

https://halfhill.com/byte/1994-6_cover-nexgen.html

Actually, you're both right. One of the explanations (albeit, not the only one) given for why boiled wine remains kosher if handled by non-Jews is that it's considered unacceptable for non-Jews to use in idolatrous rituals.

> Why is everything in craft brew now shipping in cans instead of bottles? When did that happen?

- They block all light

- They’re better sealed than bottles

- They weigh less and are more compact than bottles

- They don’t break

- They’re more often recycled

The freshness reasons probably correlate with the rise of hazy IPAs, which are more sensitive to freshness than other styles.

Unit propagation (a major component of CDCL-based SAT solvers) is P-complete, and thus has no effective parallel algorithm.

TL;DR: they bridged Elm with React, and when they started using Web Components there was an impedance mismatch between the bridges between Elm/React and WebComponents and the bridge between Elm and React, so they had to pick one of Elm and React.

Anyone know what's new in this edition? Both the publisher's site and the author's site are light on details.

If you take this idea to its logical conclusion, you end up with Predictive LR(k) (or PLR(k)) grammars:

https://link.springer.com/article/10.1007/BF01934444

These are essentially the LR(k) grammars that become LL(k) with a combination of a left-corner transform (to eliminate left recursion) and factorization of common prefixes.

> You can build highly sound-proof timber-framed walls, but most people don't because it's more expensive. Like everything in modern construction, the cheapest permissible option usually wins.

Especially when reduced cost is the reason mid-rise wood construction became popular in the first place.

As far as I can tell, the correct way to handle units of measurement in a programming language is by extending unification to abelian groups, as in Andrew Kennedy's work that was later implemented in F#:

https://www.microsoft.com/en-us/research/publication/relatio...

This seems superior to the GNAT solution. And support for dimensionality is somewhat orthogonal to the ergonomics of converting e.g. a u32 to a u64 that comes up in systems programming.

Rust's handling of numeric conversions is broken IMO. Implicit conversions to wider types that never overflow should be allowed, and the "as" operator shouldn't silently ignore overflow. I should also be allowed assume that usize is at least 32-bit, instead of requiring a fallible conversion. I really doubt pervasive support for 16-bit architectures is important enough to justify inconveniencing everyone else.

> The C abstract machine, despite looking a lot like a PDP-11, leaks the underlying memory and ordering semantics of the architecture being targeted. The result is that even seasoned C programmers regularly rely on architecture-specific assumptions when writing ostensibly cross-platform code: assumptions about the atomicity of reads and writes, operation ordering, coherence and visibility in self-modifying code, the safety and performance of unaligned accesses, and so forth. Each of these, apart from being a potential source of unsafety, are impossible to detect statically in the general case: they are, after all, perfectly correct (and frequently intended!) on the programmer’s host architecture.

I don't disagree with his general point that C isn't really cross-platform, but these are bad examples:

- The C memory model addresses the issues regarding atomicity, memory ordering, and the safety of unaligned accesses (although users might not like the answer for the last one).

- Coherence within a C program is guaranteed by the language, so issues with coherence only arise when interacting with an incoherent external agent. How could any language solve this?

- Are there any examples of self-modifying code that don't already make assumptions about the underlying ISA? If you're already doing that, dealing with data/instruction memory consistency doesn't seem particularly onerous. Even when only targeting AArch64, it isn't possible to write platform-independent userspace assembly code that does this because instruction cache maintenance instructions might not be enabled for EL0.

> I don't want to trust binaries built by strangers on the Internet if they hide their behaviors.

If a binary really wanted to hide its behavior (at least to the same extent that it could with -fomit-frame-pointer), it could just make fake stack frames beyond the current PC.

> GPUs today have a more VLIW-like architecture than CPUs

Older GPUs seemed more VLIW-like because they were descended from fixed-function rendering pipelines and essentially just exposed the control signals via instruction encodings. Over time, shader cores have become less VLIW-like, e.g. look at any reverse engineering of recent Nvidia architectures.

This makes sense for the same reason you give for SMT: if you're trying to execute from multiple instruction streams on the same execution units, it makes more sense to use small individual instructions rather than large puzzle pieces.

Such architectures exist (e.g. for signal processing). They just aren't good for running general-purpose software.

I don’t work on x86 CPUs, but it’s my understanding that most “microcode updates” change the values of HW registers (or “chicken bits”) to disable problematic CPU optimizations rather than changing the literal microcode expansions of instructions.

On non/less-microcoded CPU, this same functionality would be achieved by a higher-level firmware/OS update.

> Hedge funds tracking parking lots with low orbit satellites have more insider information than any official channel.

That's not an example of an insider abusing their inside position for their benefit, it's an example of a hedge fund deciding that investing in low-orbit satellite photography gives them an edge in estimating market movement.

Does RISC-V accept changes to ratified specs beyond clarifications of existing intent?

The problem of the CPU reordering things only exists on architectures like Alpha. However, there's still the problem of the compiler reordering things (which exists on every architecture), and memory_order_consume was intended to solve both. As you can see from the original rationale document from 2010, this RCU use-case was one of the main motivations:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1525.htm

You can't express the equivalent of Linux's rcu_dereference primitive in a way that avoids data races without using memory_order_acquire (or memory_order_consume, which is treated like memory_order_acquire in all implementations, and is fundamentally broken as I link to in my sibling reply). With a memory consistency model weaker than TSO (e.g. ARM, RISC-V, POWER), this imposes unnecessary overhead and eliminates some of the benefits of RCU.

To work around this flaw, you can use inline assembly, implementation-specific "compiler-only" barriers, etc. but that's outside of the language. It also forces the compiler to be much more pessimistic about optimizations than is actually necessary to preserve dependency ordering.

The keyword to search for is "memory_order_consume", which was C++11's proposed solution to the problem that turned out to not work in practice. Here are some of the C++ WG documents describing the issues:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p00... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p01... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p04... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07...

A lot of the problems center around the reliance on data dependencies for ordering, and the difficulty of expressing these requirements in a manner that is compatible with separate compilation and compiler optimizations.

Although, somewhat amusingly, neither C++ nor Rust (which basically just copies the C++ atomics and memory model) can be used to correctly express RCU written within the language. The leading proposal for C++ (at least AFAICT) is to just add RCU primitives to the library and make their correctness the implementation's concern:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...

I hope we get a next generation of systems languages with improved memory models that can actually express these things directly.

It would be nice if Rust could do this, but it breaks backwards compatibility. Some existing code depends on pointer values of &T being equal or not equal.

JITs also modify the code at the destination of the function pointer, which was likely also code at a different time (since it usually needs to be allocated from a separate heap that is marked executable). If the CPU prefetched/cached the instructions at the function pointer target prior to the modification, then the program would observe incorrect behavior, even though it's not self-modifying code in the usual sense.

All JITs use self-modifying code, and JITs are more popular now than even 15 years ago. Although you might make a distinction between modifying code that has already executed once, from the perspective of instruction/data consistency on a CPU it doesn’t really matter.

> Unlike Go's, rust's panics do not actually, universally, get "propagated up the call stack until they reach a "catch point", where they can be handled by the programmer". There's a compiler flag which can be "unwind" or "abort". In the former case (the default), panics can be caught and recovered from. In the latter case, the program gets hard-stopped on the spot.

There are Rust libraries (e.g. salsa, used in rust-analyzer itself) that use unwinding internally for non-local control flow and won't work with unwinding disabled.

Those abstractions are still leaky, e.g. it's entirely possible that an optimizing compiler could apply correct monoid laws and end up with a program that has vastly different space usage.

Were you testing on the same platform? The Microsoft ABI has callee-save XMM registers, whereas the Linux/macOS ABI does not. Regardless, it would be nice if more compilers could do interprocedural register allocation in cases where all callers are known.

> Destroy someone's career and livelihood with unsubstantiated claims.

Hans admitted cheating while playing games on Chess.com. Is alleging that he cheated more than he previously admitted destroying his career and livelihood?