ioc.exchange is one of the many independent Mastodon servers you can use to participate in the fediverse.
INDICATORS OF COMPROMISE (IOC) InfoSec Community within the Fediverse. Newbies, experts, gurus - Everyone is Welcome! Instance is supposed to be fast and secure.

Administered by:

Server stats:

1.5K
active users

#computerarchitecture

0 posts0 participants0 posts today

On April 2, 1997, AMD released a new CPU. If it succeeded, AMD had a chance at success. If it failed, AMD would probably fail with it. That CPU was the K6, and it revitalized AMD, letting them move to the middle of the market, where margins were high enough to fund its future CPUs. dfarq.homeip.net/amd-k6-releas

The Silicon Underground · AMD K6 released April 2, 1997It allowed AMD to move into the more lucrative middle of the market

If it's not an API, it's an implementation detail.

A nicely-phrased distinction: “On the technical side, I want to stress that there’s no such thing as an undocumented API (or private API). By definition an API is something that’s meant to be called by apps. Things that aren’t APIs are implementation details. And when you use that term it’s easier to evaluate your choices.” — Quinn “The Eskimo!”

Which is all too reminiscent of a common outcome among apps:

"With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.” — Hyrum's Law

Platform providers would usually prefer to follow the model “Everything which is not allowed is forbidden" while developers are fond of "Everything which is not forbidden is allowed”.* The former avoids breaking quite as many apps and can deeply annoy, err, limit app developers, while following the latter makes non-breaking platform changes difficult to impossible, and increases support and testing.

At the intersection of those two models is app instability, angst, and architectural limits.

And yes, there are inevitably cases where API designs are just broken, or where the designs reach their architectural limits, and those then either stymy further work, or might get incompatibly un-broken, or preferably get replaced in parallel with better and more capable designs and the older APIs deprecated and removed.

How you design replacements for your API limits is part of your design too, but a part frequently ignored. As are app upgrades.

Limited API designs I've met have included an eight-byte password hash buffer, and APIs featuring 32-bit addressing for storage and memory.

*I'll leave any discussions of Misters Dillon and Cooley for another time.

Replied in thread

@jfmezei :How long are data blocks for each entry in the in-CPU cache? 64 bits ? 128 bytes ? 1 page ?

It varies. Most implementations will use one cache block size at a time at a given cache level, but that size and the size and the organization of the caches varies.

:Does this vary from architecture to architecture or even inside an architecture?

Yes. Alpha caching varied by processor and by implementation, all within the limits of the Alpha architecture.

:Is it totally transparent when writing at OS level?

Totally transparent? No.

Details, such as what was locally called word tearing, alignment, memory timing, and memory lock processing, all get involved.

Similar requirements can arise in apps.

There are a few other wrinkles I’d prefer to not meet again, too.

Mostly transparent? Yes.

:And in multi core with coherent caches, when a core does a write to RAM, does memory controller propagate this to all other cores in case they have it cached? or does memory controller know which core has what in cache and send only relevant updates?

It depends. Most of what I’ve met will mark the cache contents as being invalid, and will await the next opportunity to wait for main memory to load the data, or to wait for a load from L3, or such. I can’t recall ever working on a cache-coherent multiprocessor that tried to reload the cache everywhere.

Alpha could load cache speculatively, or explicitly, or evict as needed.

bitsavers.org/pdf/dec/alpha/sy

WP has a reasonable description, as well:

en.wikipedia.org/wiki/Cache_(c

Deeper still:

cs.swarthmore.edu/~kwebb/cs31/

More for amusement, figures 5 and 6 nicely show the shifting scale of the complexity of modern computer systems:

computer.org/csdl/journal/ts/2

#digitalequipment #dec
#alpha #computerarchitecture #retrocomputing

Inside SiFive’s P550 Microarchitecture
🔗 old.chipsandcheese.com/2025/01

"The P550 is a 3-wide out-of-order core with a 13 stage pipeline. Out-of-order execution lets the core move past a stalled instruction to extract instruction level parallelism. It’s critical for achieving high performance because cache and memory latency can be significant limiters for modern CPUs."

Chips and Cheese · Inside SiFive’s P550 Microarchitecture
More from clamchowder

RISC-V Vector Extension overview
🔗 0x80.pl/notesen/2024-11-09-ris

"The goal of this text is to provide an overview of RISC-V Vector extension (RVV), and compare — when applicable — with widespread SIMD vector instruction sets: SSE, AVX, AVX-512, ARM Neon and SVE.
[…]
The vector extension is quite a huge addition. It adds 302 instructions plus four highly configurable load & store operations."

0x80.plRISC-V Vector Extension overview
#RISCV#RISC_V#RVV