IRC channel logs

2020-11-07.log

back to list of logs

<OriansJ>now if a test fails it is only because of 3 things: 1) the build failed to produce a binary that complies with the standard. 2) The Host OS can't run the binary [eg windows can't run OSX binaries] and the test should have checked for that 3) The Host architecture/implementation can't run the binary [eg armv7l binary on PowerPC] and the test should have checked for that.
<vagrantc>OriansJ: thanks for the detailed explanation :)
***stikonas_ is now known as stikonas
<Hagfish> https://queue.acm.org/detail.cfm?id=3431245
<Hagfish>"The Die is Cast - Hardware Security is Not Assured."
<Hagfish>maybe one for the website, OriansJ?
<OriansJ>Hagfish: they missed NEXUS class attacks (hardware backdoors done by the software that compiles the VHDL/Verilog into net masks) or the software the that alters the net masks to better account for quantum interference (Usually done on super computers and super proprietary) and thus improve the yield (which is alter the design in significant ways)
<OriansJ>but yes, everything there is valid
<OriansJ>I wonder what it would take to Knight into a proper standard.
<OriansJ>With extension proposals and formal standards
<xentrac>will
<xentrac>implementations would help too
<xentrac>what are the advantages of the Knight instruction set?
<xentrac>extension proposals seem like they would be counterproductive to bootstrappability
<xentrac>because another name for "extension" is "incompatibility"
<OriansJ>xentrac: well unless there are core required instructions for all implementations