2024-10-16 00:27:52 MrMobius: i have one for you. 16.16 fixed point multiplication. 2024-10-16 00:28:19 for the life of me i can't get gcc to generate code that isn't idiotic without just writing inline assembler myself. 2024-10-16 00:28:39 and even then, it does some idiotic shuffling of registers around my assembler 2024-10-16 00:31:23 should just be: mov operand1 to eax, mul second operand, shift eax 16 bits right, shift edx 16 bits left, or them together 2024-10-16 00:34:17 probably better to do it with 64 bit instructions, if you have those 2024-10-16 00:36:25 okay, 32.32 fixed point multiplication, then :) 2024-10-16 00:47:26 yeah, C is terrible for writing multiple precision arithmetic algorithms 2024-10-16 00:49:48 Forth is a bit better at it because of things like m*/ 2024-10-16 15:28:31 well after sleeping on it, i think you're right. probably the way to do it is to not define cell, cells, cell+, etc. at all in the meta core. should come up with some other word to describe the host's cell size (maybe metacell or something less stupid), and then let the back-end define cell, cells, etc. 2024-10-16 15:51:50 probably you want to have a different vocabulary so you can compile standard Forth code to run at compile time 2024-10-16 15:52:25 using cell cells cell+ etc. 2024-10-16 15:59:10 but again, if i do that, then it really defeats the whole purpose to me. 2024-10-16 16:02:20 also, the deeper issue with the mismatch is the way i'm handling c! and c@. in that case, i replace the entire cell with a "raw chars" meta object for managing the chars buffer and enforcing rules about not evaluating chars fetched with @ as an integer. but if the cell size is different, then you have unexpected behavior. e.g., 1 c, 2 c, align here 3 , what is the offset of here? is it 2, 4, or 8? 2024-10-16 22:32:41 Aren't microchips just incredible? 2024-10-16 22:34:50 what's amazing is that forth has finally forced me to learn the c99 variadic macro parameter shift trick 2024-10-16 22:45:45 alas for lisp macrochips