***nikita is now known as Guest87463
<OriansJ>xentrac: got it, no eproms or roms in Knight <OriansJ>markjenkinsznc: well load32 is the 32bit sign extended load of 32bits; (LOADU32 is the zero extended load of 32bits) which is proably what you want (Limits M0 to 1GB of input) <OriansJ>STORE32 just stures the bottom 32bits of the register <OriansJ>as that is the correct thing, unless you want values that don't fit in that size to throw an excption (or add an extra register to record that issue) <OriansJ>one thing you could do (if you are careful) is STORE and LOAD which use the full register size but then all loads and stores would need to lookup their offset (fortunately we have READSCID to detect what size the host registers are [and what features]) <OriansJ>With the bottom 4bits representing the integer class instructions supported (8bit, 16bit, 32bit, 64bit, 128bit, 256bit and reserved(2)) Then the next 4bits covering floating point support <OriansJ>xentrac: in further regard to the Rosetta Project discs; could ornamental etchings and transparent aluminum increase the likelihood of human preservation of the artifacts? <OriansJ>markjenkinsznc: well, I want the right thing ultimately done (even if ti means the rework by me) <OriansJ>markjenkinsznc: there were also bits for string, vector and other extended functionality they had planned but honestly integer only is good enough for now. Although I might want to look into their MMU design to see if we should include it as is or reengineer it so that knight can become a future Linux target <markjenkinsznc>OriansJ, I'm closing stage0 issue 27 as you've helped me realize both 16 bit and 64 bit register support for M0-macro.s is wishlist territory and not reflective of a bug in the current emulator or code <markjenkinsznc>Took me a bit to process my blind spot on 64 bit support and the distinction of LOADU32 vs LOAD32, something I should have thought of earlier seeing how I've been implementing these in my own emulator and trying to pay attention to the distinction between signed extended and not <markjenkinsznc>The "right thing" on achieving some support for other register sizes is tricky, as an overriding value everyone seems to have here which I support is code readability/auditability <markjenkinsznc>Lots of smarts based on READSCID can be a challenge for readability, as would be having some kind of template/macro language and writing M0-macro.s.in and generating M0-macro64.s and so on from that... <markjenkinsznc>It's nice that things like structure offsets are just immediate decimal values right now, good for readability <markjenkinsznc>A way to balance this, treat 32bit and 16bit as priorities with their own implementations, everything else (or 64, 128, 256) gets something generic and harder to grok <markjenkinsznc>32bit has enough addressable memory with a single register and no bank switching to just optimize for readability, 16 bit can sacrifice some readability to get chip count down without going as far as 8 bit <markjenkinsznc>And in fairness, 16 bit isn't really promoted to first class citizen by having a version of M0-macro.s that uses STORE16, LOAD16 and adjusted offsets just to assemble the smaller programs, someone would have to invest the time to make a less readable lowmem version to assemble some of the larger programs and a similar cc_* conversion, and some programs buildable with cc_* that make it worthwhile, as its notable M2-planet itself will be too <markjenkinsznc>Sorry to flood the chat... one out there idea (I know, we have too many), if there's a 16 optimized cc_knight at some point, use it to compile a knight32 emulator and work with some kind of memory bank switcher so a knight16 machine can emulate knight32 and run the the amazing knight32 compatible programs <fossy>this weekend's project: Finish kaem refractor. <fossy>i've started and the flow of the program looks so much better <OriansJ>markjenkinsznc: if you look at stage1/stage1_assembler-2.s; you'll see how one can use READSCID without major problems with reading complexity <OriansJ>To get programs like cc_x86.s fit into 64KB; we would have to break M0 into a read DEFINEs-only pass and then generate output while reading (skipping all the defines) <markjenkinsznc>OriansJ, where I start to worry about READSCID and code readability would be if that information were then used to decide how to pack pointers into structs instead of decimal immediate values like we see now. I suppose one could just always reserve 256 bit for storing pointers in memory, though I wouldn't want to take up precious memory doing that in a 16 bit context <markjenkinsznc>I put M0-macro-64.s in stage0/stage1/development because I was figuring I would put a note saying more generic work needed in all contexts before it could become part of stage0/stage1, namely actually taking advantage of the larger memory space of 64, 128, 256 <markjenkinsznc>but after the fact it occurred to me that a .s file big enough to need a 64bit address space to be assembled isn't really a concern and LOADU64/STORE64 isn't even a thing <markjenkinsznc>So I think we can make stage1/M0-macro.s cover 32 bit through 256 bit cases by using STORE32/LOADU32 , so I'll test, rebase and PR a version that touches stage1/M0-macro.s, stage1/M0-macro.hex2, and test/SHA256SUMS <markjenkinsznc>and vm64 vm128 and vm256 as optional things for makefile (not built with plain make) <xentrac>OriansJ: transparent aluminum is star trek fiction <xentrac>ornamental etchings do seem like a good idea <dddddd>ok, fossy. Not the first time so I thought was worth reporting now. <fossy>dddddd: yeah, I used to spell it wrong, until someone corrected me <fossy>So now sometimes I acidentally type it wring again <fossy>muscle memory and everything <dddddd>I recall being wrong for some word during quite a lot time, until looked and... surprise! :D <OriansJ>xentrac: you are correct, it is generally referred to as: Aluminium oxynitride <OriansJ>markjenkinsznc: that is correct to a degree (opcodes were reserved and previously allocated) in regards to LOAD{U}64 and STORE64; <dddddd>OriansJ, why M1-macro.c range_check/bound_values refer to the value under testing as "displacement"? Even in the error message. <dddddd>The use case (the caller of range_check) just pass an arbitrary value, not related to displacements AFAIU. <markjenkinsznc>OriansJ, just a note the commit I referenced earlier today where LOAD and LOAD32 were replaced with LOADU32 didn't do the right thing on semicolons for comments, have that fixed now in code not yet pushed <markjenkinsznc>realized as well that I won't be using automated output to redo M0-macro.hex2, I'll be making sure to change that one with a clean diff and testing it just as much as I'm tested this slightly revised M0-macro.s <markjenkinsznc>speaking of testing, had a really nice test at lunch today, this only slightly revised M0-macro.s running under a 64bit vm assembled itself correctly <dddddd>Another, trickier, question, OriansJ. About eval_immediates... There're a couple of test (to avoid setting the expression of some token) with this shape `('0' == i->Text[first]) || (0 != value)` after calling to numerate_string to get the value from the relevant part of i->Text . I see that numerate_number returns 0 for invalid inputs. Also, the '0' char is part of the family of 0b, 0, 0x base prefixes. I'm wondering how all this details <dddddd>interact and what means to leave the expression unset in the token. So, we don't care about the 0-as-error if we have a zero prefix (0b/0/0x)? Why would be that? And... we count on zero starts with '0' to take apart this zero from 0-as-error? <dddddd>I hope this makes some sense... but it this feels this hard to express, I'm missing something obvious. <dddddd>Leave the expression unset obviously means it's NULL. And I see now that preserve_other would error out later.