00:00:00 --- log: started forth/19.12.01 00:00:13 I think the slow speed osc in the m0+ is rated at 5% error 00:00:23 something like that 00:00:56 which is probably as good as it gets for laser trimmed RC osc's in silicon 00:01:15 as usual, if you need better a xtal is required 00:01:22 I really should have put an xtal on this thing 00:01:36 you still can Im sure 00:02:00 using a RC osc for a clock is pretty unusual 00:09:25 I would have to bodge one on there 00:10:39 need to borrow some hot melt glue ? 00:10:41 ;-) 00:11:45 Nah i've got some 00:11:58 Hmm where are my crystals hiding 00:12:56 more specifically your 32,768 hz xtals ? 00:14:31 yeah 00:25:21 --- quit: dddddd (Remote host closed the connection) 00:42:38 --- join: gravicappa joined #forth 01:37:24 --- quit: tp (Remote host closed the connection) 02:20:59 --- quit: ryke (Ping timeout: 265 seconds) 02:34:22 --- join: tp joined #forth 02:34:22 --- quit: tp (Changing host) 02:34:22 --- join: tp joined #forth 03:31:00 --- quit: jsoft (Ping timeout: 240 seconds) 04:42:19 --- quit: gravicappa (Ping timeout: 240 seconds) 04:42:52 --- join: gravicappa joined #forth 04:55:40 --- quit: smokeink (Ping timeout: 276 seconds) 06:00:01 --- quit: iyzsong (Ping timeout: 276 seconds) 06:15:53 --- quit: gravicappa (Ping timeout: 265 seconds) 06:16:29 --- join: gravicappa joined #forth 06:43:19 --- join: dddddd joined #forth 07:53:34 --- quit: dddddd (Ping timeout: 252 seconds) 07:53:46 --- quit: deesix (Ping timeout: 276 seconds) 07:55:38 --- join: dddddd joined #forth 07:56:12 --- join: deesix joined #forth 09:11:32 --- quit: dddddd (*.net *.split) 09:11:32 --- quit: tp (*.net *.split) 09:11:34 --- quit: X-Scale (*.net *.split) 09:11:34 --- quit: a3f (*.net *.split) 09:11:34 --- quit: heredoc (*.net *.split) 09:11:34 --- quit: diginet2 (*.net *.split) 09:11:34 --- quit: dzho (*.net *.split) 09:11:34 --- quit: pointfree (*.net *.split) 09:11:34 --- quit: bluekelp (*.net *.split) 09:11:34 --- quit: newcup (*.net *.split) 09:11:35 --- quit: jhei (*.net *.split) 09:11:35 --- quit: dbucklin (*.net *.split) 09:12:56 --- join: dddddd joined #forth 09:12:56 --- join: tp joined #forth 09:12:56 --- join: X-Scale joined #forth 09:12:56 --- join: a3f joined #forth 09:12:56 --- join: heredoc joined #forth 09:12:56 --- join: diginet2 joined #forth 09:12:56 --- join: dzho joined #forth 09:12:56 --- join: pointfree joined #forth 09:12:56 --- join: bluekelp joined #forth 09:12:56 --- join: newcup joined #forth 09:12:56 --- join: jhei joined #forth 09:12:56 --- join: dbucklin joined #forth 09:15:31 --- quit: X-Scale (Ping timeout: 246 seconds) 09:24:34 --- join: X-Scale joined #forth 10:10:26 --- join: jsoft joined #forth 10:49:21 --- join: f-a joined #forth 11:16:25 --- join: WickedShell joined #forth 11:19:22 --- join: inode joined #forth 11:47:58 --- join: ryke joined #forth 11:52:58 --- quit: ryke (Ping timeout: 276 seconds) 11:58:37 --- quit: dddddd (Ping timeout: 246 seconds) 11:58:43 --- quit: WickedShell (Remote host closed the connection) 12:09:52 --- join: WickedShell joined #forth 12:12:06 --- quit: gravicappa (Ping timeout: 265 seconds) 12:12:22 --- join: ryke joined #forth 12:45:04 --- quit: WickedShell (Remote host closed the connection) 13:08:22 --- quit: f-a (Ping timeout: 250 seconds) 13:10:21 --- join: f-a joined #forth 13:22:00 --- quit: inode (Quit: ) 13:23:04 --- join: dddddd joined #forth 14:09:02 --- quit: X-Scale (Ping timeout: 250 seconds) 14:35:49 --- join: jedb_ joined #forth 14:38:43 --- quit: jedb (Ping timeout: 276 seconds) 14:54:53 --- quit: dave9 (Quit: dave's not here) 14:55:36 --- join: dave9 joined #forth 14:55:40 --- quit: f-a (Quit: leaving) 15:17:32 --- join: X-Scale joined #forth 15:23:55 --- join: dave0 joined #forth 15:52:20 --- quit: ryke (Ping timeout: 240 seconds) 16:26:24 --- quit: tabemann (Ping timeout: 250 seconds) 16:37:58 --- join: tabemann joined #forth 16:40:07 ugh 16:40:33 I feel like I'm gonna hafta license zeptoforth as GPL3, when I want to license it as BSD3 16:41:53 can't you buy a spray on bottle of "GPL3 rid" 16:42:25 "now with stronger GPL removal power and a fresh lemon scent!" 16:43:28 some would argue that I shouldn't even be looking at Matthias's code 16:44:07 then look at non gpl'd code ? 16:44:26 the problem is Matthias's code is too convenient and too comprehensive 16:45:00 I mean, only honest people like you are worried about looking at gpl code. All the mega companies just take it and abuse it 16:45:27 heh, matthias code is all German to me! 16:45:48 you're speaking to whom Stallman is a hero, and who only uses the GPL3 to enable more people to use his code 16:45:52 *BSD3 16:46:27 I loaded Mecrisp into Radare3 and *OMG* there are thousands of links everywhere 16:46:31 and with something like Forth, I'd be afraid of forcing the user to use the GPL too in th ie rocd 16:47:04 *in their own code 16:47:30 Stallman is my hero also, I'm describing what happens in the real world, from my experience 16:47:37 I know 16:48:01 I honestly don't care if some corporation takes my code 16:48:07 it's only human I guess. In a way the GPL is like 'rules in a knife fight' 16:48:31 remember mecrisp-across ? 16:48:40 yeah 16:48:52 it's GPL3 as well, but the binaries it produces for the target are not 16:49:04 one can use the binaries however they wich 16:49:06 wich 16:49:13 wish 16:49:14 erk ... wish 16:49:25 fumble fingers! 16:49:39 is their some addendum likek the GCC one for mecrisp-across strictly allowing that? 16:49:47 *like 16:50:13 i.e. saying that the GPL specifically does not apply to generated code 16:50:44 i dunno, Im not a lawyer, but Matthias states the binaries are license free 16:52:39 okay, I'm just going to fudge the legal stuff and say that I don't actually borrow the characters in Matthias's code it's probably okay 16:55:22 ill bet that a fair bit of his code was learnt from others in the German Forth group anyway 16:55:42 well, and as long as I change the identifiers and don't directly copy his overall logic 16:55:49 we all build on the works of others, no one creates stuff in true isolation 16:56:22 exactly, and besides you want to make *your* forth, you don't want to copy anyone elses 16:57:13 I still think that Mitch Bradleys 'cforth' is really nice, I think I'll see if I can compile it on a Linux box 17:01:58 --- quit: dave0 (Quit: dave's not here) 17:02:01 back 17:02:44 --- join: jedb__ joined #forth 17:03:24 welcome back! 17:05:10 one thing I'm confused about is this 17:05:29 --- quit: jedb_ (Ping timeout: 265 seconds) 17:05:30 I also need to work on the latest mecrisp-across as that now has "Pictured Numerical Output" after I asked Matthias if he would implement it 17:05:45 cool 17:06:05 that facility now allows me to easily do my ' pretty register printing' 17:06:50 and thanks to some Rust people. I now have a SVD for the MSP430 and have created all the register words I use so much 17:07:50 and I guess Mecrisp-Across has the same stability as Mecrisp-Stellaris as the latter creates the former 17:11:23 --- join: smokeink joined #forth 17:19:55 --- quit: smokeink (Ping timeout: 276 seconds) 17:37:06 back 18:35:32 --- quit: tabemann (Ping timeout: 268 seconds) 18:50:12 --- join: tabemann joined #forth 19:20:56 tp, I have a question 19:21:06 in Thumb assembly 19:21:16 do you have to explicitly specifies the bitshifts 19:21:24 or does it figure them out for you 19:21:41 sorry I dont follow 19:21:47 like if you have: 19:21:51 orr r1, #B0 19:21:56 is that permissible 19:22:00 or do you have to write 19:22:12 orr r1, #0xB < 4 19:22:26 *orr r1, #0xB0 19:23:03 I thing you have to specify them manually 19:23:07 I always have 19:23:27 where the immediate exceeds the 1024 value ? 19:24:30 oh in my case the immediate doesn't exceed 1024 19:25:32 yeah in which case the assembler wont complain 19:26:37 in Mecrisp-Stellaris I can use any value, but Mecrisp-Stellaris will automatically compute the shortest number of loads and shifts to achieve a number over 1024 19:33:14 here is a example 19:33:17 : rlit 19:33:17 [ 19:33:17 1000 0 registerliteral, 19:33:18 ] 19:33:18 ; 19:33:18 \ see rlit 19:33:20 \ 20000654: B500 push { lr } 19:33:22 \ 20000656: 20FA movs r0 #FA 19:33:24 \ 20000658: 0080 lsls r0 r0 #2 19:33:28 \ 2000065A: BD00 pop { pc } 19:35:50 Registerliteral, generates the shortest possible sequence to get x into given low Register using movs adds lsls sequences. 1. M0: A movs-lsls-adds… sequence 2. M3/M4: movs / movs-mvns / movw / movw-movt 19:36:11 you will definitely need your own version of this 19:36:32 to be completely honest, I reading over Matthias's code, and then typing it in with my own keystrokes but modifying it enough so that it is no longer anything like identical 19:37:18 like different comments, different identifier names, breaking things up into separate functions that were single functions originally, making things into .equ constants which had previously been specified inline, etc 19:37:50 the reason why is that even if I looked up everything on my own I doubt my code would have turned out to be functionally any different 19:38:16 because these things are the sorta thing where there is probably one right way to do it 19:38:54 perhaps one thats more efficient where that term may be code size or speed ? 19:39:29 matthia's favorite thing is algorithms, he loves them 19:39:41 loves solving them 19:40:07 I always have to heavily refactor his Forth code as it's always too long and complex for me 19:40:18 this is not stuff like that 19:40:25 this is boring setup stuff 19:40:29 ahh 19:40:43 like load register X, clear bits Y, set bits Z, write back to register X 19:41:17 he doesnt like Thumb anyway, and Im not fond of it myself. He thinks in MSP430 assembler tho 19:41:56 I kinda like assembly in general, especially the setup stuff because thats what Im always doing as a tech 19:42:16 i never do the complex software things that programmers love 19:42:55 I don't like the whole adds rx, ry stuff where it adds rx and ry and puts it back in rx 19:43:08 you get used to it 19:43:40 I'm hanging out to start doing some RISC-V assembly but have some other tasks to finish first 19:43:58 i prefer like adds rx, ry, rz where it adds ry and rz and puts it in rx like in normal ARM assembly 19:44:00 I'm hoping it will be 'smoother' than thumb 19:44:22 I've never done any non thumb arm code 19:44:55 I want 32 bit #IMM stuff too! 19:45:17 I dont care about code size, Flash is plentiful thesedays 19:45:24 norma ARM won't give you 32 bit #IMM either 19:45:32 i know 19:45:52 nor will MSP430 ;-) 19:46:12 what is the point of MSP430 though? I mean, they've got so little space that how can you do anything with them? 19:46:25 but MSP430 gives you the full data width of 16 bits :) 19:46:56 MSP430 apart from having M6800 like smooth as silk assembly, is : 19:47:07 * fast 19:47:14 * efficient 19:47:27 * all peripherals are highly integrated 19:47:36 * very low power 19:47:49 * FRAM memory in the later models 19:48:28 MSP430 is very popular for all the above reasons 19:48:48 the only things I dont like about MSP430 are: 19:48:52 * price 19:49:03 * documentation 19:49:13 otherwise it's pretty nice 19:50:16 when I get mecrisp-across fully setup I'll make a couple of MSP430 projects 19:51:14 want *low power* mode in MSP430, where the power drops from 1mA to 0.4uA , it's ONE instruction ! 19:51:44 cortex-mx takes about 6 months to learn how to handle low power and it's a mind bender 19:52:37 but 500 bytes of flash! 19:52:47 that's ridiculous 19:53:05 actually it's hard to get one under 2kB flash and they do make larger ones 19:53:25 500 bytes goes a long way with MSP430 assembly 19:54:07 whats the smallest binary blinky you can create ? it must flash one led every 1 second or so, and leave no strange pin states 19:54:33 never tried 19:54:43 a default Gcc one is about 20k, hahahah 19:54:58 then optimise it and it drops to about 800 bytes 19:55:22 cheat and use every trick in the book and maybe get it to 300 bytes 19:55:33 (for cortex-m) 19:55:55 --- join: ryke joined #forth 19:55:58 matthias did one in assembly in 28 bytes for cortex-m 19:56:09 and one in 14 bytes for MSP430 19:56:29 thats how much smaller MSP430 code can be 19:56:47 my best in assembly for cortex-m was 80 bytes 19:56:53 that is small 19:57:07 these are self booting binaries 19:57:30 does this include the vectors? 19:57:31 yeah 14 bytes is crazy 19:57:43 yeah 19:58:08 which is only the reset and stack vector I think 19:58:13 it's all you need 19:58:14 you'd probably have to reuse the vector space and make sure those interrupts never get triggered 19:58:33 well they cant if not enabled or used 19:59:02 he does all kinds of stuff, his mind is like taht 19:59:31 he moves the reset vector to a number thats then easily modified for the next step and so on 19:59:41 but get this ! 20:00:05 my best assembly for the MSP430 was 80 bytes, nothing clever, no tricks 20:00:23 just standard boring, uninspired tech coding 20:00:52 but it was in assembly, so nothing was wasted 20:01:33 then I tried it in mecrisp-across writing the blinky in Forth the same way, nothing clever, no tricks just standard boring Forth 20:01:51 and the binary that it generated for the target was 80 bytes! 20:01:59 that blew me away 20:02:20 i cant beat mecrisp-across even with assembly 20:02:22 ! 20:03:11 yet I go from 300 (Gcc) to 80 (assembly) with cortex-m 20:03:54 and still the C acolytes insist on telling me that 'Gcc produces better assembly than you can do by hand' 20:04:24 from everything I've hard, gcc isn't the greatest compiler, rather just everyone uses it because it's free 20:04:30 *heard 20:04:35 sure 20:04:54 yet Gcc was like a gift from the gods when I learnt C in 1997 20:04:56 like when you disassemble its code it produces pretty shoddy code 20:05:22 lots of shuffling values around between registers unnecessarily 20:05:36 up until then Id trued to use some 'limited' C compilers available on the web and they were so bad I was in despair 20:06:13 then I stumbled across DJ Delories DJCC 20:06:25 "DJCC" it think it was 20:06:29 I used to use CodeWarrior and before it Symantec, which was originally think C 20:06:38 it was just Gcc compiled for windows use 20:06:44 I remember people talking about that one 20:06:55 but I never used it because I was not a windows user 20:07:16 I started using gcc when I first got Linux 20:07:18 i couldnt belive how slick, easy and bug free it was compared to all the free windows crap Id tried 20:07:49 at the time I was just divorced and dead broke, I didnt have any money to spend on anything 20:08:16 in fact dgcc was the reason I switched to Linux 20:08:46 I remember when I first used Linux 20:08:56 it was like everything I wanted computing-wise 20:09:07 I thought 'if a C complier made for linux is so good ported to windows, whats it like on Linux ?" 20:09:15 SAME here! 20:10:04 and so I wrote and released a general porpose micro and rom burner for Linux under the GPL back around 1998 20:10:26 it use a parallel port, Gcc, relays and worked great 20:10:50 the first target was a 8051 variant 20:11:01 which was a PITA to flash 20:11:10 I was into something called Freenet and wrote Freenet client software in Python and OCaml back then 20:12:04 I remember trying to learn Perl and absolutely hating it 20:12:06 there is a OSS distributed forum application called "freenet" now 20:12:13 was it anything like that ? 20:13:00 as a tech Perl is ok, CPAN is handy 20:13:23 i prefer shell and Forth to Perl nowdays 20:13:29 this was a distributed file distribution system - not like bittorrent - but rather so that files are distributed over multiple machines in a fashions so that you don't know what's on your machine in the first place, so no one can make you remove it 20:13:46 I also played around with ficl and gforth at the time as well 20:14:03 it was slow and inefficient, but it was also secure 20:14:08 https://freenetproject.org/ 20:14:47 apparently freenetproject is also pretty slow 20:16:43 speed, security, ease of use, ..... choose one of the above ? 20:16:52 that's it 20:17:20 I didn't even know it was still active 20:17:24 wow 20:17:32 small world 20:18:02 it's gaining popularity as people are getting tired of moderated and controlled forums 20:18:34 I remember writing a forum program for an ancient version of freenet circa like 2001 20:18:36 they could just use Usenet instead, but it seems to belong to my generation and hence is 'too old' 20:19:04 usenet is not nearly as secure, whereas this is meant so that people in places like china can securely use the internet 20:19:23 ahh 20:19:46 no usenet was never meant to be secure afaik 20:24:15 it's good to see that it's still maintained 20:24:35 it'd be awful for something like that it to fall into the dustbin of history like so many projects 20:24:48 it's a pretty big dustbin 20:25:26 so how much of your code is in the current freenet.org proj ? 20:30:16 none, as it was not part of that project but rather separate programs 20:30:33 and it's all obsolete, because it was written specifically for now-ancient versions of freenet 20:30:58 ah 20:43:40 C Forth Copyright (c) 2008 FirmWorks 20:43:41 ok 20:43:41 ok 20:43:41 ok 20:43:41 ok 1 1 + . 20:43:41 2 20:45:46 is this the cforth you mentioned? 20:47:35 it is 20:47:55 it compiles fine under Linux and FreeBSD and runs under either 20:48:15 but the STM32F103 and other embedded targets fails bigtime 20:54:42 --- join: rdrop-exit joined #forth 20:55:12 Hello Forthafarians 21:00:24 Hello Fortnighter 21:01:17 hi presiden 21:01:29 what's new 21:02:50 g'day fellow Forthlings 21:03:00 hey rdrop-exit, presiden 21:03:16 Hi tp and tabemann :) 21:03:22 C Forth Copyright (c) 2008 FirmWorks 21:03:22 ok 21:03:34 runs under FreeBSD and Linux 21:03:45 sadly is a bit unmaintained now 21:03:47 cool, Mitch Bradley's? never tried it 21:03:50 yep 21:04:00 --- join: gravicappa joined #forth 21:04:04 has a excellent collection of targets and libraries 21:04:10 and great notes 21:04:12 Started learning about RISC-V today 21:04:17 ahh ") 21:04:37 i need to finish my dev sys porting the risc-v I have 21:04:44 Started off with a video 21:04:56 https://www.youtube.com/watch?v=glS6BaniG8M 21:06:15 well, I'd like to do more work on zeptoforth but I should get to bed 21:06:35 zeppoforth? 21:06:55 oops zepto, I was thinking of the Marx brothers 21:06:58 ;-) 21:07:02 zeptoforth is (well, will be) a native-code cortex-M forth 21:07:08 cool 21:07:47 I decided that the design of hashforth wasn't well-suited for embedded applications, and would have inherent performance limitations on them without hardcore JIT action 21:08:12 and it'd be much easier to just write a forth that is SRT/NCI from the getgo 21:08:20 cool 21:08:37 night-o tabemann 21:09:12 rdrop-exit, *plus* tabemann couldnt find a micro with 2GB ram to run Hashforth from ;-) 21:09:19 I'm looking into the Debug infrastructure of RISC-V, from the point of view of leveraging it for interactive incremental tethered cross-assembly 21:09:43 =8-O 21:09:53 rdrop-exit, wont that vary among implementations ? 21:10:05 the big problem was the token table, which would present more of a performance hit than on a PC because it'd essentially have to do two lookups per token for anything in RAM 21:10:30 to get reasonable performance out of it I'd have to do everything in RAM 21:10:42 but that would make poor use of the massive flash on my board 21:10:49 rdrop-exit, just *getting* the risc-v toolkit is a drama in itself 21:10:51 There's a minimum spec and optional extensions 21:12:07 If I can leverage enough of it, I won't need a custom monitor on the target 21:12:23 that would indeed be cool 21:12:34 tethered with no runtime 21:12:40 rdrop-exit, well you're diving deep into RISC-V, I'm just doing my usual mods to Mecrisp-Quintus 21:12:53 tabemann, exactly 21:13:14 I'm not digging deep yet, just scratching the surface 21:13:25 tabemann, same as mecrisp-across, it works fine on a blank chip 21:13:50 tp: yeah, I saw that it uses the JTAG interface 21:13:55 not too many systems you can plug a blank chip into and suddenly the have Forth on them 21:14:03 tp, I shouldn't need to use any of their risc-v toolkit 21:14:05 yep, 4 wires only 21:14:24 rdrop-exit, making your own assembler ? 21:14:35 I guess so 21:14:37 of course 21:14:43 a Forth powered assembler 21:14:46 RPN assembler 21:15:12 usually that's the easy part, unless their ISA is a mess 21:15:30 tp: question about thumb GNU asm 21:15:40 how do numbered labels work? 21:15:48 i dont know, I cant wait to write some RISC-V assy on my risc-v Forth system and see 21:16:22 tabemann, I use them in Mecrisp-Stellaris 21:16:36 they are relative, which is why 21:17:08 the video is from may 2018, the spec was at version 0.13, I haven't downloaded it yet, this is all preliminary exploration 21:19:09 okay, well, I should actually hit the sack for real now 21:19:35 g'night guys 21:19:40 Won't even need hex files, build up the target incrementally over a tether via the debug interface 21:19:51 goodnight tabemann :) 21:20:25 rdrop-exit, so machine code goes into the target 21:20:37 same as many other tethered forths 21:21:43 rdrop-exit, I did fins that the 'DFU' loader for the GD32VF103 risc-v required a special version of dfu-utils 21:22:13 gd32vflash-v0.1.0 21:22:47 I shouldn't need any special utilities, since I'll just be following the debug spec, to the chip I'm just another debugger 21:25:49 fingers crossed! 21:28:16 have a look at that video on their debug architecture 21:29:04 it's pretty sophisticated 21:31:42 the mcu seems pretty fast, I havent yet looked at what speed it's running at 21:31:55 so much to discover from a $5 board! 21:32:05 cool 21:32:20 it's tiny, like 2cm * 1cm 21:32:37 too small for me, but it was a gift 21:33:02 I prefer to have jtag connectors and so on on the board 21:33:28 but this is a eval I may not even like it yet 21:33:34 it's still so new 21:35:05 you're speaking of a RISC-V board right? 21:38:38 yes 21:38:45 the 'longan-nano' 21:40:13 I'm looking forward to your comparisons of RISC-V vs ARM 21:47:02 me too :) 21:47:09 hopefully pater this week 21:47:13 later 21:47:18 cool!! 21:47:46 I like what I see so far, except one thing has me confused 21:48:37 the GD32VF103 has *exactly* the same GPIOS as the STM32F103 21:48:42 theyre identical 21:49:06 but every register in the GD32VF103 has a different name to any in the STM32F103 21:49:25 even the bitfields have different names 21:50:42 I guess they're trying to leverage existing ecosystem, without trying to paper over the internal differences 21:51:06 i could simply change all the names and just use the STM32F051 ones at least for the GPIOS 21:51:49 I dont think there is a existing ecosystem for the GD32VF103 ? 21:52:01 not in OSS land 21:52:05 it's too new 21:52:27 I meant the ARM ecosystem 21:52:47 even if all the peripherals are identical to the STM32F103, the MCU is alien 21:53:01 only the older M3 peripherals 21:53:23 but changing the names and bitfields is confusing, it must be a copyright thing 21:54:13 when I look into my svd2forth output I'll see if they have improved the STM32 naming which has a couple of flaws 21:54:38 sadly STM had some low level names duplicated 21:54:50 which has caused a fair bit of drama 21:55:24 yikes 21:56:13 very, very late luch is ready. Catch you later :) 21:56:22 * lunch 21:56:26 cya! 21:56:42 3pm lunch! fire the cheff! 21:56:48 -f 23:14:00 --- quit: proteus-guy (Ping timeout: 240 seconds) 23:20:59 --- quit: dddddd (Remote host closed the connection) 23:29:20 --- join: reepca joined #forth 23:35:32 --- quit: gravicappa (Ping timeout: 265 seconds) 23:59:59 --- log: ended forth/19.12.01