squizzle

It may have been obvious to others, but it’s only just “clicked” for me what is meant by an “external interface”. My assumption was something like an external PCIe card performing some accelerating functionality.

If my “click” is correct, then a better view would be like an ADC on an embedded microcontroller. It’s still part of the chip, but it’s not accessed with a “readadc” opcode, it’s accessed by setting the ADSC bit in the ADCSRA register, then reading ADC register at some point in the future (atmel AVR example)

So instead of a RdRand opcode like x64, you could have something like (paraphrasing, not certain of the syntax) …

load(MM_rand,,)

… and if the RNG takes more time than you expected to provide the data, then you stall, and that’s ok, because loads are designed to handle stalls. That doesn’t mean that you’ll have a 300 cycle latency to get a random number, but it does mean the RNG is allowed to be flexible on its timing.

Is my understanding correct?

Could you expand upon what the cycles / phasing looks like with multi-cycle ops such as a multiply?

Another fascinating talk. I’ve got a few questions from it (you might notice a theme 🙂

Could a thread manipulate its own spReg to allow it to make calls without overflowing the stack, BUT overflowing the state in the spiller?

Could a thread do a grant in a loop, generating regions until something breaks? It sounds like the OS won’t get a chance to stop it until PLB eviction occurs. Also, if it’s on a family member which does it in hardware, that removes the OSs ability to regulate a rogue process.

If sounds like if a thread fills the region table with regions overlapping one address, the augmented interval tree will handle it happily (ignoring the previous question), however what if the PLB is (mostly) full of regions that all overlap an address, which a thread then accesses? Would it need to hit an excessive amount of regions in the cache to resolve the final permission set?

On the topic of overlapping regions, I assume it’s an OR of the permissions, not an AND?

Does the iPLB ignore read permissions? (ie, can code be execute, non-read)

Keep up the good work

I think not supporting an AES primitive is a mistake. One day AES is likely to be replaced, but that’s certainly many years away, and unless there’s a massive and complete break, it will be even longer before people actually stop using it (how many people still use SHA1? MD5?).

If it (or perhaps a generic crypto instruction with a parameter for algorithm) is in the machine independent instruction set, it can be emulated when it reaches the point of being removed from silicon. When we reach this point, the emulation will only need to be correct, not super hand optimized for every cycle, so the cost required to maintain the specialiser on a new family member would presumably be very low / none.