00:00:00 --- log: started forth/19.12.16 00:00:38 --- quit: cp- (Quit: Disappeared in a puff of smoke) 00:01:43 --- quit: ryke (Ping timeout: 246 seconds) 00:03:12 --- join: ryke joined #forth 00:06:53 --- join: mtsd joined #forth 00:07:57 --- nick: tpbsd -> tp 00:15:41 --- join: cp- joined #forth 00:32:34 --- quit: ryke (Ping timeout: 250 seconds) 00:56:17 --- quit: KipIngram (Read error: Connection reset by peer) 01:20:12 tp, how's ya RISC-V thingy going ? 01:28:45 jsoft, I've stopped work on it for now 01:30:02 --- join: dys joined #forth 01:38:01 --- quit: smokeink (Remote host closed the connection) 01:39:11 --- join: smokeink joined #forth 02:05:41 --- join: koisoke joined #forth 02:05:47 --- join: ornxka joined #forth 02:05:52 --- join: cheater joined #forth 02:05:59 --- join: irsol joined #forth 02:06:08 --- quit: cheater (Changing host) 02:06:08 --- join: cheater joined #forth 02:07:37 --- join: remexre joined #forth 02:19:25 --- join: catern joined #forth 02:20:48 --- join: dave9 joined #forth 02:25:30 --- quit: mtsd (Ping timeout: 268 seconds) 02:39:40 --- join: iyzsong joined #forth 03:03:37 --- quit: rdrop-exit (Quit: Lost terminal) 03:03:47 --- join: mtsd joined #forth 03:15:33 --- quit: WilhelmVonWeiner (Remote host closed the connection) 03:28:27 --- quit: mtsd (Ping timeout: 248 seconds) 03:33:52 --- join: mtsd joined #forth 03:45:45 --- join: tpbsd joined #forth 03:45:45 --- quit: tpbsd (Changing host) 03:45:45 --- join: tpbsd joined #forth 03:45:56 --- quit: tp (Remote host closed the connection) 03:50:36 --- nick: tpbsd -> tp 03:51:29 --- join: `presiden joined #forth 03:53:09 --- nick: `presiden -> fwiw 04:12:10 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 04:13:32 --- join: KipIngram joined #forth 04:13:32 --- mode: ChanServ set +v KipIngram 04:13:46 --- join: tpbsd joined #forth 04:13:46 --- quit: tpbsd (Changing host) 04:13:46 --- join: tpbsd joined #forth 04:14:32 --- quit: tp (Remote host closed the connection) 04:16:52 --- nick: tpbsd -> tp 04:21:25 --- quit: tp (Ping timeout: 246 seconds) 04:22:36 --- join: tp joined #forth 04:24:27 --- quit: mtsd (Ping timeout: 248 seconds) 04:26:55 --- quit: tp (Ping timeout: 245 seconds) 04:30:14 --- join: tp joined #forth 04:30:57 --- quit: smokeink (Remote host closed the connection) 05:21:55 --- quit: tp (Ping timeout: 245 seconds) 05:27:28 --- join: tp joined #forth 05:27:28 --- quit: tp (Changing host) 05:27:28 --- join: tp joined #forth 05:31:55 --- quit: tp (Ping timeout: 245 seconds) 05:36:13 --- join: tp joined #forth 05:41:30 --- quit: tp (Ping timeout: 245 seconds) 05:44:27 --- join: tp joined #forth 05:44:28 --- quit: tp (Changing host) 05:44:28 --- join: tp joined #forth 05:53:24 --- quit: dys (Remote host closed the connection) 05:54:37 --- join: dys joined #forth 05:55:11 --- join: f-a joined #forth 06:13:40 --- quit: jsoft (Ping timeout: 268 seconds) 06:27:09 --- quit: proteus-guy (Ping timeout: 265 seconds) 06:29:49 --- join: ff-mike joined #forth 07:00:54 --- join: dddddd joined #forth 07:18:27 --- join: presiden joined #forth 07:20:06 --- quit: fwiw (Quit: WeeChat 2.6-dev) 07:22:16 --- join: tpbsd joined #forth 07:23:21 --- quit: tp (Ping timeout: 268 seconds) 07:44:25 --- quit: tabemann (Ping timeout: 245 seconds) 08:31:35 --- join: tp joined #forth 08:34:12 --- quit: tpbsd (Ping timeout: 276 seconds) 08:35:06 --- quit: f-a (Read error: Connection reset by peer) 08:36:12 --- quit: tp (Ping timeout: 265 seconds) 08:39:46 --- join: f-a joined #forth 08:43:08 --- join: tp joined #forth 08:46:53 --- join: tpbsd joined #forth 08:46:53 --- quit: tpbsd (Changing host) 08:46:53 --- join: tpbsd joined #forth 08:49:31 --- quit: tp (Ping timeout: 248 seconds) 08:55:50 --- join: tp___ joined #forth 08:55:51 --- quit: tpbsd (Read error: Connection reset by peer) 09:03:15 --- join: ryke joined #forth 09:03:16 --- quit: tp___ (Read error: Connection reset by peer) 09:03:31 --- join: tp___ joined #forth 09:03:31 --- quit: tp___ (Changing host) 09:03:31 --- join: tp___ joined #forth 09:05:30 --- quit: tp___ (Read error: Connection reset by peer) 09:08:21 --- join: ryke1 joined #forth 09:10:02 --- quit: ryke (Ping timeout: 265 seconds) 09:10:02 --- nick: ryke1 -> ryke 09:12:34 --- join: tp joined #forth 09:12:34 --- quit: tp (Changing host) 09:12:34 --- join: tp joined #forth 09:26:19 --- quit: dys (Ping timeout: 248 seconds) 09:33:56 --- quit: tp (Read error: Connection reset by peer) 09:33:59 --- join: tpbsd joined #forth 09:39:57 --- quit: tpbsd (Remote host closed the connection) 09:40:13 --- join: tpbsd joined #forth 09:42:55 --- nick: tpbsd -> tp 09:49:23 --- quit: Jookia (Remote host closed the connection) 09:49:55 --- join: Jookia joined #forth 09:55:27 --- join: smokeink joined #forth 10:39:59 --- join: ryke1 joined #forth 10:43:07 --- quit: ryke (Read error: Connection reset by peer) 10:45:17 --- quit: smokeink (Remote host closed the connection) 10:46:46 --- quit: ryke1 (Ping timeout: 246 seconds) 10:49:47 --- join: WickedShell joined #forth 10:53:18 --- join: ryke joined #forth 11:21:59 --- quit: gravicappa (Ping timeout: 265 seconds) 11:37:00 --- join: smokeink joined #forth 11:39:42 --- join: payphone` joined #forth 11:54:44 --- join: dave0 joined #forth 12:00:23 --- quit: smokeink (Remote host closed the connection) 12:00:54 --- join: smokeink joined #forth 12:08:27 --- quit: ff-mike (Remote host closed the connection) 12:35:22 --- quit: f-a (Read error: Connection reset by peer) 12:39:20 --- join: f-a joined #forth 12:42:39 --- quit: f-a (Client Quit) 13:40:02 --- quit: ryke (Ping timeout: 252 seconds) 14:04:00 --- join: ryke joined #forth 14:40:33 --- quit: tp (Remote host closed the connection) 14:40:55 --- join: tp joined #forth 14:47:38 --- join: ryke1 joined #forth 14:49:00 --- quit: ryke (Ping timeout: 245 seconds) 14:49:00 --- nick: ryke1 -> ryke 15:30:15 --- quit: ryke (Ping timeout: 245 seconds) 15:44:30 --- quit: smokeink (Ping timeout: 276 seconds) 15:52:50 --- join: ryke joined #forth 16:34:13 --- quit: X-Scale (Ping timeout: 265 seconds) 16:36:38 --- join: X-Scale` joined #forth 16:37:28 --- nick: X-Scale` -> X-Scale 16:46:34 good afternoon Forthlings! 17:18:54 --- join: tabemann joined #forth 17:26:12 hey guys 17:53:10 --- quit: tabemann (Ping timeout: 245 seconds) 18:20:36 --- quit: dave0 (Quit: dave's not here) 19:34:35 --- join: rdrop-exit joined #forth 19:35:25 Hola Fortheros! 20:12:16 --- join: tabemann joined #forth 20:12:44 hey guys 20:14:55 hola 20:15:50 I've discovered I really don't like coding in assembly 20:16:19 which assembly? 20:16:37 e.g. I'm trying to write a literal-generation routine that generates literals in machine code with as efficient generated code as possible 20:16:46 and it's a real ain 20:16:50 *pain 20:16:53 Thumb-2 20:17:22 one thing is that I've inverted the standard ARM calling conventions 20:17:34 the caller saves the registers, not the callee, in my code 20:17:55 the reason why is that most of the code will be Forth code, and Forth code has no need to save registers 20:17:56 seems like that will lead to a good amount of bloat 20:18:17 ya ARM code seems like the least friendly assembly for a human to work with 20:18:46 so basically ignoring most of the registers and just using the stack? 20:18:53 mostly yeah 20:19:32 how much slower does that come out to? 5x? 20:19:47 don't know 20:20:23 --- join: smokeink joined #forth 20:20:37 I do have a TOS register 20:20:59 which gets used very heavily for a variety of things 20:21:12 I also have push_tos and pull_tos macros 20:21:43 push_tos is equivalent to dup if one does not replace the TOS register with something else 20:21:45 --- join: gravicappa joined #forth 20:21:55 pull_tos is equivalent to drop 20:24:44 I think you could get an enormous performance boost by having a word that puts data in a register 20:25:15 then you could very easily convert what looks like non-forthy code to very fast code 20:25:52 it's pretty standard amongst forths to have one TOS register, and everything else on the stack 20:27:21 right 20:28:07 its just many times slower if you ignore the registers 20:28:38 but maybe worth it since your code would use variables for trivial things and make your code look bad 20:29:23 I don't know how using arbitrary numbers of registers would be any faster 20:29:36 because any time the top of the stack moves one would have to move values between each register 20:30:01 if youre mirroring the stack in the registers then yes 20:30:38 but if your holding variables in registers then pushing them to the stack, doing calculations and storing them back, it would be easy to catch that and avoid the stack 20:32:01 back 20:32:08 5 REG1 ! 7 REG2 ! then something like REG1 @ REG2 @ + REG2 ! which looks terrible could be reduced to one instruction and probably takes one cycle 20:32:10 Hi Forthers 20:32:38 hey rdrop-exit 20:32:46 hi tabemann 20:32:55 hi rdrop-exit 20:33:03 hi Mr Mobius 20:33:16 MrMobius: the matter is that I can't write a complex optimizing compiler - this is supposed to fit into an MCU 20:33:30 tabemann, fair enough 20:33:45 sure the MCU I have has a huge amount of flash (it's a DISCOVERY board after all) 20:34:00 but I'd like to scale down to more the kind of stuff tp's been working with 20:34:02 just use a tether :) 20:34:46 Then you can have your cake and eat it too 20:35:02 tabemann, hmm, just now thinking this through but could you do REG1 REG2 ASMADD which outputs exactly one assembly instruction and avoids the stack? 20:35:14 and requires no optimizing on the compiler's part 20:36:41 Caching TOS is a minimum and supposedly best, but caching top two or even three is worth experimenting with if you have lots of registers 20:37:38 yes that seems ideal 20:38:53 but if there are two code paths that leave two different stack sizes, one of them has to shift all the cache registers 20:39:20 storing variables in registers yourself seems to be the only reliable speed up afaict 20:39:30 back 20:39:36 (not that that is the chief goal for everyone. just thinking) 20:39:43 * tabemann is caching the TOS, for the record 20:40:15 to me at least, caching the TOS is sensible and practically trivial, but going beyond that is a bit much 20:40:47 well technically I'm not caching the TOS because I'm not keeping a copy on the stack 20:42:29 You don't keep a copy on the stack, you're real stack is one less than you're Forth stack 20:42:38 * your 20:44:25 hi all! 20:44:34 if your on an FPGA your whole stack can be a big shift register 20:44:38 hi tp! 20:45:15 tabemann, the mcu sometimes has 2X the flash you think :) https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8-diags.html#stm32f103c8-diags 20:45:29 ho rdrop-exit Zen Forth Guru 20:46:28 hi Forth Master Technician (tm)! 20:46:35 MrMobius, judging by the performance boost of the register allocater version of Mecrisp-Stellaris I'm sure youre right 20:49:54 hey tp 20:50:36 hey tabemann, brave Thumb assembly adventurer ! 20:50:43 :) 20:50:49 Matthias hates thumb also 20:50:53 there's a white paper by Ertl where he comes to the conclusion that caching TOS is usually the best tradeoff, but I think it's still worthwhile experimenting with 2 (even 3, although that's a longshot) 20:54:07 For an FPGA, I would experiment with a circular stack without a stack pointer 20:55:18 I'm still annoyed that absolute addressing is so fucking hard with thumb 20:55:49 because the lack of it makes calls between flash and RAM expensive 20:55:54 tabemann, yeah, it stops thumb being my favorite ISA also 20:56:31 I'm implementing a literal generation routine right now 20:56:51 and a full 32-bit literal requires a pile of thumb instructions 20:57:04 enough to kill whatever benefit thumb might have 20:57:45 yes, there is a "long" bl instruction-pair 20:58:04 but I don't think it's long enough for a call between flash and RAM 20:58:40 your literal compiler has to be smart 20:59:34 rdrop-exit: it's turning into a nest of routines for determining the case of which of any number of bytes happens to be zero 20:59:43 and then compiling the code to skip over that byte 21:00:49 tabemann, I think you'll find that Thumb still saves memory, or it wouldn't exist 21:01:08 tp, makes sense 21:02:02 I just need to figure out how calling between flash and RAM without invoking the literal compiler would work 21:02:26 matthias has released a new version of RISC-V 32 Bit which uses the 'compressed 16 bit instruction set' and the binary size has dropped from around 26kB to 17kB 21:02:28 This is why tethered is so much better, you don't need to use target resources to add smarts to your compiler 21:03:39 rdrop-exit, but some times a little Forth chip just has to grow up, cut the tether to it's parents and leave to seek it's fortune in the big wide world! 21:05:09 Not a problem, you can always use your tether to build a sophisticated resident Forth on the target for those rare cases where you need it 21:05:34 you can have your cake and eat it too 21:05:46 ;) 21:06:12 I didn't realise! 21:07:28 The main advantage of the tether is you can put as much or as little as you need on the target. You can decide the tradeoff on project by project basis. 21:07:32 Mecrisp-Across only produces a tiny binary for the MSP430. But then "Mecrisp" is a full on-chip version for the same target 21:09:08 Like Frank Sergeant said, lets my Forth and your Forth do lunch 21:09:10 rdrop-exit, absolutely; one of my 'would love to have' features is to be able to have the full register memory maps available when developing but they always take more memory than even the largest flash memories have on cortex-m 21:09:28 hahah, I dont recall Frank writing that! 21:10:17 rdrop-exit, it's not a 'killer' app because no cortex-m can actually run *all* the peripherals at the same time anyway 21:11:31 found it: http://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html 21:11:50 It's one of the section titles 21:11:59 "Let's Your Forth and My Forth Do Lunch" 21:12:48 "This is distributed embedded systems development. Some work is done on the host and some on the target. It allows you the full power of Forth and the full power of an interpreter without requiring extensive resources on the target." 21:13:55 --- quit: smokeink (Remote host closed the connection) 21:14:49 Franks tethered Forth was the first cortex-m3 I ever used, sadly it does tend to die silently while developing, so I stopped using it 21:15:24 I've never used his code, but I always liked the principles behind it. 21:15:26 his source was pretty easy to follow, it's still a favorite learning resource for me 21:15:38 yes 21:15:38 --- join: smokeink joined #forth 21:16:16 I started learning some TCL because thats what 'riscy pygness' uses 21:16:17 With modern on-board debug infrastructure, you don't even need his 3-instruction Forth monitor. 21:16:59 thats right, his was designed for my all time favorite chip the Motorola 68HC11 21:17:06 From the point of view of the target, your host Forth system is a sophisticated debugger. 21:17:17 sure 21:17:25 I dislike Big Endian 21:17:40 and JTAG is what Mecrisp-Across uses 21:18:20 Im a technician, I'm not specialised enough to have a endian dislike 21:19:10 JTAG is a start, but you want more ideally 21:20:40 what can give more access to all the mcu components than JTAG ? 21:21:51 The RISC-V Debug Standard has a debug ROM and a debug RAM 21:22:19 plus JTAG ? 21:22:22 and a debug event queue 21:22:54 Yes, JTAG is used as a transport of sorts 21:23:21 ok, I clearly have no clue here. Youve been off assimilating all the tech data on these facilities :) 21:23:45 Just watched a video, that's all so far 21:23:59 rdrop-exit, do you think RISC-V Debug Standard will make debug easier ? 21:24:27 rdrop-exit, are you familiar with debugging as typified by GDB for assembly ? 21:24:38 wether over JTAG or SWD 21:25:36 that's the infrastructure that GDB would talk to on a RISC-V 21:26:31 My interest is in leveraging it beyond debugging for tethered development 21:27:26 no hexfiles, no Gnu tools, etc... 21:27:46 impressive ... 21:29:21 here's the video I watched: https://youtu.be/glS6BaniG8M 21:29:40 it's from May 2018 21:29:58 I have used GDB to debug cortex-m assembly from time to time, and as a open source package, GDB can access everything in ways I used to dream off, back in the 68HC11 days 21:30:22 this is truly the 'golden age' of free embedded tools 21:30:48 If you have time, have a look at that video and let me know what you think 21:30:55 thanks, I'll bookmark it as Im throttled until the 25 of this month 21:31:25 no problemo 21:31:30 actually I'll try saving it then I can play it back at full speed 21:33:11 dl, I'll have it in 4 hours :) 21:33:20 cool! :) 21:33:34 all thinks come to those that wait! 21:34:41 hey, I started altering my SCM system to include my library in every new project, and found that I couldnt check out any projects! 21:34:52 ouch 21:35:01 becauseback 21:35:55 whoops 21:35:58 just back 21:36:26 it was kinda humorous, because it kept giving me a error like this "no such repository. your left foot is on fire" 21:36:27 Things like that would be easier on a block-based Forth 21:37:25 so I spent a couple of hours trying to find why it thought there was no such repository and ignoring the fact it was telling me my left foot was on fire 21:38:01 when I finally realised my left foot was on fire and put it out, then everything worked fine ... 21:38:27 don't play with matches 21:38:55 I use Zippos myself 21:39:02 heheh, I hadnt, it wasnt my fault that my left foot spontaneously combusted! 21:39:33 You probably stepped on flaming manure 21:39:44 so when I fixed that fault which had been around for years, and only affected checkouts all was good, so it's been a interesting few days 21:39:50 okay, got my literal compiler mostly implemented 21:40:01 hehe, something smelly was certainly going on 21:40:05 just have to implement the parts that compile the individual instructions 21:40:14 tabemann, nice work! 21:40:21 kudos tabemann 21:41:00 luckily I only need to implement three instructions for this - MOV immediate, ORR, and LSL 21:41:24 --- quit: Jookia (Remote host closed the connection) 21:41:52 --- join: Jookia joined #forth 21:44:42 well, LSL immediate 21:47:59 it seems to me that matthias has to make quite a few assembly 'helper' routines to get stuff done 21:48:51 yeah, I've been doing just that 21:49:03 in theory these could be called from Forth itself 21:49:13 even though I don't plan on writing a full assembler 21:49:52 true, tho he wrote all such routines in assembly 21:53:05 what I mean is that I'm adding the necessary headers to these routines so that they can be called from Forth, need be 21:53:16 the routines themselves are written in assembly 21:53:31 one thing I was surprised to find was that I couldn't get a 32 bit number into given low Registers immediately, and that matthias had written a routine to do it using a 12 bit load and various shifts etc to build the number up to the desired value in the register concerned 21:53:34 and the code calling them will mostly be in assembly 21:54:23 as long as you have a way to inline machine code you can always speed up any slow Forth words later ? 21:55:04 --- join: lisbeths joined #forth 21:55:06 that was my plan, except everytime I think I see a way to make something faster or smaller, I find that Mecrisp-Stellaris has already done that 21:55:25 evening 21:55:30 quite right, inlining opens the door to peephole optimization 21:55:37 hey 21:55:50 hello lisbeths 21:56:16 tp: for the time being I'm not going to implement inlining, but I may in the future 21:56:39 rdrop-exit, I guess if I ever actually find a way to improve my code that Mecrisp-Stellaris hasnt already done, I'll know I've stepped up to dumb arse acolyte level ? 21:56:56 well, I should go to bed 21:57:01 g'day lisbeths 21:57:04 g'night guys 21:57:10 it's very simple to implement, so you can always add it later 21:57:12 night tabemann ! 21:57:15 g'night tabemann 21:57:41 rdrop-exit, thats the beauty of forth, one can always change it later! 21:58:16 yes, either through extension, or through metacompilation 21:58:57 rdrop-exit, Ive never come across such a malleable programming language. Using simple tools I can beat a Forth sword into a nice set of teaspoons, or vice versa 21:59:30 that's why Forths that lack a metacompiler tend to be more kitchen sink 22:00:03 rdrop-exit: what I'm probably going to do is use a special flag for a forth word header which uses macros to point at parts of words to pull out and add to the word being compiled 22:00:14 g'night for real now 22:00:20 they create a dichotomy between a Forth user and a Forth implementer 22:00:59 tabemann, all you need is an inlining width field in your header 22:01:18 and having COMPILE, make use of it 22:02:07 that assumes you explicitly decide a word is inlineable 22:02:46 I believe some Forths make the decision implicit, whuch I don't like 22:04:25 : compile, ( ca -- ) 22:04:25 dup code> b/inline ?dup if s, then; call, ; compiled 22:05:10 0 shadow Outer Interpreter - Compiler & Interpreter 22:05:11 1 22:05:11 2 compile, Compile a call to a code address, if the definition 22:05:11 3 has a non-zero inline length simply inline the code 22:05:11 4 instead. 22:05:56 The above assumes a subroutine threaded Forth with optional inlining 22:06:27 a metacompiler "is a compiler which processes its own source code, resulting in an executable version of itself 22:06:54 rdrop-exit, how many forths actually have a metacompiler ? 22:07:18 yes, a modified version of itself 22:07:42 rdrop-exit, I assume that because Mecrisp-Stellaris is written in thumb assembly and compiled by arm-none-eabi- that it doesnt have a metacompiler ? 22:07:58 I don't know, less than before since vendors usually don't want you to be able to modify and regenerate their Forth 22:08:46 ahh 'regenerate' sounds like a key word ? 22:09:55 Metacompilation is what allows you to bootstrap a new version of a compiler from the previous 22:11:35 So it seems Mecrisp-Stellaris isn't written in Forth but in thumb assembly 22:12:04 --- part: lisbeths left #forth 22:12:21 A metacompiled Forth would have a combination of Forth and assembly (using it's built-in assembler) 22:13:17 The scenario is slightly more involved if the Forth runs on a VM 22:13:58 then you'd have two levels of source 22:14:09 Mecrisp-Stellaris is absolutely written in thumb assembly 22:14:51 The VM (written in C most likely), then the Forth that runs atop the VM written in Forth and the assembly of the VM. 22:15:06 there are several 'base' files which constitute the core of Mecrisp-Stellaris and theyre all thumb assembly 22:15:57 Mecrisp-Stellaris runs only on cortex-m directly, there is no vm involved 22:16:17 So you can't easily use Mecrisp-Stellaris to write the next version of Mecrisp-Stellaris. 22:17:47 I dont think it's possible 22:18:15 you must have the arm-none-eabi- binutils 22:18:26 bah humbug 22:18:29 ;) 22:18:36 which being GPL are free and always available 22:18:53 BUT ... I take your point, I'm not trying to minimise it 22:19:23 actually, your point hit home just the other day with Mecrisp-Quintus 22:20:13 The risc-v tools are horrendous 22:20:56 one must get them with a git clone and there is literally gigabytes of source 22:21:15 tp: risc-v's tools are packaged in debian i think 22:21:20 I trued and it failed after about 1.4GB of source had been downloaded 22:21:36 Jookia, thats true, but what if one doesnt use Debian ? 22:21:50 I'll always dependencies on host tools for bringing my host VM, but I want to avoid dependencies on target specific toolchains 22:22:03 tp: i dunno, crosstool-ng 22:22:32 riscv should provide binary toolchains though like arm does 22:22:33 Jookia, I have the latest MX Linux which is debian based, and it doesnt have the latest debian riscv stuff in it's repos 22:22:34 they should get on that 22:22:56 tp: interesting, for my uses the riscv stuff in jessie's repos were enough 22:22:59 In other words, I need tools to port my host onto a new host machine, but I won't rely on any target specific tools 22:23:01 (oldstable) 22:23:09 Jookia, from a cortex-m user pov, the RISC-V tools are a nightmare 22:23:49 tp: yikes 22:23:52 Jookia, in fact theyre so bad atm, I've shelved any RISC-V 32 Bit work here until it's all sorted out 22:24:12 I don't plan on using any RISC-V toolchain 22:24:35 rdrop-exit, thats why youre the Zen Forth Guru around here! 22:24:57 tp: yikes. what have you been struggling with in particular? i've mainly use the gnu toolchains to assemble 22:25:46 Jookia, Id say that these RISC-V difficulties will mean that adoption is going to be slow (what else is new with new tech?) and will probably take years and years 22:26:01 I'd much rather use a Forth to talk to a target 22:26:20 rdrop-exit: well you need something to bootstrap it 22:26:41 Jookia, without the *latest* risc-v stuff available on Debian I cant compile the latest mecrisp-Quintus 22:26:53 tp: ah. interesting 22:26:53 No, to the target I'd be no different than a debugger 22:27:24 rdrop-exit: would you write the code that runs on the target first in forth and cross-compile it? 22:27:48 Jookia, I tried the risc-v-64xxxx on FreeBSD, MX-linux and they all have only the old buggy version 22:28:39 I use a tethered Forth 22:28:50 where do you get the tethered forth 22:28:51 Jookia, this isnt a criticism of risc-v, I quite like it, but the target is moving fast and it's hard to get all the right bits just now 22:28:56 I write it 22:29:14 rdrop-exit: do you write it using your forth? 22:29:23 tp: yeah i understand 22:29:24 It is my Forth 22:29:42 ugh ok 22:30:14 It's the same approach as used by Forth Inc and MPE 22:30:39 it doesn't make sense to me, you need a binary to run on the target and that has to come from somewhere 22:31:04 You lay it down interactively through the tether 22:31:44 To the target your host is no different from a debugger 22:32:43 Before you needed a debug monitor or a custom boot/debug monitor on the target, now the target debug capabilities are much more sophisticated 22:32:49 what tether 22:33:00 JTAG? 22:33:29 depends on what's on the other end 22:34:20 it sounds like a headache considering file formats like ELF 22:34:34 no file formats involved 22:34:52 depends on the OS 22:35:01 what OS? 22:35:30 whatever OS your target is running if any 22:36:18 You're way below the OS level, you're riding on the debug infrastructure of the hardware 22:36:48 You're in control 22:36:55 i guess that's a different use case to mine then 22:37:02 i work in userspace 22:38:41 My host on the PC side is POSIX, but that doesn't have anything to do with the target 22:39:42 yeah i see then 22:39:48 I posted this earlier today, it's a video on the RISC-V Debug specification: 22:39:49 https://www.youtube.com/watch?v=glS6BaniG8M 22:40:20 is there slides somewhere else? 22:40:40 Don't know, haven't looked for them yet 22:41:13 there's probably something on riscv.org 22:43:22 Have you ever read Sergeant's 3-instruction Forth paper, that would clarify for you the concept of a tethered Forth environment. 22:43:44 http://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html 22:48:30 If the debug infrastructure of the target is sophisticated enough you don't any of your code to be on the target before you start talking to it and laying down code on it, you can start talking to the target board straight out of the box. 22:49:02 rdrop-exit, sounds like your "One Forth" may rule them all ? 22:50:37 You only need one Forth on the desktop, that's pretty much how the vendors do it. 22:51:12 Your host Forth is basically a tethered IDE. 22:52:10 but even SWIFT and MPE also have resident target Forths 22:52:33 Take a look at SwiftX from Forth Inc, or Forth 7 from MPE. 22:52:34 it's not a age of Tethered only Forths yet is it ? 22:52:59 well I tried, but frankly all their commercial guff just put me off 22:53:11 I think most embedded Forth development has been tethered for decades. 22:53:20 plus theyre so windows oriented 22:53:38 It's only in the desktop focused ANS Forth world that it's not. 22:53:43 that hasnt been my experience 22:54:01 tethered embedded forths are rare in OSS 22:54:16 Franks effort was experimental 22:54:37 Sure but OSS is relatively new in the Forth world 22:54:55 the only OSS tethered Forth I have which actually works is Mecrisp-Across for MSP430 22:55:23 I would wager that most embedded development on commercial Forths has been tethered since sometime in the 80s 22:55:31 agreed, but thats because Forth has been around for so long 22:56:03 rdrop-exit, oh, ok, well I learn something new everyday 22:56:33 I don't think the vendors sell many of their desktop Forths, that's not their primary focus 22:57:02 there are no free interactive tethered forths around except Mecrisp-Across, but there are plenty of free resident forths going back to the 6502, and recent PIC chips 22:57:13 Their desktop Forths are mostly used as the host side Forth in tethered setups. 22:57:31 thats makes sense 22:57:37 At least that was my impression 22:57:56 and frankly, to be a commercial proposition, a Forth probably has to be tethered anyway 22:58:17 frigging around at 9600 baud via a terminal is for hobbyists 22:58:41 it's just too slow and dinky to ever develop any commercial project with imho 22:59:11 only because your transferring hexfiles back and forth :) 22:59:29 * you're 22:59:38 exactly 23:00:31 It doens't make sense to waste resources on a target for a fully resident Forth environment when you don't absolutely need it. 23:00:33 my system is pretty fast, it's as fast or faster than Gcc and GDB, which was my requirement. I think of it as a 'semi tethered forth" :) 23:00:44 cool :) 23:01:19 but it's one I can fine tune in the field with just a android tablet or even a smart phone 23:03:01 You can still do that, my point is you put what you feel you need on the target for that particular project. There's no "I want the banana, I get the gorilla" situation. 23:04:33 --- quit: dddddd (Remote host closed the connection) 23:05:28 absolutely you offer the best of both worlds 23:05:30 --- join: proteus-guy joined #forth 23:06:40 of course, the full binary for a on chip Forth for me is 20kB, and the minimum Flash I have is 64kB. Most chips have 128kB, so the size of the resident Forth binary really isnt a issue 23:07:05 this is for cortex-m 23:07:33 for cases where I may want to use a 2kB MSP430, I have the tethered Mecrisp-Across 23:11:07 What are the RAM requirements? 23:12:01 depends on whats being done 23:12:44 a base install doing nothing uses about 900 bytes of ram 23:13:11 my smallest cortex-m has 8kB of ram, the larger M3 chips have 20kB 23:13:35 well, by doing nothing I mean apart from running and doing terminal stuff 23:14:09 got it, not bad at all 23:26:19 --- join: jsoft joined #forth 23:27:13 bbl 23:27:29 no problemo 23:38:48 --- join: mtsd joined #forth 23:50:04 --- quit: proteus-guy (Ping timeout: 250 seconds) 23:56:48 --- join: proteus-guy joined #forth 23:58:39 --- quit: X-Scale (Ping timeout: 268 seconds) 23:59:59 --- log: ended forth/19.12.16