00:00:00 --- log: started forth/19.06.19 00:02:36 --- quit: Keshl (Read error: Connection reset by peer) 00:02:42 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 01:10:13 is forth.org still down? 01:27:38 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 01:39:09 seems to be 01:51:55 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:01:37 yayyyyyyyy no more errors! I've been looking at red Forth compiler errors for hours 05:51:09 { dup * } : square \ https://test.ton.org/fiftbase.pdf 05:59:29 is this your lang? 05:59:39 No. 05:59:48 why have the name after the quotation if it can read ahead anyway 05:59:54 It was mentioned here a few days ago. 06:00:16 at least with : square { dup * } it could be recursive 06:03:15 a lot of these changes seem to be pointless 06:04:22 bool {then} {else} cond 06:04:31 I like those changes. 06:04:49 that's what quotations are good for yeah 06:04:58 meh 06:05:03 I just drop out of the word early now, though 06:05:48 rdrops are simpler than if/else 06:08:20 --- join: igstan (~igstan@aftr-62-216-206-62.dynamic.mnet-online.de) joined #forth 06:08:43 --- part: igstan left #forth 06:20:43 --- quit: cantstanya (Remote host closed the connection) 06:23:09 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth 06:52:58 --- join: john_metcalf (~digital_w@host86-161-140-152.range86-161.btcentralplus.com) joined #forth 07:10:56 --- quit: john_metcalf (Ping timeout: 246 seconds) 07:36:05 CORDIC, wow I'm not the only one who sees forth as a natural fit for cryptoledger VMs! 07:36:10 --- quit: tabemann (Ping timeout: 252 seconds) 08:13:20 --- quit: proteusguy (Ping timeout: 245 seconds) 08:19:02 I think crc's Nga would work great in a crypto vm with some minor alterations 08:19:55 don't see why all these crypto stack vms have PUSH1..PUSHn instructions rather than PUSH [LITERAL] though 08:20:22 where the literal is just a word-length signed number 09:51:18 --- quit: rdrop-exit (Quit: Lost terminal) 10:00:43 --- join: proteusguy (~proteusgu@cm-58-10-154-231.revip7.asianet.co.th) joined #forth 10:00:43 --- mode: ChanServ set +v proteusguy 10:17:27 --- join: dys (~dys@tmo-082-158.customers.d1-online.com) joined #forth 11:16:08 --- join: jedb_ (~jedb@185.128.24.51) joined #forth 11:16:53 --- join: aedb (~aedb@h69-128-148-247.crlbnm.broadband.dynamic.tds.net) joined #forth 11:17:53 --- quit: jedb (Ping timeout: 245 seconds) 11:19:45 --- part: aedb left #forth 11:25:23 --- quit: jedb_ (Ping timeout: 246 seconds) 11:27:16 --- join: jedb (~jedb@185.128.24.51) joined #forth 11:36:36 --- quit: dys (Ping timeout: 244 seconds) 12:17:10 --- quit: gravicappa (Ping timeout: 246 seconds) 12:27:54 --- quit: phadthai (Quit: reboot) 12:31:50 --- join: phadthai (mmondor@ginseng.pulsar-zone.net) joined #forth 12:45:38 --- join: dys (~dys@tmo-102-146.customers.d1-online.com) joined #forth 13:56:24 WilhelmVonWeiner: because these VMs are often defined by mathematicians and not computer sciencetists or hackers that know more of the itty-gritty details of the various tradeoffs when defining such. 13:58:56 take for instance the Ethereum Virtual Machine, a few of the opcodes have ambigious meanings implementation wise. Plus there is no easy way to do intra-'"contract"' subroutines. 14:00:01 could be that instructions are encoded with a builtin operand, so the n in PUSHn is builtin 14:00:27 not to mention the intra-'"contract"' calling mechanism design has serious reentrancy bug issues (one that was exploited in the D'OH (ahem DAO) attack) 14:01:41 in Bitcoin Script opcodes there is a section of PUSH0 to PUSH16 which makes sense when you look at the placements into the opcode table. 14:02:15 (think those opcodes all where 0x7_ something where _ is the 'builtin' operand) 14:02:20 should be 0 to 15 14:02:33 sorry, off by one error 14:02:47 just don't let it happen again 14:03:14 Start counting at 3. You will have off-by-2 errors. 14:03:20 But no more off-by-one errors. 14:04:28 regarding smart-contract-VMs for cybercoins and such I quite like what the folks behind Agoric.com are doing. 15:02:45 --- quit: xek (Ping timeout: 244 seconds) 16:35:32 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:40:59 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 16:41:30 hi 16:42:26 g'day dave0 16:42:41 hi tp 16:43:06 getting some cool nights in ydney ? 16:43:10 +S 16:43:45 yeah, it was sunny yesterday but around 4pm the temp drops 16:44:12 same up here, I much prefer it to 40+ days 16:46:19 after running my svd2forth generator on a stm32L072 yesterday and then fixing all the errors I realised I need to make a generic version that does all the STM32 cortex-M types. Its slightly less useful because then custom label legends cant be made, but saves years making labels by hand ;-) 16:47:54 then I realised I can make the generic Words a lot smaller, funny how it takes a few years for me to 'see' the heart of certain Forth issues 16:49:06 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:31:09 --- quit: dddddd (Remote host closed the connection) 17:37:24 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 17:56:36 --- quit: proteusguy (Ping timeout: 272 seconds) 18:01:58 --- quit: tabemann (Ping timeout: 268 seconds) 18:24:23 --- join: tabemann (~tabemann@2600:1700:7990:24e0:a8c3:b476:359:e7d9) joined #forth 19:00:58 --- join: proteusguy (~proteusgu@cm-114-109-129-168.revip13.asianet.co.th) joined #forth 19:00:58 --- mode: ChanServ set +v proteusguy 19:11:15 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 19:23:32 I'm tempted to add preemptive multitasking to hashforth, even though I know I probably shouldn't 19:27:35 --- quit: PoppaVic (Ping timeout: 250 seconds) 19:29:31 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 19:37:38 haha don't succumb to the temptation! ;-) 19:42:16 --- quit: proteusguy (Ping timeout: 244 seconds) 19:45:35 should DO be simpler at all than ?DO ? right now, it's just a jump over the ?DO 19:46:42 Real Men use FOR/NEXT ;-) 19:48:43 :P 19:48:56 not in the 2012 spec -> I don't know of its existence 19:49:16 heh.. "spec".. that's so cute ;-) 19:49:29 I treat it as informal advice 19:51:14 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 19:54:42 --- join: proteusguy (~proteusgu@180.183.96.185) joined #forth 19:54:42 --- mode: ChanServ set +v proteusguy 20:06:44 --- quit: dave0 (Quit: dave's not here) 20:29:03 back 20:29:20 c[_] hi tabemann 20:29:26 hey guys 20:29:45 for some reason I'm tempted to add preemptive multitasking to hashforth 20:29:57 resist 20:29:58 --- quit: X-Scale (Read error: Connection reset by peer) 20:30:33 because at a runtime level it is really simple - just set an alarm, that in a signal handler sets a flag, and that in the inner loop of the interpreter, it breaks out if that flag is set, and then calls an interrupt hander routine 20:33:44 hmmm... sounds fairly course grained, no? The finer grained it is the more overhead it's going to take on your performance of your regular code. 20:35:31 it can be very coarse-grained to as fine-grained as the OS, in a hosted environment, or a timer interrupt, in an embedded environment permits 20:36:06 if I were to implement this, PAUSE would still be available and still would be the recommended means of transferring control 20:36:58 the real reason why I thought of this is that in my Life implementation each frame takes a relatively long period of time, and I don't want to be figuring out some way to call PAUSE in the middle of generating a frame 20:37:34 I was thinking of making alarm signals be every 1/50th of a second 20:37:57 sounds like kind of an interpreter-assisted cooperative multi-tasking. Which is probably an ok kinda thing if you have a compelling use case for it. 20:38:25 I would make it as course as possible. 20:38:38 Sounds like you want to add interrupts to your "virtual processor", you can do that without adding preemptive multitasking 20:38:39 coarse, too 20:38:49 haha 20:38:50 or two - as the case may be 20:38:56 yes coarse. 20:39:08 yes coarse, of course. 20:39:18 off course 20:39:24 rdrop-exit: yes, the alarm interrupts enable preemptive multitasking, but they do not necessitate it 20:39:31 PoppaVic, ...often! 20:40:02 really it is a general interrupt mechanism, it's just on hosted environments one main use alarm handling 20:40:29 on embedded environments it could be used for other things, such as any kind of processor interrupt 20:41:42 What's generating the alarm? 20:42:41 proteusguy: a system call to the OS would set an alarm, on hosted environments, which would at a later time result in SIGALRM 20:43:29 on embedded environments it would be dependent on the exact chip, but I presume it would be setting some IO registers which would turn on timer interrupts 20:44:38 in a hosted environment alarms would be one-shot 20:44:55 i.e. each time an alarm is desired it has to be turned on again 20:45:26 whereas in embedded environments timer interrupts may occur regularly until they are turned off 20:47:23 How will you deal other interrupt sources aside from timers? 20:48:38 rdrop-exit: I would probably pass the interrupt handler a value indicating what kind of interrupt it is; on hosted environments it would be a signal number or equivalent, on embedded environments it would be an IRQ number or equivalent 20:49:25 but interrupt handlers may have to poll multiple things to determine the cause of an interrupt, as in the case of IRQ numbers being shared amongst multiple devices 20:51:16 actually 20:51:21 now that I think of it 20:51:27 I wouldn't pass in a value 20:51:39 I would have an array of interrupt types 20:51:59 and the original handler within the implementation would set the corresponding index in the array to TRUE 20:52:09 so if multiple different interrupts came in close succession 20:52:22 the types of the different interrupts would not mask each other 20:53:14 I could even make it so it's not a boolean but a count 20:53:26 and each time an interrupt is handled it increments the corresponding count 20:53:48 so if two of the same interrupt came in in close succession, the count would be 2 20:53:58 and when the count rolls over? 20:54:37 considering that each of these are going to be a cell, if the interrupt handler can't handle them fast enough, we've got bigger problems 20:55:00 (the handler would reset these back to zero) 20:55:04 You're going to keep a cell-sized count for each interrupt? 20:55:54 I can see how on embedded systems you might want it to be byte-sized 20:56:25 whereas on hosted environments, if you can't devote a cell to each signal you really have not enough memory 20:57:07 you could just have a status word with a single bit for each source 20:57:37 that's essentially what I was originally thinking of 20:57:53 the counts were because of the chance of interrupts in close succession 20:58:58 Just copy how your favorite ISA deals with it 21:00:05 "my favorite ISA" would be ARM, simply because any on-metal implementation is almsot certainly going to be for ARM first, before any other platforms 21:01:12 (the first implementation is for x86-64 in its current form, but that doesn't count because it doesn't have access to real interrupts due to being hosted, instead having signals) 21:02:19 So now your virtual processor has interrupts and cooperative multi-tasking. What was the reason you also wanted preemptive multitasking? 21:05:13 because I have written code that takes up lots of processor time per unit of computation, and it would be awkward to add PAUSEs into the code because what it does is coherent units of computation that are indivisible 21:05:21 specifically my Life implementation 21:05:56 currently my Life implementation uses 100% CPU without PAUSEing, but even if I added PAUSEs, it would only have a real opportunity to PAUSE a few times a second 21:06:16 i.e. once a frame 21:09:18 I'm not sure what you mean by indivisible. 21:10:32 let's say I have a loop which goes over each line of the screen, and another loop which goes over each pixel in each line 21:10:45 there are only three real ways to divide this up 21:10:50 Start by looking at loops for PAUSE opportunities. 21:10:51 PAUSE once for the whole thing 21:10:57 PAUSE once per line 21:11:00 PAUSE once per pixel 21:11:19 the first is not often enough, the second two are too often 21:12:19 to try to divide it up any other way introduces unnecessary complexity 21:12:46 There's no I/O happening? 21:13:08 there's IO occurring once per frame 21:13:20 after it's calculated everything 21:13:54 How did you determine what is "too often" and "not often enough"? 21:14:17 Did you test those assumptions? 21:14:58 I'm basing it off the assumption that I want ~50 PAUSEs per second 21:15:22 there are only a few frames per second (not enough PAUSEs) 21:15:38 there are 512 lines on the screen (far too many PAUSEs) 21:15:58 there are 512 * 512 pixels on the screen (way way too many PAUSEs) 21:16:39 pause on line % 10 == 0 21:16:59 Exactly, pause every so many lines 21:17:41 How did you determine 50 context switches per second is what you need? 21:17:42 (divided by frames per second of course) 21:18:47 rdrop-exit: it sounds stupid, but because the Haskell runtime IIRC defaults to 50 context switches when no thread yields, so I figured that number was chosen for good reason 21:20:37 So for the moment it's just an arbitrary number 21:21:36 Why don't you PAUSE once per line for the moment 21:22:43 Change only if experimental data tells you to 21:22:48 it is an arbitrary number, but even if we chose some number, using the raw framerate would yield too small a number (since there are only about 4 or so frames a second it seems), but using lines would yield way too many (e.g. the Linux kernel last time I checked preempted 100 times a second, and 512 * number of frames per second is far larger than that) 21:24:18 I could try doing it once a line just to see what kind of performance hit it results in 21:24:47 --- join: gravicappa (~gravicapp@h83-174-248-9.dyn.bashtel.ru) joined #forth 21:25:03 Adjust based on experimental data 21:25:23 Don't put too much faith in arbitrary numbers 21:28:59 What are the other tasks doing? 21:31:45 right now I'm just having it PAUSE without any other loads 21:32:03 So it doesn't really matter anyway 21:32:38 there is one other task, which handles select() 21:34:36 So at the moment PAUSing is irrelevant to your application 21:36:24 okay, I did a test of 500 cycles of Life 21:36:38 the PAUSing code is slightly slower, but not by much 21:37:47 now I am going to use some code that will put a load on the system to run side by side with Life 21:45:48 and 21:46:10 I tried it with my test load... and it all hangs 21:46:31 and I know it's not doing anything because my CPU load isn't maxed on one core as I'd expect 21:49:30 Bummer, sounds like your PAUSE has a bug 21:50:12 or more likely that select() related task 21:52:33 I must say, it's a lot of fun developing new Forths and development environments 21:53:46 what's fun is that I cannot even do anything other than close the terminal because it crashes while displaying the sixel data 21:54:05 --- part: PoppaVic left #forth 21:55:04 and it's the interaction between the life code and the load, because it works just fine, one CPU maxed, when the load by itself is running 21:56:55 what's also interesting is that it does not crash right away, rather it waits some seconds before it crashes 21:57:08 as memory runs out ? 21:57:26 my sixel code and my load code function in constant memory space 21:57:48 as in all their memory is ALLOTed.... unless a stack is exploding 21:58:12 my guess is the stack of one of these things is going through the roof 21:58:28 and it crashes when the stack collides with the dictionary 21:58:44 how do you debug such possibilities ? 21:59:44 have you seen "Cutter/radare2" ? 21:59:48 the only thing is that it has to be the life code whose stack is exploding, as it exists in the main thread, which has lots of task space 21:59:54 Cutter/radare2? 21:59:59 it's a reverse engineering tool 22:00:19 it dissasembles and single steps 22:00:47 the load has two tasks with absolutely tiny stacks, so if one of those was blowing up it should happen immediately 22:00:59 I've been testing it on my simple cortex-m0 assembly and it's pretty nice! 22:01:28 I've never tried it myself 22:01:52 it's pretty simple to run with the GUI (cutter) or cli with radare2 22:02:24 I'm growing quite fond of it, it has a very solid feel, but still under development, some rough edges 22:02:38 Put in a check to make sure the stack heights are the same before and after a PAUSE 22:02:51 rdrop-exit: good idea 22:04:53 https://github.com/radareorg/cutter 22:06:22 bbiab 22:09:08 and... my stack check not only doesn't catch anything, but because I turned off sixel display it doesn't crash 23:53:53 --- quit: dys (Ping timeout: 244 seconds) 23:59:59 --- log: ended forth/19.06.19