Reply To: Hard/soft realtime

There’s a bit of confusion here. The belt is not addressed by an ID drawn from a pool; it is addressed by position number. The most recent operand to drop to the belt is by definition b0. It does not have a permanent ID as it is moved along the belt by subsequent drops, but becomes b1, b2, .. bN.

Similarly, stack frames do not really have an ID, they are indicated by the ordinal stack depth. Thus the very first frame in a stack is frame zero, and so on. These too do not get recycled, although you can think of the automatic reuse (as return operations cut back the stack and later calls add new frames) as being a form of recycling.

The only pool IDs on a Mill are the thread and turf IDs. Because creating a new thread or turf is an infrequent event, allocation and recovery can be a more expensive process. The actual mechanism involves hardware allocation from a pool of IDs which is kept full by a lazy background maintenance thread, but details are NYF.

Consequently neither belt nor call frame IDs have any HRT impact at all, nor does thread or turf allocation, although thread and turf recovery does require some (very small) spare background execution outside the HRT itself.

The spiller that Will described is concerned with the data, not with the data’s name (ID). It is possible in a deeply nested sequence of prompt calls with lots of belt arguments (or rapid exit from such deep frames) to overrun the spiller’s capacity to move data. However, the constraints are the same memory bandwidth constraints that are faced for any other use of bandwidth; the spiller does not add any demand that would not have been needed by equivalent loads and stores on a register machine saving its registers. So if a HRT program hits the spiller bandwidth limit then it would also have hit the load/store bandwidth limit on a conventional. The Mill is pretty good, but it cannot magically create memory bandwidth that the DRAM chips don’t supply. If you hit the spiller bandwidth limit, your only solution is to buy a Mill family member with more memory pins, just as you would have had to do on an x86, ARM, or whatever.