2023-08-26 13:14:44 <KipIngram   > Guys, I've got something really weird happening in my Python.  I'm working on code to make a dump of my image.  There's a routine, dump_group() that gets called for each 32-bit item in my image.  It should get called eight times for each row of the dump.  The function takes two parameters, a "base" address into the image in bytes and a "group" number that runs from one to 8.  I have a debug print in there
2023-08-26 13:14:46 <KipIngram   > right now that looks like this:
2023-08-26 13:14:48 <KipIngram   >   index = base>>2 + group
2023-08-26 13:14:50 <KipIngram   >   print(base, group, index)
2023-08-26 13:15:01 <KipIngram   > When I run it, the eight lines that result might look like this:
2023-08-26 13:15:21 <KipIngram   > 672 0 168
2023-08-26 13:15:23 <KipIngram   > 672 1 84
2023-08-26 13:15:25 <KipIngram   > 672 2 42
2023-08-26 13:15:27 <KipIngram   > 672 3 21
2023-08-26 13:15:29 <KipIngram   > 672 4 10
2023-08-26 13:15:31 <KipIngram   > 672 5 5
2023-08-26 13:15:33 <KipIngram   > 672 6 2
2023-08-26 13:15:35 <KipIngram   > 672 7 1
2023-08-26 13:15:37 <KipIngram   > What the hell?
2023-08-26 13:15:44 <KipIngram   > That is correct for group = 0, but just entirely not right for the remaining seven lines.
2023-08-26 13:15:56 <KipIngram   > Why the hell  isn't index just going up by 1 each time?
2023-08-26 13:16:15 <KipIngram   > Oh, wait.
2023-08-26 13:16:24 <KipIngram   > Does + have precedence over >> ?
2023-08-26 13:16:26 <KipIngram   > It must.
2023-08-26 13:16:30 <KipIngram   > one moment...
2023-08-26 13:17:06 <Zarutian_iPad> and this is why you always use parens around terms in infix notation
2023-08-26 13:17:07 <KipIngram   > That's it.
2023-08-26 13:17:26 <KipIngram   > Heck - I was using >> in that context as a division operator, and just expected it to behave precedence like division.
2023-08-26 13:17:29 <KipIngram   > But apparently NOT.
2023-08-26 13:17:46 <KipIngram   > Well, the whole point of precedence is so you DON'T have to do that.
2023-08-26 13:17:54 <KipIngram   > But one does have to know what one is doing, huh?
2023-08-26 13:18:35 <Zarutian_iPad> the thing is that the precedence rules are arbitrary and inconsistant betwixt programming languages
2023-08-26 13:22:40 <KipIngram   > Well, I'm willing to take the blame here - I'd rather say that I should just know how to use the language at hand rather than hiding behind excessive parentheses my whole life.
2023-08-26 13:23:23 <KipIngram   > It's closer to working now, but still not there yet - this dump code very clearly prints "entire lines," and yet my program is just ending in the middle of a line before it finishes dumping the whole image.
2023-08-26 13:23:33 <KipIngram   > No error message, no nothing - it just stops.
2023-08-26 13:24:04 <KipIngram   > I expect Python print(string) to do a newline, but after I run it my bash prompt is hanging out over there at the end of the last line printed.
2023-08-26 13:24:11 <KipIngram   > It's like it's just shrugging and stopping.
2023-08-26 13:24:58 <KipIngram   > The part of the image that is dumped appears right, under some very preliminary checking.
2023-08-26 13:29:01 <KipIngram   > It tells me it's about to print 34 rows, then prints 24 and stops.
2023-08-26 13:46:49 <KipIngram   > It seems to be printing a certain string that stops it.  I can PRODUCE the string just fine - all I have to do to get the program to run through is remove that string from the pair of strings I print at one point.
2023-08-26 13:46:51 <KipIngram   > Bizarre.
2023-08-26 14:37:58 <KipIngram   > Ok, seem to have gotten that working now.  I think it had to do with  printing a character I shouldn't.
2023-08-26 14:38:24 <KipIngram   > Anyway, looks like all of the dictionary entries for the vm instructions take 1088 bytes.
2023-08-26 14:39:56 <KipIngram   > https://imgur.com/a/Ry03P0u
2023-08-26 14:41:03 <MrMobius    > KipIngram: in case it's useful, you can pass `end=""` to print so you don't get a new line
2023-08-26 14:41:13 <MrMobius    > If you want all 8 values on one line
2023-08-26 14:41:58 <MrMobius    > nvm, just saw the screenshog
2023-08-26 14:51:36 <KipIngram   > That 3296 at the end is unused bits - bits leftover at the end of cells beyond the minimum required.
2023-08-26 14:52:21 <KipIngram   > That looks bad, but it's really not - there are 64 instructions which are going to only use 12 bits of the 32-bit cell the code goes in.
2023-08-26 14:52:36 <KipIngram   > Those dictionary entries are just <instruction> <return>.
2023-08-26 14:53:08 <KipIngram   > Then there are 32 "extended" instructions that will use 20 bits - those are <alt opcode> <extended opcode> <return>.
2023-08-26 14:53:31 <KipIngram   > Nothing to be done about that.  I really should just subtract that known unavoidable waste off.
2023-08-26 14:54:05 <KipIngram   > 1-char names fill their header cells perfectly.  5-char names to do.  But names of other lengths guarantee some waste as well.
2023-08-26 14:54:32 <KipIngram   > Since the header has to be 0 padded out to 32-bit alignment.
2023-08-26 15:38:21 <KipIngram   > Ok, this is going to sound like "premature optimization" etc., but I'm noticing that given my style of making quite short definitions there's a "feature" I could add that would let me save a noticeable amount of space.  The idea would be to have a bit in the header that designated an alternate header layout.  Instead of a 2-byte link field, a count byte, and the name bytes, it would combine the link and the
2023-08-26 15:38:23 <KipIngram   > length count into a ONE BYTE field.  Then names up to three chars long would go in a header of this type that took just one cell.
2023-08-26 15:38:43 <KipIngram   > Three bytes is enough to work intelligently with when choosing names for helper words that will eventually get .wiped.
2023-08-26 15:39:20 <KipIngram   > So the whole mess of helper words I wind up having in my code would be that much smaller in RAM.
2023-08-26 15:39:48 <KipIngram   > I'm thinking just two bits of that one byte would be for the count - this would be intended for use on very short word names.
2023-08-26 15:47:53 <KipIngram   > I am planning to use the two LSB bits of the link field as flags, and may want one or two up at the high end as well.  If I pursue this short header format, then the two LSB status bits would be 1) INLINE and 2) SHORT.  If I then took the top two bits as the count, that would leave four for the link.  So I could reach back 16 cells or 64 bytes.  Most words I write are shorter than that.
2023-08-26 15:48:13 <KipIngram   > And in any case, if I couldn't reach the next link back with that then I couldn't apply the feature in that case.
2023-08-26 15:48:23 <KipIngram   > It would be an optional thing.
2023-08-26 17:56:56 <KipIngram   > Well, that dual header format trick reduced it from 1076 down to 804 bytes.
2023-08-26 17:57:41 <thrig       > now you're golfing
2023-08-26 18:25:48 <KipIngram   > Heh heh.
2023-08-26 18:27:10 <KipIngram   > Well, here's what it looks like now:
2023-08-26 18:27:12 <KipIngram   > https://imgur.com/a/ujOKkDi
2023-08-26 18:27:45 <KipIngram   > Now, there are 96 definitions there.  Given that things have to be 32-bit aligned, there MUST be at least one cell for the header and at least one for the code of that definition.  That's 8 bytes.
2023-08-26 18:28:15 <KipIngram   > 96 defs, 8 bytes each would be 768 bytes.  So, there are only 36 bytes beyond that in the thing.  I think that's not bad at all.
2023-08-26 18:31:10 <KipIngram   > That's still not quite perfect, but it's the right size.  My link fields aren't quite set right in the short headers.
2023-08-26 18:40:33 <KipIngram   > Of course, it won't maintain this sort of word density going forward.  These are just the definitions required to make the vm instrucitons accessible as Forth words.  For everyone of them the code that the interpreter will call fits in a single cell.  That won't be typical for most definitions.
2023-08-26 18:42:38 <KipIngram   > But I think that short header option will lower my average bytes per header across the whole thing, because I'll try to name my helper words in a way that exploits it.
2023-08-26 18:59:01 <KipIngram   > All of these definitions have the inline bit set, so when the compiler hits them it will copy everything there except the return instruction into whatever's being compiled now.
2023-08-26 19:00:59 <KipIngram   > I found the little issue with the link field.  It only affected one word, but it's fixed now in any case.
2023-08-26 19:04:43 <KipIngram   > I hate seeing so many zero bytes in there, but there's little to do about it.  The return instruction is opcode 0b000001.  All of those first 64 definitions have the six bits of the opcode in bits 5:0 of the cell's first byte, and the return instruction puts a 1 in bit 6.  Then the remaining three bytes of the cell are zero.  So that's 192 zero bytes that are just an unavoidable consequence of the design.
2023-08-26 19:55:14 <KipIngram   > I think next I'll write a Python bit that walks the dictionary linked list and prings all the names, just to make sure all those links are correct.  The one's I've spot checked are, but it's easy enouh to do an exhaustive check on this.
2023-08-26 19:57:30 <thrig       > trust but verify, huh
2023-08-26 20:28:40 <KipIngram   > Indeed.  Ok, that works fine.
2023-08-26 21:10:04 <KipIngram   > Well, I guess I can write some code to compile now.  Find the word in the dictionary, check the inline bit.  If it's set, copy instructions one slot at a time up to the return; if it's not set, compile a call to that location in the dictionary.  Not much to it, really.
2023-08-26 21:10:57 <KipIngram   > Or I could write the execution emulator first.  Maybe I'll watch TV for a while and see which one seems more appealing later.
2023-08-26 21:11:11 <KipIngram   > I'm up near the end of season 6 of Magnum PI.
2023-08-26 21:11:43 <KipIngram   > I think I may do Person oF Interest after this.  It would be fun seeing Zoe Morgan again.  ;-)
2023-08-26 21:12:38 <KipIngram   > There are tons of attractive women on TV, but every now and then one comes along that just *particularly* works for me - she's in that category.  :-)