00:00:00 --- log: started forth/19.11.21 00:00:05 yeah, I'm reading it now 00:00:13 the register names are familiar from x86, at least 00:01:22 ARM registers? 00:01:35 er the UART registers 00:02:12 ah. i haven't looked at the UART drivers for the imx6 in too much detail. the chip itself has a giant reference manual, but not all ARM boards have that so often you have to rely on reading other people's drivers 00:02:13 like "Line Status Register," "Modem Status Register," etc 00:02:49 yeah, I'm using the rk3399, so I've got an 824-page manual 00:03:05 and debian support 00:03:23 oh you should be all set then :) 00:03:45 if you have the schematics for whichever board you're using that should help 00:04:54 the canonical source of device trees is usually whichever kernel you're using. if it's mainline, then linux's source code 00:05:23 u-boot copies them and strips them down for its early boot purposes 00:06:22 looks like I've got schematics, though I don't know how to read them and there's a nontrivial amount of chinese 00:06:55 you probably don't need them unless you're trying to verify which pins are connected/muxed 00:07:56 the muxing/pin info is in the device tree for your board anyway 00:08:28 that'd be like, "to use device register needs bit # set" ? 00:08:50 yes and no, device trees are meant to be descriptive. so a mux looks like 00:08:53 let me find an example 00:10:00 --- quit: dys (Ping timeout: 250 seconds) 00:10:09 --- join: mtsd joined #forth 00:10:27 http://ix.io/22pj 00:11:12 with the uart using it like so: http://ix.io/22pk 00:12:28 not sure how to read this tbh; time to do some reading I guess 00:12:56 http://ix.io/22pl clarifies it heavily 00:13:28 for the rk3399 i'm sure it's something different and maybe a bit saner 00:14:04 oh ew these use the C preprocessor? 00:15:00 yep, device trees have their own compiler and it's kinda trash but at runtime it's just a flattened tree in memory 00:15:37 so I guess I'll have my own notation in my notes... 00:16:11 probably bc I work in a lisp shop, but it annoys the heck out of me that new tree-structured data formats are invented when sexprs exist... 00:16:34 ylatest device tree expr is at https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2/devicetree-specification-v0.2.pdf 00:17:15 ok, thx 00:17:54 so this'd be like (for that uart), to enable the transmit pin do "*0x164 |= 0x2" (in pseudo-C) 00:18:46 yeah basically. just set the system on a chip's pins to mux according to the device tree, then whatever the uart block needs for initing (if it hasnt been already) 00:18:46 or I guess more like "setReg(0x164, getReg(0x164) | 0x2)" 00:18:57 ok, cool 00:19:03 you may be able to just get away with avoiding hardware setup if u-boot has already set up your uart 00:19:25 u-boot does not clean up its initialization before booting 00:19:38 huh, not sure how I feel about that 00:19:43 I guess short-term, makes my life easier 00:19:57 the device trees are often explicitly written so you can re-init the system 00:20:05 so all the pin muxes are provided 00:20:34 linux for example re-inits everything 00:21:22 but u-boot does do things like init DDR and MAC addresses which is useful 00:21:27 okay, I might after I get some stuff working, heh 00:21:54 probably don't want to mess with any of that until I have a working forth repl over serial though 00:22:10 one thing u-boot does that might actually mess with you is keep the instruction + data caches enabled- i'm not sure if this is of concern, but this breaks *BSD booting 00:23:08 huh, weird; is there not just like a "flush i/dcache" instruction? 00:23:18 and what are they doing that depends on not having caches o_O 00:23:31 i have no idea, it's weird 00:23:38 u-boot has the ability to disable them before boot 00:23:44 so they patch u-boot to do that 00:24:07 this is maximally spooky... 00:24:25 here's the u-boot boot spec that most modern u-boot's (2014 onwards) conform to: https://github.com/u-boot/u-boot/blob/master/doc/README.distro for your uses it would likely be you writing a u-boot script and puttig it on storage as 'boot.scr' 00:24:28 with forth (assuming DTC), do I need to do anything weird with the icahce? 00:25:05 probably not 00:25:55 but you can write a u-boot script that disables/sets up things using u-boot's commands before you load your binary 00:26:11 ok 00:27:00 i'm not entirely sure how u-boot passes the device tree to your binary, i think if you write an ELF binary you can specify an entry point 00:27:10 but you can also just check what the value is on your board and use that for now :P 00:28:07 yeah, doc/arch/arm64.rst was unhappily thin on details... didn't think to check for ELF-specific stuff 00:28:14 I'll probably hardcode for hello world, yeah 00:28:30 or maybe even skip the device tree and hardcode the register numbers and such too 00:28:51 yeah that's fine too 00:28:59 device trees are only there for portability 00:29:36 arm64 does have ACPI i think 00:29:54 but you might need EFI for that, i'm not sure 00:29:54 ehhhhhhhhhhhhhh 00:30:00 I'll take a hard pass on acpi... 00:30:04 haha 00:30:20 like implementing ACPI just seems pointlessly difficult for no reason 00:30:22 actually, arm64 also has arm trusted firwmware 00:30:38 which is loaded as well as u-boot 00:31:03 I'm not familiar with that; is that like a TPM? or like another EFI-shaped thing? 00:31:37 i believe it's a bit like intel's PSP where it runs in a privileged mode and handles power stuff 00:31:39 Mecrisp-Quintus 0.25 for RISC-V 32 IM on GD32VF103CB by Matthias Koch :) 00:31:42 https://github.com/ARM-software/arm-trusted-firmware 00:32:19 imho, arm64 really tries to get a more x86-like system 00:33:05 what's "secure world"? every google I tried for arm trusted firmware hit it (as did that link) 00:33:24 oh wait I can google it lol 00:33:33 I should prooooooooooobably get sleep at this point 00:33:42 'secure world' is just a mode in arm's trustzone which is very vague on details 00:33:51 the best explanation i've seen is https://genode.org/documentation/articles/trustzone 00:34:09 opening the page it has basically a diagram that explains it all 00:34:41 it's mainly used for DRM and security modules on phones 00:35:33 yeah, doesn't seem useful for anything I'd wanna do 00:35:45 i know for the imx6 at least you need some kind of NDA to read on how to initialize trustzone 00:36:08 I'm a compilers-head, so imo security should be obtained by requiring proofs of security properties in order to load programs :P 00:36:20 that's fair 00:36:40 i'm more of an 'isolation solves security' problem, but i think an MMU and microkernel basically solves that 00:37:26 problem with both ours (which I think/hope my model solves better) is confused-deputy sorts of things 00:37:41 capability-based security might help with that a bit? 00:37:59 I guess 00:37:59 there's a lot of effort spent on making systems like windows or linux which have bad security models be safer by just ... isolating those 00:38:25 but there's also nested hypervisors which is insane 00:38:58 I'm honestly suspicious of capability-based security's usability based on how much of a pain SELinux is, but if everyone in the ecosystem was assuming you'd need to ship whatever profiles looked like, then it seems like it'd be more usable 00:39:15 I dunno, I'm probably gonna end up with some flavor of capabilities 00:39:27 i wouldn't say SELinux is capability-based, though maybe i'm using the wrong term 00:39:37 right now I'm not thinking about it too hard, just making PIDs 64-bits to mitigate guessing 00:39:50 capability based where you can only use a resource if you have a token for it 00:39:57 a bit like file descriptors + passing those around 00:40:56 you ask a service for a handle, and after security checks you get the handle and can use it 00:41:13 SELinux/AppArmor are just weird hacks to try and curtail Unix's ambient authority 00:41:19 oh, I think I was thinking about it wrong 00:42:06 64-bit PIDs are pretty good if they aren't re-usable 00:42:18 unix's re-usable PIDs is such a headache :( 00:42:37 in my amd64 version, they're not, but that's the result of a resource leak bug :P 00:42:46 ah 00:43:21 the problem with re-usable PIDs is the race condition it gives where you can create a process, get pre-empted, have that process killed and replaced, then get pre-empted again and then try and use that process by its PID and its a new process 00:43:21 I'll probably make them non-reusable, but I need to figure out how I want PIDs to work with multi-machine setups 00:43:34 yeah 00:43:58 'cause like ideally I'd be able to IPC over the network with the same syscalls, just way higher latency 00:44:09 theoretically its solvable if you let processes lock PIDs 00:44:22 but i guess nobody wants that 00:44:34 yeah, that sounds like more trouble than its worth 00:44:45 actually, that 'locking' of PIDs is what init does on linux- init has to wait PIDs before they're reclaimed 00:44:55 so if every process had to wait() for its children that would solve the issue 00:45:09 but then you have stupid issues like double forking that destroys that 00:45:34 my hatred for unix runs deep as you can tell ;) 00:45:53 yeah, I'm not thrilled either 00:46:09 I suspect that I'll like Redox once I give it a try 00:46:26 my favorite unix fun fact is that if you don't have a controlling terminal (like a daemon), open()ing a file that is a terminal will set it as your controlling terminal UNLESS you pass NO_CTTY 00:46:38 :/ 00:46:49 I read an article about how the linux tty subsystem worked 00:46:55 got abt 2/3 of the way through 00:47:03 had to leave to go drinking 00:47:28 i was debugging DOSBox which happened to support using ptys to emulate serial connections 00:47:41 and i found that there's a TTY flag you can use to escape errors and ugh 00:48:18 as in to be able to send errnos as part of the stream or something? 00:48:23 fork() is also the worst 00:48:56 i think it was to send control characters for TTYs, such as resets 00:49:07 so the 0xFF character becomes an escape char 00:49:24 so you now have to check if a char is 0xFF then read the char after that for info 00:49:30 ah 00:50:30 i think it was actually used for parity or something 00:51:59 I've got to get to bed now (work in 5 hours); thanks for all the help and the great convo! 00:52:06 np, see you around 00:53:06 btw if you're the Linux maintainers and you really don't want people to grep for why code is checking for 0xFF, make sure to use \377 as your literaly 00:53:13 literal* 00:54:32 and especially don't document any of this anywhere useful 00:55:51 to be fair http://man7.org/linux/man-pages/man3/termios.3.html documents it but wow. ok im done 01:11:11 --- quit: Jookia (Ping timeout: 260 seconds) 01:13:31 --- join: Jookia joined #forth 01:49:07 --- quit: proteus-guy (Ping timeout: 265 seconds) 02:27:28 --- join: dave0 joined #forth 02:29:57 --- join: proteus-guy joined #forth 02:45:19 --- join: dddddd joined #forth 02:59:14 --- join: iyzsong joined #forth 03:12:15 --- quit: mtsd (Ping timeout: 265 seconds) 03:34:11 --- join: mtsd joined #forth 03:54:32 --- quit: mtsd (Remote host closed the connection) 03:55:47 --- join: mtsd joined #forth 04:01:04 --- quit: jsoft (Ping timeout: 265 seconds) 04:03:15 --- quit: dave0 (Quit: dave's not here) 05:59:23 --- quit: reepca (Remote host closed the connection) 05:59:59 --- join: reepca joined #forth 06:00:11 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 06:03:35 --- quit: inode (Quit: ) 06:08:55 --- quit: Jookia (Ping timeout: 260 seconds) 06:10:40 --- join: Jookia joined #forth 06:21:57 --- quit: reepca (Remote host closed the connection) 06:22:31 --- join: reepca joined #forth 06:32:30 --- quit: reepca (Read error: Connection reset by peer) 06:33:12 --- join: reepca joined #forth 06:51:41 --- quit: reepca (Remote host closed the connection) 06:51:55 --- join: reepca joined #forth 06:52:03 oh, Jookia: now that I'm well-rested (well, better-rested), I remember the point of the SELinux comparison 06:52:19 the policy for what processes can request handles to what needs to live somewhere 06:52:47 and the finer-grained it is, the more annoying it is to get working with a large body of software 06:54:04 --- quit: mtsd (Quit: Leaving) 07:03:24 --- quit: reepca (Ping timeout: 250 seconds) 07:46:44 --- quit: tabemann (Ping timeout: 250 seconds) 07:54:26 --- join: dys joined #forth 08:00:36 --- quit: dys (Ping timeout: 250 seconds) 08:42:47 --- join: inode joined #forth 10:25:32 --- join: dys joined #forth 10:52:34 --- join: WickedShell joined #forth 10:53:08 --- quit: dys (Ping timeout: 252 seconds) 11:03:30 --- quit: inode (Quit: ) 11:17:20 --- join: dys joined #forth 11:30:34 --- quit: gravicappa (Ping timeout: 265 seconds) 12:26:46 --- quit: jimt[m] (*.net *.split) 12:26:47 --- quit: Jookia (*.net *.split) 12:26:47 --- quit: oxford (*.net *.split) 12:29:13 --- quit: diginet2 (Ping timeout: 240 seconds) 12:29:33 --- join: diginet2 joined #forth 12:35:59 --- join: ryke joined #forth 12:36:57 --- join: Jookia joined #forth 12:38:47 --- join: oxford joined #forth 12:46:14 --- join: dave0 joined #forth 12:51:19 remexre: yeah 13:05:48 --- join: Keshl_ joined #forth 13:07:55 --- join: X-Scale` joined #forth 13:09:20 --- quit: Keshl (Ping timeout: 268 seconds) 13:10:53 --- join: rpcope- joined #forth 13:12:39 --- quit: rpcope (Ping timeout: 240 seconds) 13:12:40 --- quit: X-Scale (Ping timeout: 240 seconds) 13:12:43 --- nick: X-Scale` -> X-Scale 13:23:31 my stupid math tweet just got liked by a guy who's got a fields 13:23:35 how cool is that 13:24:26 pretty cool! 14:10:24 --- quit: jedb__ (Read error: Connection reset by peer) 14:10:27 --- join: jedb_ joined #forth 15:06:10 --- quit: xek_ (Ping timeout: 246 seconds) 15:18:18 --- join: z0idburg joined #forth 15:18:23 Hello everyone 15:19:19 g'day z0idburg ! 15:20:06 I've been testing out various forths on this old box of mine 15:20:34 cool, hows the testing going ? 15:20:45 Though some of them feel broken or just not working due to possible misconfiguration maybe, not sure. Some just lack the documentation I wish it had 15:20:46 eh 15:21:36 which ones have you tested so far? 15:21:50 --- join: jedb__ joined #forth 15:22:23 So far, I have gotten pygmy, gforth, figforth, and in the past I tested this4th but I can't find it anymore 15:22:34 I can't remember if I have played any any others on this 15:23:06 the funny thing about pygmy is that it lacks a do word, and I couldn't find any alternative name for it 15:23:27 I wasn't very inclined to write one myself with concern of "who knows what else is missing" 15:24:19 --- quit: jedb_ (Ping timeout: 240 seconds) 15:25:15 My requirements are kind of narrow I'd have to say. Perhaps unnecessarily. First of all, I don't have my system configured to run 32 bit software yet, so my limitation is that it has to be 16 bit. But second of all, I need an assembler 15:25:49 UNLESS there's one that has words to help me call interrupts 15:26:23 Do any of those forths allow you to write inline assembler? 15:26:42 so pygmy supposedly does, gforth can, I am unsure about fig16 15:26:51 this4th no idea 15:27:09 Because if none of them have high level words for interrupts, that would probably be the only way to do it 15:27:24 gforth has a neat way of doing it, so I can be like, code foobar .w bx .w ax mov and it will translate it fine 15:27:57 oh nice 15:28:03 though I did test that and I think mayyybe I am expected to do some cleanup because after foobar compiles with end-code it says invalid memory address when I call it 15:28:38 maybe it expects me to fix the return stack for it possibly without doing so itselfno idea 15:28:44 you might have to save registers on the stack before you return 15:28:50 right 15:29:09 does gforth specify any kind of abi or anything? 15:29:21 It's funny because I am much more skilled at 6502/65816 than I am x86 assembly 15:29:27 hmmm 15:29:35 same for me 15:29:39 I haven't checked yet 15:29:46 Although, 6502 was designed to be written by humans 15:29:49 x86 not so much 15:30:21 or at least, not in its current iteration 15:30:51 I'm mostly just doing this for fun, but here's what happened. I discovered that DOS (I am using 16 bit FreDOS on a Pentium II) doesn't have many MUD clients and the ones that exist are awful 15:31:35 So I decided, WATTCP isn't that hard to work with, so why not try playing with WATTCP in Forth right? Because meh I don't want to use C for something nonserious and the WATTCP BASIC lib... yeah nevermind :D 15:32:09 hence the need for interrupts 15:32:58 You know I never did see if there was any wattcp forth libs 15:33:11 I assumed, "Nope." 15:34:39 --- quit: ryke (Ping timeout: 240 seconds) 15:35:57 crc: have you experienced any really bad perf issues with a bytecode VM? 15:41:53 i'm really considering moving from ITC to bytecode 15:47:22 Going to test some things, can only run one program at a time! I'll be around 15:47:24 --- quit: z0idburg (Quit: z0idburg) 16:03:17 --- join: rdrop-exit joined #forth 16:12:14 c[] 16:13:52 rdrop-exit, g'day Zenforth Master! 16:14:11 https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano 16:14:44 hi Master Technician (tm)! 16:14:53 I've started porting stuff from the STM32F103 to the new RISC-V that uses the STM32F103 peripherals 16:15:43 tp: oh, i've heard about that. isn't that pin compatible? 16:15:50 cool, reading it now 16:16:04 one thing I don't yet understand is why the gd32vf103 has changed all the names of the peripheral registers when the ones I've looked at have identical bitfields 16:16:45 maybe to avoid being sued too bad 16:16:56 Jookia, I havent got to looking at the pin compatibility yet 16:17:13 Jookia, I guess there are many possible reasons 16:17:36 I do know that the actual die copyrights for the STM32F103 have expired now 16:17:41 what's your opinion on risc-v? 16:18:22 Jookia, I can only give an opinion regarding Forth on it compared to the STM32F103. I like it, it's pretty fast, and very cheap 16:18:44 but Ive still got a way to go porting my apps over 16:18:50 and my development system 16:19:20 FLASH.. TOTAL REPORTED: 131072 USED: 83308 FREE: 47764 16:19:20 RAM.... TOTAL PRESET: 32767 USED: 13675 FREE: 19092 16:22:15 I've become used to a small and easily install-able arm-none-eabi but the RISC-V toolchain is MASSIVE 16:22:38 'Kernel power consumption Only 1/3 of the traditional Cortex-M3' wow 16:22:59 claimed ... 16:23:08 yeah 16:23:25 and thats hard to measure, plus the board has no handy jumper to make that easy 16:23:41 but for $5 inc c color tft ... 16:23:53 cant complain really 16:24:33 there are other more developer friendly gd32vf103 boards around 16:25:07 the longan-nano is tiny, hard to even press the buttons with the nails on your fingers 16:25:26 but I think they will sell millions of them 16:25:58 a $5 voltmeter inc display ? perhaps a ampmeter, temperature guage, the list is limitless 16:25:59 i hope so 16:26:15 ill be really surprised if they don't 16:26:24 i was originally writing my forth for risc-v 16:27:06 what happened ? 16:28:04 i wrote it for ARMv7 instead because that's what runs on my computer atm 16:29:34 ARM's assembly is fairly similiar 16:30:27 64 bit ? 16:30:39 nah, 32-bit 16:30:42 i haven't messed with aarch64 yet 16:31:52 i'm under the impression it's a lot better than armv7 16:31:55 or, more RISC 16:35:01 i havent messed with it either 17:04:17 --- join: X-Scale` joined #forth 17:05:15 --- quit: X-Scale (Ping timeout: 245 seconds) 17:05:16 --- nick: X-Scale` -> X-Scale 17:05:47 --- join: tabemann joined #forth 17:30:01 hey guys 17:32:13 hey tabemann ! 17:37:14 I ran into a stupid bug 17:37:33 apparently sending exceptions to tasks doesn't always work 17:38:02 so in my ctrl-C handler, when it sends an abort exception to the main task, it sometimes goes bezerk 17:38:38 my ctrl-C handler works fine without it 17:38:50 except then it cannot stop errant behavior in the main task 17:40:16 on another note - my daughter is learning to program in school - but she doesn't know the name of the language she is programming in - when I asked her she just said "English" (I told her to show me it when she is over next) 17:40:27 hahah 17:41:21 hi tabemann :) 17:41:30 hey rdrop-exit 17:41:46 probably Python as that's the current "in" programming language 17:42:02 it used to be Java 17:43:15 ohboy, this is a fun thing to do 17:43:18 git clone --recursive https://github.com/riscv/riscv-gnu-toolchain 17:43:41 that gets you everything I presume 17:43:56 this has been running for about 16 hours 17:44:01 yeah, I guess so 17:44:25 it just trickles in 17:44:29 I wouldn't be surprised if it ran another 16 hours 17:44:36 gees 17:45:20 not something to do when you're not guaranteed a constant internet connection for a long period of time 17:45:29 I'm so used to arm-none-eabi loading in about 3 minutes 17:51:26 Why do you need the ARM gnu toolchain? I thought you now had a tethered version of Mecrisp-St 17:54:38 I just realized why the SIGINT handler sending an exception to the main task isn't working 17:54:53 it works just fine when something is making the main task spin 17:55:02 but when the main task is idle it makes it go crazy 17:55:10 the reason is simple 17:55:17 the main task is asleep 17:55:23 waiting on IO 17:55:37 seems simple when you put it that way :) 17:55:47 the actual task that is active is the sleep task, which is waiting on poll() 17:56:09 the SIGINT wakes up the runtime and breaks it out of poll() 17:56:39 then the SIGINT handler sends an exception to the main task, and the sleep task passes control onto it 17:56:45 rdrop-exit, i have both tethered and hosted on chip, and they both need the ARM GNU toolchain to be built 17:56:50 but the main task isn't expecting an ABORT exception 17:57:14 rdrop-exit, in this case tho, it's the gnu RISC-V toolchain I'm trying to download 17:57:33 it's expecting IO 17:57:56 it's not written to handle this use case 17:58:09 tabemann, so write it ? :) 17:58:12 tabemann, are you expecting your targets to all be POSIX? you seem to be adding more dependencies on POSIX being present 17:58:42 rdrop-exit: no I'm not - when I get around to working on uhashforth, I'm going to strip all that out 17:59:03 fun fun fun 17:59:19 there won't be any SIGINT obviously 17:59:43 rdrop-exit, in the case of Mecrisp-Stellaris I modify the serial handling, USART used and a few small things differently to the default binary 17:59:43 and I'm going to remap the interrupt mechanism to use ARM processor interrupts 18:00:35 tabemann, the last issue that Matthias has to finish is the GD32VF103 interrupt handling 18:02:04 I bet I could do something like tie the pushbutton on the disco board to one of my interrupts 18:02:23 so instead of pressing ctrl-C you push the button 18:03:40 sure, the 'user' pushbutton is available 18:06:01 I was running a primes generator test yesterday on my dev stm32f103 and wanted to read the local temperature but didnt want to stop the test, then remembered the temperature sensor reading is triggered by a pushbutton using a interrupt as well as the terminal which was locked out while the primes was running 18:06:37 I could actually implement multiple behaviors depending on different ways you hit the pushbutton 18:06:39 i presses the pb and bingo, the terminal printed the temperature. The primes test finished 45 minutes later 18:07:15 it's 32,81 C or 91,06 F here atm 18:07:20 like it only does the SIGINT handler if you press the pushbutton five times in a row in quick succession 18:07:39 thats easy to do 18:10:13 yeah 18:11:10 okay, I think I've got a fix to my to my ctrl-C issues 18:11:26 put a flag that indicates if it is currently in the line editor 18:11:45 and it only sends the exception if it is not currently in the line editor 18:12:16 it seems strange that you would still require the GNU toolchain once your host is up, I don't think Forth Inc's SwiftX for ARM requires it, don't know that for a fact though 18:14:16 I only need it when I modify the core of Mecrisp-Stellaris 18:14:24 after that I dont use it 18:16:06 tabemann, you could just turn off Ctrl-C SIGINT generation and handle the ctrl-C in your FORTH directly like any other key input 18:16:10 it's true that I achieve my mods in Forth alone, but that takes up flash space, so I modify the core with assembly 18:17:52 (by setting BRKINT mode control flag off) 18:20:28 tp, in theory once you have a Forth up on the host, that can talk to and lay down code on the target, you (in theory) needn't depend on GNU tools from that point on 18:21:13 back 18:21:38 tabemann, see my reply to you on ctrl-C 18:21:53 the reason why I'm not handling ctrl-C like other input is that I want to be able to use it when the main task isn't accepting input 18:22:08 for what? 18:22:22 the point is to be able to stop everything but the line editor 18:22:57 I don't get it tabemann 18:23:18 I should get another coffee, maybe that'll help 18:23:19 so I can do something like write : foo begin ." * " again ; foo ... and then it ctrl-C and I'm *bang* back at the line editor 18:23:20 brb 18:23:50 it's like ctrl-reset on the old apple //e 18:24:58 that if you have other keystrokes pending when you *bang*? 18:25:59 *what if... 18:26:55 as implemented it won't stop the line editor if it's currently running 18:28:34 On my host I just disable BRKINT and ISIG, all keyboard input comes through key 18:30:22 All key mapping and ignoring mode control flags are also disabled 18:30:24 I do have a potential solution to my issue - I don't put my line editor in the main task 18:31:10 and then I can handle ctrl-C in the line editor 18:31:29 found a web emulator for c64 18:31:43 and then found two forth in its list 18:31:52 it's amazing that JS can now run faster than hardware these days 18:32:06 https://floooh.github.io/tiny8bit/ check it 18:32:18 like the TI emulator I think siraben showed me 18:32:21 How many tasks are you running at startup? 18:32:31 just two - the main task and the sleep task 18:33:07 so the forth in c64 dont have words, how can i exploring it? 18:34:48 I don't really have a line editor on my Forth, since it's not a line-at-a-time Forth 18:36:57 yunfan, try VLIST 18:37:19 that was the WORDS equivalent in FIG 18:38:29 rdrop-exit:vlist gave a one line output 18:38:37 24cc disco 18:38:52 https://floooh.github.io/tiny8bit/z1013.html?type=z1013_64&file=z1013/z1013_forth.z80 try you self :D 18:39:30 Whoa, Z80! 18:41:17 tabemann: how's token threading for you? 18:46:33 back 18:47:35 it's slower than native code, of course, but it allows abstracting away the identity of words from their actual definitions 18:47:54 one downside is I have to decide ahead of time a maximum number of words supported 18:48:05 so I can allot a table containing every possible word 18:49:26 well, not the code for those words, but the code pointer and what I call the secondary pointer (the pointer to the tokens defining the word itself if it isn't a primitive) 18:50:41 (the code pointer is a pointer to a native code routine which implements primitives, or in the case of colon words, docol 18:56:21 its really cool that you could still use these forth word in a z80 simulators 18:56:33 sounds like you had connect to the history 19:02:43 I don't miss FIG-Forth 19:03:52 okay, I've gotta go - coffee shop is closing - will be back relatively soon 19:04:02 cya 19:08:46 --- quit: tabemann (Ping timeout: 265 seconds) 19:09:04 I like the two extremes, subroutine threading with inlining, and bytecode (8 bit tokens) VMs 19:11:21 The nice aspect is you use each on its own, or layer the two. 19:11:42 I don't ITC or DTC anymore 19:12:09 * ... you can use ... 19:15:51 STC+NCI for speed, bytecodes for portability and/or size 19:22:03 Combining the two allows you to have peephole optimization on the bytecodes, sort of a middle of the road between the two extremes. 19:26:56 Well suited to some PC based programs, where speed isn't critical, like an IDE. 19:27:42 where did everybody go? :) 19:31:00 --- join: X-Scale` joined #forth 19:31:07 --- quit: X-Scale (Ping timeout: 246 seconds) 19:31:35 bak! 19:31:41 wb! 19:31:49 --- nick: X-Scale` -> X-Scale 19:32:07 rdrop-exit, define "lay down code on the target" ? 19:32:46 rdrop-exit, youre right (of course) that I can do anything after the Forth binary is on the target 19:33:11 cross-assembly and/or cross-compilation 19:34:17 --- quit: WickedShell (Remote host closed the connection) 19:34:29 rdrop-exit, I cross compile the default forth target assembly to save code space and for convenience 19:34:59 even tho I can achieve the same thing from Forth on that same target 19:36:56 I was just puzzled on why you still needed the GNU ARM toolchain 19:37:34 i can see that 19:37:58 I receive the new Forth release as a binary, then test it on the target 19:38:38 but the author builds his releases differently to how I use them 19:39:31 as you say, I can alter what they do on the target purely in forth, but it's more efficient for me to alter the assembly and recompile 19:40:10 --- join: tabemann joined #forth 19:40:48 What I was imagining is that once he provided you with a tethered host version, you would put a new Forth on the target by using by using the tethered host rather than Gnu stuff 19:41:17 I only use the non tethered version at the moment 19:41:29 ok, got it 19:42:07 because the tethered version target is limited to MSP430 19:42:25 ah 19:42:27 and I use my large stock of STM3F051s 19:43:00 a excellent reason to use the tethered version is that the MSP430 has only 2kB flash 19:43:14 vs 64kB on the STM32F051 19:44:59 rdrop-exit, I expect that the longan-nano RISC-V boars will sell in the *millions* once all the 'arduinos' and so one get on board 19:45:04 Personally I'm not that interested in having a full Forth on the target (regardless of target size), just a monitor that works with the host to lay down code. 19:45:05 boards 19:45:33 sure, there are cases that suit each Forth 19:46:19 a tethered Forth really is a killer Forth for meany reasons 19:46:43 with the small binary advantage of C and the interactivity of Forth 19:47:03 agree wholeheartedly :) 19:47:29 in fact mecrisp-across (the msp430 tether) makes the same size binary "blinky" that I can in assembly! 19:47:57 My main question on RISC-V is how well will it cover the low end. 19:48:21 i think it will smash the low end for hobby 19:48:28 it probably already has 19:48:42 the same way ARM has? :P 19:48:48 What about the low-end for non-hobby? 19:48:55 yeah, moreso 19:49:04 back 19:49:11 in industry the low end is owned by PIC 19:49:15 wb again 19:49:17 welcome back! tabemann 19:49:49 and as PICs can be had for cents in the thousands, nothing will touch them for a long time 19:50:10 (in my opinion) 19:50:26 ok, thanks, appreciate your opinion 19:50:33 thats the absolute bottom end 19:51:01 stuff that goes into electric toothbrushes, gift cards etc 19:51:48 but once you get to IoT class which is massive now, I think RISC-V will be hard to beat, especially the Chinese variants 19:52:24 interesting times ahead 19:52:28 but what excites me about RISC-V isnt the price or market share, it's the possibilities 19:52:32 exactly 19:52:48 what if RISC-V does for hardware what Linux did for software ? 19:53:08 what are the possibilities ? 19:53:28 thousands of distributions? :-p 19:53:54 yep, all different in so way, utter chaos ;-) 19:54:46 I think it's hard to imagine what those possibilities may be 19:55:36 I see RISC-V as a enabling technology 19:56:28