2024-12-26 02:14:26 http://wilsonminesco.com/0-overhead_Forth_interrupts/ seems relevant 2024-12-26 03:38:43 yeah, freezing completely due to infinite loops is potentially a problem with cooperative multitasking I guess but it wasn't the one I was thinking of 2024-12-26 03:39:43 more that it's easy to accidentally have a loop that usually runs for 0.1ms but occasionally runs for 100ms on certain inputs 2024-12-26 03:40:09 which makes the system feel janky if you're using it interactively 2024-12-26 05:06:38 one of the transputer systems would switch on every branch which is a neat compromise 2024-12-26 07:29:04 yeah, there have been a lot of multithreaded CPUs if you look, most switching on every instruction rather than every branch. some of the most interesting I've learned about are the Lincoln Lab TX-2, the CDC 6600 peripheral processor, the Tera MTA, and the Padauk series of microcontrollers including the PMS150 2024-12-26 09:35:48 I've had high-level Forth running in interrupts in zenv 2024-12-26 12:31:33 that's cool! Did you have to take any special care to ensure that the inner interpreter was reentrant? 2024-12-26 14:17:03 No not at all 2024-12-26 14:17:42 You can't expect most words to work, just 'atomic' words etc, shouldn't be doing much in the interrupt anyway 2024-12-26 14:26:50 I think it depends; I've had good experiences using the Arduino TVout library, which makes the computer spend about 90% of its time in timer interrupt handlers 2024-12-26 14:26:56 for example 2024-12-26 14:27:22 (though what it does in those handlers is in fact very simple) 2024-12-26 14:27:36 the VT52 microcode is similar 2024-12-26 14:28:11 in both cases, a timer interrupt at the start of each scan line kicks off the generation of the raster waveform for that scan line 2024-12-26 14:28:39 the interrupt handler can't yield back to non-real-time code until the horizontal blanking interval (HBI) 2024-12-26 14:29:07 and then during the vertical blanking interval (VBI) there's a longer period of time where the timer interrupt handler returns immediately instead of generating pixel data 2024-12-26 14:29:17 which gives you more time for computation 2024-12-26 14:29:31 in TVout it's just reading bits out of the framebuffer 2024-12-26 15:24:10 https://pasteboard.co/FVxOZlNMlVFn.png <- pointless of course, but fun to mess with :p 2024-12-26 15:40:24 Running a tv output is a pretty decent dip into real time coding. 2024-12-26 19:46:02 There's an exception to every rule 2024-12-26 19:46:13 I just am not programming for exceptions that don't apply to me 2024-12-26 19:46:25 Everyone else is welcome to do otherwise 2024-12-26 19:47:24 I don't think there's any reason a TV signal can't be generated purely in assembly or code words, and you can spend more time in your interrupt then 2024-12-26 19:47:54 Obviously at a big computational cost ... the CPU is running at 0.1 its capability, but obviously that's a good tradeoff sometimes 2024-12-26 19:48:06 Got nothing to do with writing everything 'reentrantly' 2024-12-26 19:49:12 Just whether routines shared between both the TV signal and your other logic are high-level and also reentrant matters, but how many high-level forth routines would be shared by both anyway? 2024-12-26 21:50:02 veltas: you've described the ZX81 :D the video was CPU-generated, and user programs only ran during the display of the top and bottom borders. 2024-12-26 21:50:59 Unsurprisingly, despite running at the exact same frequency (3.25 MHz), the Jupiter's Mazogs needs big delays to be inserted in order to run at the same speed as in the ZX81. 2024-12-26 21:52:41 well, not entirely CPU-generated, there was some hardware aid, but still, it needed the full CPU attention during video generation 2024-12-26 22:21:26 veltas: Right, what I described definitely isn't true preemption, and it would be easy to write a simple bit of code that would not only loop forever itself but would take the whole system with it. 2024-12-26 22:22:19 xentrac: Re: code that's "corner case pathological," I'd say this is Forth - it's on the programmer to avoide that. 2024-12-26 22:23:53 And yes - if at all possible ISR code should do practically nothing - nothing very time consuming, at least. It should "take note" of whatever has happened and provide minimal absolutely necessar service (make further interrupts possible, for example), and post something to OS data structures so that in time it will do the real work, which might be to make a sleeping process rerady to run again or 2024-12-26 22:23:55 something. 2024-12-26 22:26:05 In the approach I described, you'd keep yourself out of 99.9% of the possible trouble by just making sure you didn't have loops built from only primitives. Or at least making sure that such loops wouldn't run for very long. 2024-12-26 22:27:22 That isn't something that you're unlikely to run into, though - like a loop that, say, adds a pair of matrices could easily be all-primitive. 2024-12-26 22:28:18 I'll probably use core allocation to keep things smooth too - have one core that I just wouldn't run such loops on, and let it handle the real-time sensitive user interaction stuff. 2024-12-26 22:29:24 That little micro board I chose for future projects has four ARM cores, and also has a RISC-V core which is particularly suitable for real time. Their idea was that you'd use it to handle critical Bluetooth timing stuff. 2024-12-26 23:57:48 KipIngram: I didn't write the code in the interrupt handler, though, I just used the library ;) 2024-12-26 23:58:34 I agree that generating the TV signal purely in assembly is a good option