2024-08-26 05:26:15 https://assets.merveilles.town/media_attachments/files/113/026/183/848/647/748/original/83fc31c0f0c034fe.png 2024-08-26 05:26:20 music playing is coming together : ) 2024-08-26 08:34:39 Looks very nice 2024-08-26 13:31:55 yes, it does 2024-08-26 13:39:52 zelgomer: you were the one with : later >r >r swap >r >r ;, right? 2024-08-26 13:43:27 neauoire, anyone else who might know: what operating system and windowing toolkit was in use there? 2024-08-26 13:44:04 probably uxn/varvara? 2024-08-26 13:46:04 looks like rio on plan9 2024-08-26 13:49:27 thanks 2024-08-26 14:02:58 yes, it was zelgomer: http://forth.chat/logs/libera/forth/2024-08-23 2024-08-26 14:07:11 it occurred to me that you can use that approach to add dynamic scoping to standard Forth 2024-08-26 14:21:53 `later` can be traced back further; I recal it being disuc 2024-08-26 14:22:06 discussed back in 2004 or 2005 2024-08-26 14:24:38 unjust pointed out that it occurs in, for example, https://home.hccnet.nl/a.w.m.van.der.horst/forthlecture6.html 2024-08-26 14:25:42 in https://forth.chat/logs/libera/forth/2024-08-24 2024-08-26 14:27:21 I used to have it defined in retroforth, but don't use it often anymore 2024-08-26 14:27:52 what did you use it for at the time? 2024-08-26 14:29:30 initially was experimenting with infix notation 2024-08-26 14:30:54 that's interesting! how did it help with infix notation? 2024-08-26 14:32:33 i wonder if there're any implementations implement an RSWAP as a primitive 2024-08-26 14:32:43 +that implement 2024-08-26 14:35:36 http://forth.works/share/wGtyIzW0vf.txt sw 2024-08-26 14:35:42 shows an example of it 2024-08-26 14:40:53 you're sort of using the return stack as the shunting-yard operator stack; that's ingenious 2024-08-26 14:41:54 it does seem a bit like using an RPG-7 to kill a fly 2024-08-26 14:59:22 so here's my attempt at an implementation of dynamic scoping in standard Forth; it seems to work in simple tests 2024-08-26 14:59:29 : (let!) dup @ over swap 2r> rot >r rot >r >r >r ! ; : let! (let!) 2r> ! ; 2024-08-26 14:59:40 example usage: 2024-08-26 14:59:44 decimal : dec. 10 base let! . ; 2024-08-26 15:01:02 I must admit I still don't understand the shunting-yard operator stuff 2024-08-26 15:02:23 it's confusing as hell, but what it does is, before setting the requested value on the requested variable, it saves the variable's address and old value on the return stack, followed by a pointer to the `2r> !` code to restore it 2024-08-26 15:02:53 so you can use it to set any memory location to a temporary value until the word you're in returns 2024-08-26 15:02:55 Nah I get crc's example 2024-08-26 15:03:11 I'm not explaining crc's example though 2024-08-26 15:03:12 I don't get the shunting yard algorithm 2024-08-26 15:03:30 I'm explaining this implementation of dynamic scoping 2024-08-26 15:03:58 Sorry I just mean the thing I don't understand is the shunting yard algorithm 2024-08-26 15:04:08 I understand 2024-08-26 15:04:09 I 'understand' it but just don't feel like I understand it intuitively 2024-08-26 15:04:21 yeah 2024-08-26 15:04:25 I need to play with it on paper more probably 2024-08-26 15:05:04 many pocket calculators implement it, and watching it in action there can be helpful 2024-08-26 15:05:22 although the stacks are usually hidden 2024-08-26 15:06:33 I was thinking it would be interesting to design a hardware platform and OS so that to running programs there's no programmatic distinction between OS and bare metal 2024-08-26 15:06:59 Really the idea is for a VM first, although in theory it could be done in hardware, I'm no expert 2024-08-26 15:07:01 yeah, that's the idea behind IBM VM (originally CP/67), CTSS, and sort of Xen 2024-08-26 15:07:38 But the idea is that e.g. your display buffer is presented in same way at each layer, as it is in baremetal, but the layer above might mux it into a *window* rather than whole screen, for example 2024-08-26 15:07:43 Xen initially cheated with "paravirtualization" by having a small programmatic distinction 2024-08-26 15:08:04 yeah, and that specifically is how Rio and 8½ work on Plan9 2024-08-26 15:08:41 although in that case the interface isn't really the bare metal interface; it's the Plan9 framebuffer device driver interface 2024-08-26 15:09:15 actual available graphics cards often have really inconvenient interfaces for that kind of thing 2024-08-26 15:09:26 isn't that the goal of an exokernel? to provide mostly direct access to resources (whether physical or virtual) with the least amount of brokerage: ie. the kernel does some basic resource abstraction and everything else is up to the application to handle? 2024-08-26 15:09:31 yes 2024-08-26 15:09:43 The interesting result is that baremetal programs and OS-hosted applications have the same code 2024-08-26 15:10:00 So you can choose to boot your program, or run it alongside other programs 2024-08-26 15:10:20 You can run your OS as a program too 2024-08-26 15:10:20 for example, actual graphics cards often no way to ask what the resolution is, permit you to request framebuffers of only a small number of predefined resolutions, and have no way to notify you that the user has changed the resolution on you (because the user can't) 2024-08-26 15:10:38 so you need to define the baremetal interface in a suitable way 2024-08-26 15:10:46 *often have no way 2024-08-26 15:10:59 Yes in reality I don't think you can do this on baremetal, without desiging hardware for it 2024-08-26 15:11:18 But then at least you can have a dumb shim between, which is less sophisticated than a full OS 2024-08-26 15:11:21 but that's what happened with CP/67 and IBM VM and eventually with Xen 2024-08-26 15:11:37 I was wondering if this had been done before, nice 2024-08-26 15:11:58 Intel and AMD added the necessary virtualization hooks to their CPUs 2024-08-26 15:12:31 unjust: exokernels usually don't try to extend the approach to peripherals like a graphics card 2024-08-26 15:13:11 Yes this is pretty much how hypervisors work 2024-08-26 15:13:36 But it's interesting to think about going the full way with all the I/O 2024-08-26 15:13:48 CP/67 was originally built on an IBM 360 model 67 that had been custom-modified to support the necessary virtualization 2024-08-26 15:14:17 later IBM productized it as VM (and VM/CMS) 2024-08-26 15:16:14 in a sense what you're proposing is to design the hardware with a convenient abstract interface that looks like a well-designed OS API instead of whatever was easiest to get working in hardware 2024-08-26 15:18:15 do you really need much more than a memory mapped framebuffer and video controller i/o registers mapped too? 2024-08-26 15:18:18 so that your operating system uses the same operation to write a byte to your SSD or to send a byte out a serial port, for example 2024-08-26 15:18:41 That's one way of achieving this 2024-08-26 15:18:42 probably; it's hard to virtualize memory-mapped video controller I/O registers 2024-08-26 15:19:12 unjust: Depends what you're doing 2024-08-26 15:19:50 because in the case where your framebuffer is actually a window, you want to send a message to the window server when the application program writes to its simulated video controller I/O registers 2024-08-26 15:21:04 maybe that's not as hard as I think. memory-map them read-only, take a fault when the user program tries to write, single-step the user program past the write instruction, and switch the page mapping back to read-only 2024-08-26 15:21:21 maybe you could have something like a "libvideo" that's a small shim that does not a whole lot more than pretend to be a video card as far as an application is concerned, for example: it clips the boundaries of the viewport to whatever the allocated origin and dimensions are within the real framebuffer 2024-08-26 15:21:32 xentrac: That's the idea in my head 2024-08-26 15:21:58 in cases where reading from them also has side effects you'd leave the page unmapped 2024-08-26 15:22:35 this isn't going to be very nice for cases where you need to write a lot of bytes to a single location to put them in a fifo or something 2024-08-26 15:23:02 That's what needs thinking about 2024-08-26 15:23:08 But I think there are ways to optimise that 2024-08-26 15:23:11 but if you're defining the hardware you could not do that 2024-08-26 15:24:13 but what I'm saying is that, at the OS level, you want to be able to cat a file to a MicroSD card, to a serial port, or to another file 2024-08-26 15:24:33 without cat having to contain if-else clauses for all possible devices the way CP/M PIP did 2024-08-26 15:25:49 if you want cat to be able to run on bare metal with the same interface, you need to define your MicroSD interface chip and your UART to support the same hardware interface 2024-08-26 15:26:30 ideally you'd like to be able to cat your framebuffer too the way you can on Rio and 8½ 2024-08-26 15:27:07 crc> `later` can be traced back further; 2024-08-26 15:27:13 was it always called later? 2024-08-26 15:27:48 zelgomer: did you see my hack of it above to implement dynamic scoping? 2024-08-26 15:27:52 i would be surprised if nobody had come up with it before, but if they also called it later, that would be an impressive coincidence 2024-08-26 15:29:20 van der Horst called it co 2024-08-26 15:29:37 xentrac: yeah, that's cool. it lets you touch global state and arrange to restore it when you're done 2024-08-26 15:30:43 yeah 2024-08-26 15:30:47 this is the only kind of "local variables" that most Lisps had for the first 25 years of Lis 2024-08-26 15:30:52 Lisp 2024-08-26 15:30:52 i was envisioning this as the application knows how it wants to interact with a peripheral (or "resource" if it's not a physical interface/object) and the operating system has the least amount of driver capability possible to provide peripheral interface access - there has to be code to drive/allow access somewhere: the two extremes (in my opinion) are let the application deal with the details or use a 2024-08-26 15:31:40 I don't want to have firmware in my I²C interface though 2024-08-26 15:32:39 hopefully you don't have some random bus to I2C bridge implemented with an MCU then :) 2024-08-26 15:33:05 even today, after 65 years of Lisp, this prints 5 in Emacs 26.3 when I evaluate it: 2024-08-26 15:33:08 (setq x 3) (defun px () (print x)) (defun q (x) (px)) (q 5) 2024-08-26 15:33:10 rather than 3 2024-08-26 15:33:41 unjust: right, normally I don't! 2024-08-26 15:35:20 unfortunately, i have at least one case of an SPI-UART bridge implemented by an MCU to deal with recently 2024-08-26 15:36:08 humans gotta hume 2024-08-26 15:36:42 could have been done with a CPLD or FPGA instead but i guess no one collected enough $$$ in wmaze to make that happen 2024-08-26 15:37:16 yeah, it's kind of amazing, but MCUs are not just cheaper than CPLDs now 2024-08-26 15:37:25 not just cheaper than inverters 2024-08-26 15:37:34 they're cheaper than most discrete transistors 2024-08-26 15:38:53 I guess pioasm code is still firmware though? 2024-08-26 15:41:49 had to look that up, is that the raspberry pi programmable i/o code you're refering to? 2024-08-26 15:43:34 yeah 2024-08-26 15:43:58 I mean in some sense having specialized hardware to speak CAN or I²C or SPI is kind of stupid, right? 2024-08-26 15:44:22 better to do it in software. but you don't want to tie up an entire Cortex-M0 with that 2024-08-26 15:44:52 i've never played with that, but it looks like you're right that it's firmware 2024-08-26 15:45:22 but it's firmware you can fix if it's broken 2024-08-26 15:46:54 i prefer hardware to do the job, where possible, bitbanging is ok for prototyping and messing around to figure out how things work though 2024-08-26 15:49:19 zelgomer: I've also seen it named `co`, don't recall any other names for it 2024-08-26 15:55:39 sure, working hardware is always best 2024-08-26 15:56:12 but if your hardware needs firmware, it isn't really hardware that's doing the job 2024-08-26 15:57:54 maybe a state machine with an instruction set isn't the right way to build a CAN interface, but rather something like the event bus matrix and LUTs on some new Microchip MCUs 2024-08-26 15:59:21 CAN doesn't seem like the kind of thing that should need CAN-only hardware 2024-08-26 16:28:44 xentrac: once your webserver in i386 assembly had been sstrip'ed did gdb still recognize it? i could try it but i don't have an i386 system running at the moment 2024-08-26 16:31:42 I can run it, hit ^C, and x/20i $pc in gdb, if that's what you mean? 2024-08-26 16:32:58 I'm on an amd64 here but gdb and my kernel both have i386 binary support 2024-08-26 16:33:34 gdb can't find any symbols in it of course 2024-08-26 16:33:57 i was curious if gdb still recognized it 2024-08-26 16:35:13 as being an elf executable 2024-08-26 16:51:13 yes, it doesn't say "not in executable format: file format not recognized" 2024-08-26 16:51:34 it says "Reading symbols from server...\n(No debugging symbols found in server)" 2024-08-26 23:41:51 I've only today learned what an exokernel is, interesting idea 2024-08-26 23:42:58 One of the benefits of disk performance from working with raw block layout reminds me of the performance claims of PolyForth's database writing system 2024-08-26 23:43:36 And really I would expect certain routes Forth could have taken to be very similar to exokernels