Mill Computing, Inc. › Forums › The Mill › Architecture › Scratchpad design decision › Reply To: Scratchpad design decision
First, I am sure I do not fully understand the architecture (but I like it as far as I do).
Conceptually I see the belt at an array, while I know technically its really not.
And I see scratchpad also conceptually as an array of some sort.
When it comes to numbers falling off and later recovering them I can imagine them landing to some other space where these can be recovered from (or not). With memory as the final backstop, all fine so far.
Now, I did read a comment here that recovering/addressing values would take so many bits to encode and I was wondering why that would need to be. Sure more positions and selective recovery/fetching would indeed cost bits, but that is not the most compact method of encoding I thought. With that background some ideas crossed my find and like to see your opinion on them.
Specify a “sector” + “some offset bit-mask” to recover/select multiple values that are near each-other (logically).
Idea two (more latency):
Specify one or several “big” sectors that have values that need recovering soon.
Then use the prior idea to pick specific values within.
Sectors could be static relative to something else and instead of a small bit-mask, a single offset could be used instead for fetching single values. Both methods assume values clustered/produced together will likely be needed around the same time. If correct, this could simplify the encoding problem. A compiler could also group constants together based on use, supporting compact addressing schemes.
It has some similarities with the old Segment + Offset kind of addressing x86 processors used to do back in the days and near pointers in C. If its for selecting values near to each-other or accessing some part of a conceptual array where part of the addressing is constant, it will be very compact.