Will_Edwards

I have subscribed to all forums with posts in, but have not received any emails when people post. They do not appear in my gmail spam filter either.

I cannot see any RSS links except the site one, but by trail and error I have found that http://ootbcomp.com/forums/feed works. I will have to make some cron job to filter that and alert me when people other than myself post?

I see a couple of really interesting points raised here.

First, install-time vs load-time translation.

In the first talk on Instruction Encoding Ivan says that they do the translation at install time (at the 1 hour mark; Youtube’s transcript search feature helped me track it down; hope all the videos get transcripts eventually). He describes it in terms of the IBM mainframes too, as mentioned above.

(Added: and here is a second reference, in the second talk on The Belt)

They do have a lib to make the translation available at run-time too, e.g. for JIT, so I guess OS integration can pick and choose when to do it and if to persist it.

Secondly, using profiling data to retranslate the binary.

The Mill does actually take a small step on a similar path to this. In the talk on Prediction, its described how the branch predictor loads predictions from previous runs, and updates those predictions.

Presumably as the tooling improves, all the already-translated bitstreams can be retranslated with better optimisations via auto-upgrade built into your favourite OS/distro.

This isn’t all the way to annotating apps to gather profiling and then recompiling, but you could imagine this being an option in the overall toolchain. Its just a software thing, seems quite doable.

I hope I’ve tracked down the most relevant quotes; I have no more to go on than just what has been said in the published talks.

> you would need to know whether an address needs translating before you actually bother to look it up

Do you need to?

In the mainstream, the TLB does both mapping and protection; whereas in the Mill, translation is just mapping. Protection (turf reminds me of ‘get off my lawn’) is fast and between load/store FU and the top of the cache, whereas TLB is much slower but between the bottom of the cache and main memory (which is even slower anyway).

It sounds to me like the snooping by retire stations is the same mechanism that ensures that aliasing is properly resolved on the single core, right?

And if I recall correctly, this was on an arbitrary range of memory, rather than being on a cache-line level? Does this mean that in a multicore situation, there is no “false sharing” risk?

So, at a stroke, another problem the Mill sidesteps and dances around? 🙂