Mill Computing, Inc. Forums The Mill Architecture Scratchpad design decision Reply To: Scratchpad design decision

Old coder
Participant
Post count: 4

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.

Idea one:
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:

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.

  • This reply was modified 3 years, 1 month ago by  Old coder.
  • This reply was modified 3 years, 1 month ago by  Old coder. Reason: Better formulating my points and correcting typo's