16:17 republic83: You can not blame the hw designers, cause of such partly misleading paradigm, cause there's no way to uncompress the memory because it's scanned out directly and ram has no alus, but in correct form CPU can recover the curious amount of data
16:17 republic83: But that is six cycles of work per each location
16:25 republic83: So I had the last tests to do but the code is available, cause memory is not different than alu result to be decided or recovered
16:26 republic83: They are presented i.e stashed or hashed into a word the same way
16:27 republic83: So in that sense I am sure there is nothing missing in llvm divine mstring code
16:30 republic83: Yeah, it's sure, cause in that sense the data to be accessed also uses offset and index narrowed from hw world
16:30 republic83: So would alu results
16:31 _ds_: “… can't blame hardware designers, [the] cause of…”
16:33 _ds_: (people who use cause instead of because need to be taken outside and hit hard with the “cause ≠ because” cluebat)
16:34 _ds_: (if you're going to shorten because, shorten it to 'cos; much clearer that way)
16:35 republic83: Anyways it's common sense, cos the values can be also negative
16:35 republic83: Divine already handles all that
16:36 republic83: It's just logics
16:36 republic83: Derivable with common sense, as soon as I saw that code I knew it's perfect
16:38 republic83: I only looked at couple of the key loops and they were identical to my vision and understanding