[avianes]

> why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)?

I guess you think of an access that is initiated, with an associated code that runs once the access is completed.

If yes, then how you save and restore a context with several queries in progress?

[082349872349872]

reasonable guess, but no: I was thinking of an access that either completes out of L1 or fails. if the software needs context, that's on it to keep.

[avianes]

Ok, but then what does the dev do if it fails?

It sounds like you want to use the cache as a private local memory near the core, this is called a scratchpad memory. And to maintain the scratchpad memory a DMA is usually used.

It is much more reliable than a cache that can evict data behind your back. Because we generally have no (or little) control over the cache eviction policy, and an interrupt or context switch can evict what you purposely fetch in the cache (and cache coherence can also cause data eviction).

PS: Note that in some circuits the scratchpad and the L1 cache share the same memory, this enables an adjustable cache and scratchpad size

[082349872349872]

Thanks, the existence of scratchpad (which makes the IO analogy even closer) adequately explains the lack of a non-stalling load.

Compilers which care (which would seem to be those targeting embedded; not anything gp) can then, instead of providing the two differing static schedules mentioned elsewhere in this thread, provide two different code paths: one to kick off scratchpad DMA if necessary (and possibly do something useful in the meantime?), and one that knows all its data is already in scratchpad, so it can statically unroll to an appropriate width.