00:00:00 --- log: started forth/20.03.21 00:18:06 --- quit: Mellowlink (Ping timeout: 240 seconds) 00:18:24 --- quit: cartwright (Read error: Connection reset by peer) 00:23:05 --- join: cartwright joined #forth 00:24:07 --- join: Mellowlink joined #forth 01:05:27 --- quit: iyzsong (Ping timeout: 246 seconds) 01:30:17 --- join: iyzsong joined #forth 01:48:32 --- join: xek joined #forth 02:50:19 --- quit: actuallybatman (Ping timeout: 250 seconds) 02:54:17 --- quit: xek (Ping timeout: 250 seconds) 02:55:31 Who is dddddd? They were asking me about some computers before I went on holiday to a place without internet 02:55:47 Oh well catch them later I suppose 03:24:25 --- quit: _whitelogger (Remote host closed the connection) 03:27:28 --- join: _whitelogger joined #forth 05:05:03 --- join: dddddd joined #forth 06:26:03 --- quit: iyzsong (Ping timeout: 246 seconds) 06:46:13 --- join: dave69 joined #forth 06:46:32 --- quit: dave0 (Disconnected by services) 06:46:37 --- nick: dave69 -> dave0 07:54:51 --- quit: dave0 (Quit: dave's not here) 09:11:29 --- join: dddddd_ joined #forth 09:12:36 --- quit: deesix (Ping timeout: 264 seconds) 09:12:43 --- quit: dddddd (Ping timeout: 246 seconds) 09:12:58 --- nick: dddddd_ -> dddddd 09:13:25 --- join: deesix joined #forth 09:18:05 --- quit: Zarutian_HTC (Quit: Bye) 09:38:41 --- join: xek joined #forth 10:18:44 In the book "Starting FORTH", DEPTH is defined as : DEPTH S0 @ 'S - 2/ 2- ; 10:19:03 That doesn't make any sense to me, does this actually work on any Forth? 10:20:03 I'm confused that S0 would be a variable, and not just return the base of the stack, it's been mentioned elsewhere that S0 is "beyond" the stack so one cell must be removed, but the 2- is done after dividing 10:20:44 So that's like compensating for 2 cells ( i.e. 2/ 2- is the same as 4 - 2/ ) 10:46:41 back 10:47:01 --- join: actuallybatman joined #forth 10:51:35 that's simple 10:51:43 it assumes 16 bit cells 10:52:07 S0 @ must be the bottom of the stack 10:52:37 there is a mistake though 10:52:51 2- should be before 2/ or it should be 1- after 2/ 11:45:36 --- quit: jsoft (Ping timeout: 264 seconds) 11:46:49 --- join: f-a joined #forth 11:47:13 so, are you all hoarding... tp? 11:47:16 ( ͡° ͜ʖ ͡°) 12:06:53 tabemann: Okay that is my guess, would be very confusing to someone typing that in though, given this is meant to be a helpful example early on 12:13:55 --- quit: f-a (Quit: leaving) 12:43:12 --- join: rdrop-exit joined #forth 12:43:27 veltas, I think that's a typo 12:44:26 in the first edition of Starting Forth (the 79 standard one) 12:45:07 The 2nd edition (i.e., the 83 standard compliant one) doesn't define DEPTH 12:45:37 --- quit: actuallybatman (Quit: leaving) 12:45:59 A more typical defintion of depth on a 16 bit system would be 12:46:34 sp@ s0 @ swap - 2/ 12:49:35 veltas, to answer your question on why s0 needs to be fetched, it's because s0 is a USER variable on multi-tasking Forths since each task has its own 12:50:16 gotta sleep, goodnight 12:50:21 --- quit: rdrop-exit (Quit: Lost terminal) 13:34:45 --- quit: tabemann (Ping timeout: 250 seconds) 14:19:18 --- join: Zarutian_HTC joined #forth 14:20:45 --- join: tabemann joined #forth 14:57:00 --- quit: gravicappa (Ping timeout: 264 seconds) 14:58:19 hey guys 15:11:15 tabemann: hey 15:11:58 * tabemann just fixed a nasty bug that was causing stack problems, but inexplicably wasn't causing zeptoforth to crash despite also generating corrupt machine code 15:24:58 I only found the bug because there was another bug that was causing an extraneous value to be put on the stack which I had just fixed 15:27:09 And that caused an actual effect from the nasty bug? 15:33:56 --- quit: xek (Ping timeout: 240 seconds) 15:38:54 yes 15:40:20 the actual bug was that when UNTIL was compiling a 32-bit beq word - which only occurred with a long enough of a jump - it was erroneously not exiting but rather also compiling a 16-bit beq word 15:40:45 which was taking up a cell from the stack for a destination address 15:41:09 but even though this instruction would be garbage, it would still be a beq instruction 15:41:33 and because the status register would already be set for Z == 0, this one wouldn't branch either 16:00:26 --- join: actuallybatman joined #forth 16:15:04 --- quit: Bunny351 (Remote host closed the connection) 16:15:22 --- join: Bunny351 joined #forth 16:29:18 Nasty 16:30:28 I'm only permitting 8-bit jumps in my forth 16:31:24 can you trap bad instructions on ARM? 16:33:53 But they are all directed with logical bases, i.e. the 8-bit 'jump' used for an IF considers the next forth instruction following IF+jump as 0, and goes to 255. Likewise the LOOP jump distance starts at the LOOP itself and goes 255 back. 16:35:04 MrMobius: Apparantly the undefined instruction exception is the same as the divide by 0 exception 16:35:22 So from that I will assume you have a decent amount of control in baremetal and also in a hosted program 16:35:55 So yes you can trap bad instructions 17:06:23 --- join: jsoft joined #forth 18:17:25 back 18:19:12 wow 18:19:51 just the kernel and the basic Forth source code loaded together in flash come out at $B670, including a cornerstone 18:20:06 well wait there's also a test program in there 18:21:42 without the test program, but with the cornerstone, it's $B000 18:27:38 --- quit: Mellowlink (Remote host closed the connection) 18:28:51 --- join: Mellowlink joined #forth 18:33:41 hi all!\ 18:33:56 hey tp 18:34:04 tabemann, I dl and compiled zeptoforth no problemo 18:34:21 I'm wondering why zeptoforth compiled code is so non-dense 18:34:23 cool 18:34:23 sadly I have no M4+ 18:34:48 yeah, at the moment it requires an STM32L476 DISO board 18:35:02 you could always write driver code to make it work on an M3! 18:35:20 *DISCO 18:35:22 I started modifying your console.s then realised that my M4 isnt a + version (L) 18:35:52 I have a couple of F407's but the L code is totally different 18:36:03 the vast majority of the code, as written, should work on any Thumb-2 system 18:36:18 I discovered that when I was porting my code to M0+ 18:36:39 the big thing is the driver code 18:37:07 the code to set the clock, the code to configure the UART and flash, the code to interact with the UART and flash 18:37:28 flash will be different 18:37:42 clocks are different 18:38:18 plus I have too many other projects to finish :) 18:38:23 but yeah, feel perfectly free to do a pull request and make the necessary changes to port it 18:39:51 all I can offer to do is test it if you produce a stm32F4xx version 18:40:20 but I dont use the F4 either, Im a cortex-M0 user as you know 18:40:37 don't expect an M0 version any time soon 18:40:53 due to the fundamental differences between thumb-1 and thumb-2 18:41:41 which STM32F4xx version do you recommend? 18:43:55 the F4 disco is a good choice, (STM32F407) but it doesnt have a Ethernet port, but has a audio codec. Any F4xxxx is ok, theyre all much the same 18:44:41 the only thing that changes between models is the serial port availability and perhaps flash methods 18:44:51 I've found that with Mecrisp-Stellaris 18:44:52 I'll to STM32F407 18:45:04 *do 18:45:44 for instance the erased state of the F0 and F3 are both high, but the f0+ is low iirc 18:46:40 at least matthias does all models of STM32xxxx, he flatly refuses to do atmel SAMxxxx because of their flash limitations 18:52:54 overly large flash write blocks would definitely be aproblem 18:53:03 thats the problem 18:54:25 he educated me about the complexity of flash, I was blissfully ignorant as the last proms I wrote code to program were eproms and they could be done on a byte by byte basis 18:55:23 hmm, as f0 can only be done on a half word basis, does that mean the flash is actually 16 bit bytes ? 19:13:45 f407 seems to support both halfword and byte flash writes 19:15:00 whereas stm32l476 seems to support only 16 and maybe 8 byte writes 19:17:41 I think the F4 class have a lot of options 19:19:35 bbl 19:33:04 --- join: iyzsong joined #forth 19:47:55 --- join: dave0 joined #forth 19:48:46 --- join: boru` joined #forth 19:48:49 --- quit: boru (Disconnected by services) 19:48:51 --- nick: boru` -> boru 20:24:20 * Zarutian_HTC muses about cpu architectures 20:25:13 heyhey Zarutian_HTC 20:25:40 * Zarutian_HTC is rather insomniac these nights 20:25:49 h'lo tp 20:25:59 Zarutian_HTC, but your nights are 24 hours long ? 20:26:46 tp: no, there are actual daylight during the day this time of year 20:28:36 re cpus: a lot of contemporary stuff that is in cpus are due to lack of revaluation of memory design 20:29:41 Zarutian_HTC, I'm still amazed that they can make cpus at all. Ive been in this state of amazement since 1974 20:30:43 I've heard the process is so complex now that no one person can understand it all 20:31:01 the L caches, branch prediction, out of order exec, pipelining and such all arose from cpus getting faster than the memories they are fetching instructions and data from 20:31:05 so Im not surprised that there is lack of revaluation 20:31:21 yeah, flash is slow 20:32:16 flash isnt that much slow but having to earase a block makes writing to it slow 20:32:40 Ive been working on accurate stack comments lately and had to laugh last night 20:32:47 that it does 20:32:53 some chips do a cool thing where they fetch a lot of bits in parallel from flash 20:33:05 but I am not talking about the memory cell tech but the arrangement and use of memories 20:33:08 so they fill the cache faster than the CPU executes 20:33:32 I decided to add the actual stack contents rather than "x" without thinking it thru 20:34:09 the first one in a group of 32 bits was file 20:34:12 nine 20:34:14 oops 20:34:16 fine 20:34:56 MrMobious: here is the thing. I have started to look at the L2 cache of an cpu as its actual main memory 20:35:00 " : GPIOF_BSRR_BS0 ( -- #1 ) 0 bit GPIOF_BSRR ; " 20:35:18 but the last one with bit 32 wasnt so good ;-) 20:35:36 " : GPIOF_BSRR_BR15 ( -- #2.147483648e+09 ) 31 bit GPIOF_BSRR ;" 20:35:44 oops 20:36:10 ill leave you folks to discuss the finer points of cpu design :) 20:36:14 MrMobious: and that got me thinking why the hell is this expensive ContentAddressableMemory being used? 20:38:20 because, the process is being tricked into thinking that it has this vast address space to avail itself of 20:39:58 which has become heavily leaky abstraction as many programming gudies on getting your program to go fast talk about maintaining cache locality 20:42:53 --- quit: dddddd (Remote host closed the connection) 20:48:44 --- join: rdrop-exit joined #forth 21:19:14 --- join: Zarutian_HTC| joined #forth 21:19:15 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 21:19:52 --- quit: Zarutian_HTC| (Client Quit) 21:31:37 --- join: gravicappa joined #forth 22:01:17 hey guys 22:07:48 hey tabemann 22:11:54 I'm currently working on my f407 port 22:12:03 oh cool 22:12:15 i can try it out anytime youre reeady 22:12:53 the main complex point is flash 22:12:54 Im using USART2, but there is a possible problem as USART2_RTS is connected to one pin of the audio-codex 22:13:14 yeah, I'm not surprised 22:13:52 I'll add RTS to it when youre done and probably change the USART number away from 2 22:14:29 can you have a configure option to disable your ACK method ? 22:29:54 back 22:30:09 tp: not at the moment 22:30:17 no problemo 22:30:20 I made words for sending XON and XOFF 22:30:30 which can be put in the code instead of ACK and NAK 22:30:59 the big difference I'm finding with L407 is that with flash I can write individual bytes 22:31:02 or halfwords 22:31:15 *F407 22:31:20 whereas with L476 22:31:28 bytes *and* halfwords ? 22:31:34 I had to have an elaborate system for buffering flash writes 22:31:37 yes 22:31:41 nice 22:31:55 you can tell it whether you're writing a byte or a halfword 22:32:05 this will make it much more efficient in space usage 22:32:19 but in RAM and in Flash 22:32:23 the L series may only be a interim type I think as they have replaced the F and L with the G in one variant I have just become aware off 22:32:54 with the G having the low power facilities of the L and the speed of the F 22:33:22 didn't know that 22:36:15 i only just found out and it's just my observation 22:36:34 i can easily try your XON system 22:36:51 ugh 22:37:20 do you know offchance what the erase block size for F407 is? 22:37:25 and mine will ignore your ACK 22:37:32 no 22:37:54 I've never used it with Mecrisp-Stellaris 22:38:15 because I need to know that before I can adapt the erasure code for Mecrisp-Stellaris to zeptoforth 22:38:21 other than to flash it and get a prompt 22:39:00 and I need to half that working before I can have stuff like cornerstones working 22:39:10 of course 22:41:26 ill see if I can find out 22:43:18 okay, I'm commenting out the erasure code for the time being 22:50:15 I made it so the erasure words exist, but they don't do anything 22:51:21 --- quit: proteus-guy (Read error: Connection reset by peer) 22:51:35 sure 22:51:43 thats what I do with my top down designs 22:51:49 --- join: proteus-guy joined #forth 23:12:46 hey proteus-guy 23:13:04 tp: what exactly are the ROM and RAM sizes for the F407? 23:14:40 looking 23:15:45 128 kb ram 23:16:19 1024kB flash 23:16:56 thats from the Mecrisp-Stellaris mecrisp-stellaris-stm32f407.s 23:24:06 that's what I thought 23:24:11 I just pushed the code 23:24:16 don't expect it to work though 23:25:29 easy to test tho 23:26:20 also, erasing seems to be currently broken in general 23:28:25 okay, I just pushed new code to remove a reference to the LED driver from the STM32F407 code 23:29:16 plus your makefile needs updating with the mcu choice ? 23:29:51 there's a PLATFORM variable 23:30:29 and as for the gas parameter, it's just -mcpu=cortex-m4 -mthumb -g which should be the same for both 23:31:37 compile it with: make PLATFORM=stm32f407 23:32:43 ok ta 23:37:44 any luck? 23:42:33 oh, and feel free to send me a pull request - I'd be glad to have more people working on this, particularly for getting it to work on other boards and such 23:43:32 note that I did make some idiosyncretic choices, e.g. b@ b! b, instead of c@ c! c, (because in this day and age one cannot count on a byte being a character, with unicode and whatnot) 23:45:13 note that I should really get off to bed now 23:46:05 sorry busy chatting with daughter` 23:46:32 ill leave a outcome message here for you 23:46:41 oh that's fine 23:46:45 g'night 23:46:50 night-o 23:59:59 --- log: ended forth/20.03.21