You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the addressing scheme for memories (and thus the granularity of locks)
is the size of data read from the memory (i.e., the data type that it contains).
Additionally, the memories can only be addressed in terms of these units, so address 1 is adjacent to address 2 and they represent completely disjoint regions of memory.
In practice, we may want the granularity of the locks to be different from the granularity of the addressing.
For instance, we may be reading 4-byte integers but the addresses can be byte-aligned. In order to support this currently,
we would need to mark the memory's data type at 1-byte integers and then make multiple reads (therefore requiring more ports, more locks, etc.)
To support this independence we primarily need to modify the lock + memory modules to understand the difference between address granularity and data granularity. This may significantly complicate certain lock modules (since address equality is no longer sufficient to determine conflicts and whether or not data can be forwarded. This also complicates code generation since it's yet another type parameter that needs to be carried around about the lock/memory modules.
The text was updated successfully, but these errors were encountered:
Currently, the addressing scheme for memories (and thus the granularity of locks)
is the size of data read from the memory (i.e., the data type that it contains).
Additionally, the memories can only be addressed in terms of these units, so address 1 is adjacent to address 2 and they represent completely disjoint regions of memory.
In practice, we may want the granularity of the locks to be different from the granularity of the addressing.
For instance, we may be reading 4-byte integers but the addresses can be byte-aligned. In order to support this currently,
we would need to mark the memory's data type at 1-byte integers and then make multiple reads (therefore requiring more ports, more locks, etc.)
To support this independence we primarily need to modify the lock + memory modules to understand the difference between address granularity and data granularity. This may significantly complicate certain lock modules (since address equality is no longer sufficient to determine conflicts and whether or not data can be forwarded. This also complicates code generation since it's yet another type parameter that needs to be carried around about the lock/memory modules.
The text was updated successfully, but these errors were encountered: