-
Notifications
You must be signed in to change notification settings - Fork 0
Actual CMO Operations
The spreadsheet CMOs.xlsx is a list of some of the desired CMO operation. It is by no means a complete list.
The version uploaded as of 2020-04-30_08.04.31 (TBD: provide link to GitHub version) counts these. These counts suggest the regular format In the next section
bits | name | description |
---|---|---|
1 | LG | 0=>local, 1=> global |
3 | scope | e.g. cache level to flush to although sometimes not strictly a level (8 encodings used) |
4 | cmop | operation type 13 encodings used |
1 | sec | security related, 0=no, 1=> flush predictors and prefetchers |
we get away with "only" eight encodings, three bits, by overloading - using the same encoding to indicate slightly different things for outboound operations (pulls/flushes) and inbound operations.
| for push CMOs | for pull CMOs (prefetchesd) | | -- | --| -- | | to pou(I$,D$) | to I$ | | to pou coherent processor caches | to L1 D$ | to pou non-coherent processor caches | to L2$ pou(I,D ) | to pou non-coherent I/O | to L3$ | to ordinary DRAM | from NVRAM to DRAM | to battery backed up DRAM | to NVRAM ( first point of persistence) | to all NVRAM (full persistence) |
we can of course argue about details, to try to reduce the count
- do we need to have two points of NVRAM persistence, first and all?
- e.g. Keith Packard
- e.g. HP "Machine" (TBD: ref)
- do we need to distinguish DRAM from battery backed DRAM
- there are existence proofs, but we don't necessarily need to order them
- do we need to distinguish processor coherence from I/O coherence?
- could I/O coherence be just DRAM
But at the very least, I am sure that most people agree that we need at least four scopes, and probably more. => 3 bits. My biggest concern is that we should probably provide four bits rather than three.
rw | name | detail |
---|---|---|
r | FLUSH DIRTY --> CLEAN | |
r | FLUSH DIRTY + CLEAN --> INVALID | |
w | INVALIDATE | clean --> invalid dirty -- no wb --> invalid |
r | INVALIDATE CLEAN | clean --> invalid dirty --> unaffected secure version suitable for NC I/O |
-- | -- | -- |
r | Set LRU | |
--- | ||
r | PREFETCH-R | PREFETCH-X has I$ target |
r | PREFETCH-W | prefetch to write, may be clean or dirty < |
r | ? PREFETCH-E | prefetch as if to write, but must be clean may need to update |
r | FETCH-W + LOCK | like creating local writable copy of shared RAM |
r | FETCH-R + LOCK | like creating local copy of shared ROM |
r | FETCH-E + LOCK | like creating private ROM |
r | FETCH-EW + LOCK | like creating private RAM |
Thursday, April 9, 2020-04-09:
- in GitHub repo at https://github.com/AndyGlew/Ri5-stuff/blob/master/CMOs.xlsx
- (probably has more recent copies elsewhere, e.g. personal machine or cloud Drive) is a "list" of CMOs. Not exactly a list, more like a table from which the actual list can be generated. Many rows of the table can be expanded into several different CMO operations with different privilege requirements, caches affected, etc.
TBD: actually generate a "flat" list. Preferably by script, so that I can automatically go back between the expanded list and a compact form that is folded with common sub expressions that is easier to understand.