<OriansJ`>dddddd: almost there but not quite; in this specific case that markjenkinsznc is working on is to take say: LOAD32 R0 R2 8 ; Get ->Expression value and turn it into abcd 0 2 0008 # LOAD32 R0 R2 8 ; Get ->Expression value <OriansJ`>So that nearly all of the # line up and most of the ; line up <dddddd>So, when I talked about porting this feature (comments from the original in the output) I'm talking about the M1 written in asm (say, x86) having this functionality too (instead of just output the data discarding the comments). <OriansJ`>dddddd: no, this feature will only be in the Python version that markjenkinsznc is working on <OriansJ`>unless someone is willing to do the work on the C code to make it happen <OriansJ`>dddddd: the M0 being written in hex2 will be as small as possible as the primary goal as auditing hex2 is a massive pain <OriansJ`>Auditing M0 code, only requires one to check the DEFINEs and then see if the functions do what you expect them to do <OriansJ`>hex2 audits require you to check every single byte <dddddd>I can see how having the original macros and the comment, near the output, helps. <OriansJ`>dddddd: all told the hex-monitor, hex0, hex1, hex2 and M0-compact end up being 3766bytes total <OriansJ`>after which cc_x86.s is a 16,386byte assembly program <OriansJ`>and part of me is wondering what sort of encoding changes could I make to knight to result in much denser binaries without adding complexity to the hardware implementation <dddddd>I'm not sure if optimizing a hundred of bytes is really worth thinking about it. <dddddd>No doubt if the result is just a bit harder to understand. <OriansJ`>dddddd: but perhaps fewer circuits needed to implement if done correctly <OriansJ`>So it is a background thought but not one that interferes with current work <dddddd>Then the goal is not bytes saving, but less circuit. <dddddd>Would be great, of course. And if you think both are related... go for it. <OriansJ`>dddddd: well not now as it will be possible to allocate the time for that sor of work as we get closer to putting knight into real metal <OriansJ`>but it would be an interesting bit of study for a computer science student and an electrical engineer to sit down and figure out what sort of optimizations could result in a much more optimal design. (compared to a design done by hand and with the goal of being extended past 8192bits) ***Server sets mode: +cnt
<fossy>When I make it please be highly critical of the new design.... I dont want something thats not robust merged <OriansJ`>fossy: well if you added a monkey_lives; added a flag argument to enable it and then fuzzed the program with AFL for 8 hours you should be able to clear out most of the things I would be pointing out but I will careful to put it through its paces <dddddd>fuzzing helps with robustness, but I understand fossy is also (maybe mostly) asking for design flaws? <OriansJ`>dddddd: well if fossy writes clean code with understandability at its core, design flaws will be obvious <OriansJ`>with practice fossy will be able to be able to pick up the difference between good and bad design smells <markjenkinsznc>Out of 588 lines, 20 of them (4%) have hex and the commented assembler instruction exceeding the column width <markjenkinsznc>And there are 4 lines where the hex is fine but the assembler comment takes up too much space <markjenkinsznc>Started on a work in progress basis to do alignment of operands in hex, see start, main, match, and match_cmpbyte as a sample for feedback <fossy>OriansJ`: thanks for promtimg me to do fuzzing <fossy>half an hour uncovered 3 obvious bugs