IRC channel logs
2020-02-21.log
back to list of logs
<dddddd>Talking about preserve_other, I find out-of-place doing padding in what is seems a passthrough operation. Do you think there's a better place for this? <OriansJ>dddddd: because it was just copy/pasted from hex2 before being modified and I never got to fixing its name. <OriansJ>markjenkinsznc: another possiblity is simply DEFINE ->NEXT 0000 DEFINE ->TYPE 0004 DEFINE ->TEXT 0008 DEFINE ->EXPRESSION 000C <OriansJ>dddddd: well the reason for the numerate_number returning zero and the first char of the number being zero is a rough approximation for the special cases which the expression would return zero. aka -1 or 0x123 will return non-zero values and thus one doesn't need to check the leading char. However if a zero is returned it either means it isn't a number or it is just 0/0x0/0b0/00 and in that case it would just be the same <OriansJ>regardless. This is a side effect of %foo and %4 using the same prefix for x86 and knight not having a prefix <OriansJ>dddddd: I'll have to think further about the preserve_other bit <markjenkinsznc>That appears to be ready for merge, I'm inclined to PR after I sleep, run it against knightpies and give it one last read to be sure I didn't use LOADU32 or STORE32 anywhere where it wasn't needed <markjenkinsznc>All of the binaries in test/SHA256SUMS are re-assembled by the new M0-macro.s in 32 bit and 64 bit mode. M0-macro.hex2 is also re-linked/re-encoded by the test and results in same binary <markjenkinsznc>other thing I could have done wrong is get the comments out of sync in M0-macro.hex2 with the hex <markjenkinsznc>Hmmm, I just realized I didn't look at the formatting of the comments in M0-macro.hex2 the way I paid attention to it in M0-macro.s <markjenkinsznc>OriansJ, the idea of using DEFINE not just in High_Level_prototypes but in .s files is interesting, though for someone hand verifying the co-respondance between M0-macro.s and M0-macro.hex2 its a bit more work, though the comments would help like they do now <markjenkinsznc>Very strange idea of mine, the current M0-macro.s could support 16, 32, and 64 if there was a macro that did LOADU32 on 32 and 64 and LOADU16 on 16 bit and all the struct offsets left alone with space in mem for 32 bits... <OriansJ>markjenkinsznc: the standard LOAD and STORE do so at the register length. So on 16bit knight it is 16bits; on 32bit knight it is 32bits; on 64bit knight it is 64bits, etc. When they care combined with READSCID you can do an offset table (using LOADR8 [to get the offset] followed by a LOADX [using that offset]) <Hagfish>a meme that somehow manages to simultaneously compliment and insult every single person in our industry 