2024-09-10 04:06:57 hmf, need to go to bed soonish 2024-09-10 04:07:54 the best place in the whole world 2024-09-10 04:13:00 what, my bed? 2024-09-10 04:24:24 yup 2024-09-10 04:24:57 well, for me it is my bed 2024-09-10 04:24:57 o/ 2024-09-10 04:26:11 good, if you were that enthusiastic about my bed I'd be concerned 2024-09-10 04:26:13 hi neauoire! 2024-09-10 04:29:04 hey xentrac : ) 2024-09-10 04:29:18 I wrote a little something you might be interested in 2024-09-10 04:29:21 it's not much 2024-09-10 04:29:26 but I know you're familiar with fractran 2024-09-10 04:29:34 but I don't think you've ever thought about this: 2024-09-10 04:29:42 https://wiki.xxiivv.com/site/fractran.html 2024-09-10 04:30:53 instead of thinking of fractran, here's a little exploration write straight rewrite rules instead of whatever people usually do to write program 2024-09-10 04:30:53 programs* 2024-09-10 04:30:54 the rewrite notation makes for writing programs in fractran really fun 2024-09-10 04:30:57 it's almost like modal 2024-09-10 04:31:42 I've seen Fractran programs but never tried to write one 2024-09-10 04:31:53 it's typically quite painful 2024-09-10 04:32:13 but it's because people come in with the wrong mental model 2024-09-10 04:32:39 it's actually really fun to write programs for 2024-09-10 04:32:50 https://git.sr.ht/~rabbits/fractran/tree/main/item/examples/fizzbuzz.fra 2024-09-10 04:32:52 yeah, in part because you have to factor the numbers to read them ;) 2024-09-10 04:32:52 fizzbuzz 2024-09-10 04:33:39 it's just replacement rules, like Thue 2024-09-10 04:33:45 :: this > turns into that 2024-09-10 04:37:06 this has some relationship to some aspects of term rewriting like with Maude 2024-09-10 04:37:15 but I don't really know where that falls exactly 2024-09-10 04:37:26 I still have to explore this more 2024-09-10 04:37:37 it's basically unexplored, I couldn't find any information on this 2024-09-10 12:59:36 yeah, I think it's fair to say that Fractran hasn't been explored much 2024-09-10 16:49:06 After doing all sorts of experiments in writing a forth in C, Frank Sergant's 3-instruction forth seems even more appealing. 2024-09-10 16:53:05 I didn't get very far, just had some instances where I wondered if a pointer or an integer is more appropriate, and had one more run-in with byte order. Overall it seemed a bit higher level than it should be. 2024-09-10 16:55:44 uintptr_t is your friend if you want to mix arbitrary pointer (void * and unsigned char * at least) and integer operations (ie. arithmetic with pointers) 2024-09-10 16:56:16 did you implement the host/tether-side of 3-instruction forth in your own forth implementation? 2024-09-10 16:56:40 So I was thinking a very simple "live" assembler might be a simplier start. Read hex or decimal or octal or whatever and translate that to the appropriate ASM instructions. I guess most can tell where this is going. 2024-09-10 17:01:06 user51: what's your goal? 2024-09-10 17:01:58 unjust: Honestly, I was just experimenting with writing my own forth. I probably got wrapped up in making it tidy more than I should have. I had fun, at least. 2024-09-10 17:02:16 you can't ask for more than that :) 2024-09-10 17:04:34 i was asking because i've been having fun over the last few weeks with exactly that sort of "live" assembler approach you mentioned. except in (POSIX) shell script rather than forth 2024-09-10 17:04:50 True :) it stretched my skills a bit. It's fun to see how stuff can be written. 2024-09-10 17:05:48 there aren't many people who go down this path, so i'm interested to speak to others who have and find out what they've experienced 2024-09-10 17:07:57 Two probably silly examples: one attempt used a a linked list of cells - that's more or less like CAR/CDR. Another take was to not have immediate words and have have an explicit STATE check. Another was starting from a simple RPN evaluator and adding words as needed, but I haven't thought how adding words should work. 2024-09-10 17:10:28 unjust: POSIX shell script? That would mean, shell script exclusively, no binaries? 2024-09-10 17:10:40 yes 2024-09-10 17:10:59 just the shell 2024-09-10 17:11:37 did you roll those examples as code for the target machine and push them across via something X! and branched to with XCALL? 2024-09-10 17:46:23 something i tried a few years ago that's somewhat related, was writing a bit of 8086 assembly to be run from a PBR that implemented an interpreter that read keyboard input via bios expecting hex values (00-ff) if in compile mode, or string tokens if in interpret mode; implemented a linked list dictionary that consisted of just ":" initially (i guess CODE: would be more fitting, but this isn't a real forth) 2024-09-10 17:46:29 to append subroutines as named words 2024-09-10 18:51:24 user51> After doing all sorts of experiments in writing a forth in C, Frank Sergant's 3-instruction forth seems even more appealing. 2024-09-10 18:51:29 what are the three instructions? 2024-09-10 18:52:15 read, write, execute 2024-09-10 18:52:52 In particular c@ c! 2024-09-10 18:53:39 It's meant to be 2024-09-10 18:53:44 https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html 2024-09-10 18:53:59 Er, meant for embedded systems with the three instructions on the target and a full Forth on the host 2024-09-10 18:54:48 aaah, see 2024-09-10 18:55:26 recently i've start transitioning to a new vm model for my host build environment. it's fewer than 400 lines of C right now if you don't count the ROM image (which is generated by forth). has only 27 instructions atm, including some that are just bindings to libc fopen/fread/fwrite/fclose so that i can implement include and output target images 2024-09-10 19:00:31 s/h, see/h, i see/ 2024-09-10 19:25:42 unjust: I haven't gotten very far with any of them except one, which was an almost useful subroutine-threaded forth. 2024-09-10 19:29:59 user51: congratulations on getting that far 2024-09-10 19:30:54 I'd say implementing is fun, but it's also important not to get lost in it. But it's definitely worthwhile, and stressed my C knowledge a bit. (*(void(**)(void)address)(); // have fun! 2024-09-10 19:32:09 That line shouldn't compile because I missed a closing paren, but it should load something like 'void function(void);'. But when assigning cells to a function (pointer), what I got was the first few bytes of the function call. 2024-09-10 19:33:40 Er, assigning function pointers to cells. 2024-09-10 19:43:35 unjust: Thanks. Getting to the bones part - just enough to execute builtin words was a small enlightenment. Then getting the meat part which is user-defined words. But I'm not so sure about the skin part :D 2024-09-10 19:56:11 i've found that by calling random addresses this way - the right thing happens, C pedants are upset, and my compiler doesn't complain even with CFLAGS="-Wall -Werror -pedantic": uintptr_t address; void (*function)(void); ... function = (void(*)(void)address; function(); 2024-09-10 19:57:48 lost a closing parenthesis there, so i meant: uintptr_t address; void (*function)(void); ... function = (void(*)(void))address; function(); 2024-09-10 19:58:12 unjust: Happens to the best of us :) 2024-09-10 20:01:47 ^ proof of concept: https://pastebin.com/iWbtRmXN 2024-09-10 20:07:45 casting a function pointer from a void * is undefined behavior, yes. but it is required by any platform that implements the dlsym() api. my understanding is that the recommended way to do it is like this: function = *(void (**)(void))&address; 2024-09-10 20:08:33 but even better you could just make your cell type a union 2024-09-10 20:31:53 That's what I did, but it ended up confusing me a bit because it can look like a struct, e.g cell->function, cell->data, etc 2024-09-10 20:32:09 But maybe it's just me. 2024-09-10 20:32:50 name your members "as_function" "as_number" 2024-09-10 20:33:38 But having a cell pointer in the union makes things like @ a breeze. Same thing could be done with a struct and offset: offset = struct[offset]. 2024-09-10 20:37:23 zelgomer: I'm leaning towards writing a function. Just have an explicit cast in that function instead. For words an extra cautious debugging function which checks the dictionary before execution might be helpful 2024-09-10 20:57:10 I like the live-assembler idea. A lot of the first computers I had included some kind of monitor program in ROM where you could read, modify, and execute memory, similar to Sergeant's "three-instruction Forth" 2024-09-10 20:59:08 Ben Eater has a video where he ported an monitor from an Apple I to his 6502 computer 2024-09-10 20:59:39 "How Wozniak’s code for the Apple 1 works" https://www.youtube.com/watch?v=SpG8rgI7Hec 2024-09-10 20:59:57 user51: to avoid confusing things like *(void(*)()) I tend to use typedefs: typedef void (*callback)(); 2024-09-10 21:00:38 Actually, I think this is the porting one "Running Apple 1 software on a breadboard computer (Wozmon)" https://www.youtube.com/watch?v=HlLCtjJzHVI 2024-09-10 21:00:41 you can also do it as unjust did by assigning to a variable with the right type, but often casting is more convenient 2024-09-10 21:01:27 xentrac: agreed about convenience 2024-09-10 21:01:33 sounds like it, GeDaMo 2024-09-10 21:01:59 my uncle had an Altair, which didn't have a ROM monitor 2024-09-10 21:02:27 instead you could read, modify, and execute memory directly from the hardware 2024-09-10 21:02:38 Front panel! :P 2024-09-10 21:02:54 right, an electromechanical front panel "monitor" 2024-09-10 21:03:34 but for example on my Heathkit H8 the front panel was software-controlled 2024-09-10 21:03:56 so you could type in instruction bytes in octal and read them on the 7-segment displays in octal 2024-09-10 21:04:48 I mean. Not that you couldn't do a BCD to 7-segment decoder in hardware 2024-09-10 21:05:01 but in fact you could display arbitrary segment patterns 2024-09-10 21:07:15 crc: Konilo is indeed quite nice! 2024-09-10 21:08:04 a 7447 (a BCD to 7seg decoder) can do a bit more than 0-9 but not by much, there are 6 extras 2024-09-10 21:09:21 as seen on page 3 @ https://www.ti.com/lit/ds/symlink/sn54ls47.pdf 2024-09-10 21:10:27 some front panel debugging functionallity would be useful for modern systems too 2024-09-10 21:13:24 i definitely could have used a kernel debugger trigger (maybe via a spare GPIO somewhere) more than once, specifically for times when my workstation has become unresponsive and Magic SysRq doesn't work because the keyboard isn't being acknowledged - yet the system still responds to some network traffic 2024-09-10 22:34:32 Systems aren't really made for people like us anymore. 2024-09-10 22:34:44 The profit optimization process just grinds us right out. 2024-09-10 22:35:08 There aren't enough of us. 2024-09-10 23:10:41 What do you mean?