00:00:00 --- log: started forth/19.01.14 00:05:54 --- quit: dys (Ping timeout: 258 seconds) 00:19:28 --- quit: pierpal (Read error: Connection reset by peer) 00:19:40 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 00:23:45 --- quit: pierpal (Ping timeout: 245 seconds) 00:29:07 --- quit: nighty- (Quit: Disappears in a puff of smoke) 00:40:09 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 00:48:49 --- quit: presiden (Remote host closed the connection) 01:27:26 --- quit: pierpal (Quit: Poof) 01:27:44 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 02:02:30 --- quit: ashirase (Ping timeout: 245 seconds) 02:19:10 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:52:46 --- join: Insert_Coin (~insertCoi@h081217214054.dyn.cm.kabsi.at) joined #forth 02:53:22 --- quit: Insert_Coin (Remote host closed the connection) 02:53:41 --- join: AGreenGrasshoppe (~AGreenGra@h081217214054.dyn.cm.kabsi.at) joined #forth 02:54:37 --- part: AGreenGrasshoppe left #forth 02:57:32 --- join: GreenGrasshopper (~GreenGras@h081217214054.dyn.cm.kabsi.at) joined #forth 02:58:59 --- quit: pierpal (Quit: Poof) 02:59:18 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 03:32:17 --- join: dddddd_ (~dddddd@unaffiliated/dddddd) joined #forth 03:32:56 --- nick: dddddd_ -> dddddd 03:36:14 --- quit: pierpal (Quit: Poof) 03:36:35 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 03:48:11 Just mapped how TI-OS lets the user type many different characters through "input modes" 03:48:13 https://raw.githubusercontent.com/siraben/zkeme80/aefe100f0ce837cd5f318179aff51416806b10d2/key.png 03:48:29 There's a lot of unneeded complexity there, I think I'll do things differently for my OS 03:49:13 Alphabetic input by default, then if the user holds 2nd while pressing the keys, it will allow input of 0-9 03:51:29 I'll also add an "insert mode" and "replace mode" so the user can edit the current line easily 04:00:35 I wish I had a data cable for my 83 Plus. 04:01:58 --- join: jedb_ (jedb@gateway/vpn/mullvad/x-wimfguofjuezcrnk) joined #forth 04:02:19 I could order one on amazon... Hmm... 04:04:04 Or you could use an emulator! 04:04:29 Z80 assembly is quite fun to program in, but only to get the Forth layer :) 04:05:01 --- quit: jedb (Ping timeout: 246 seconds) 04:08:05 --- nick: jedb_ -> jedb 04:31:40 Just updated the demo again: https://raw.githubusercontent.com/siraben/zkeme80/a28229068b971d67942ed10ccd44df5101dcf7c2/demo.gif 04:50:27 --- quit: pierpal (Quit: Poof) 04:50:44 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 05:11:06 siraben, cool - making progress. 05:17:51 --- quit: pierpal (Quit: Poof) 05:18:12 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 05:23:25 siraben, sent you an email earlier today with lots of fun reading material... :-) 05:36:49 proteus-dude: got it, thanks! 06:03:11 --- join: proteusguy2 (~yaaic@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 06:03:11 --- quit: proteusguy (Read error: Connection reset by peer) 06:03:36 --- quit: proteus-dude (Remote host closed the connection) 06:07:17 --- quit: proteusguy2 (Read error: Connection reset by peer) 06:07:35 --- join: proteusguy (~yaaic@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 06:07:35 --- mode: ChanServ set +v proteusguy 06:09:03 --- join: proteusguy2 (~yaaic@2001:44c8:42c7:e9c6:1:1:aa9a:fa5b) joined #forth 06:11:44 --- quit: proteusguy (Ping timeout: 250 seconds) 06:34:58 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 06:47:52 --- join: Kumool (~Khwerz@adsl-64-237-235-188.prtc.net) joined #forth 07:00:34 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 07:01:24 --- quit: pierpal (Remote host closed the connection) 07:10:50 --- quit: Kumool (Ping timeout: 245 seconds) 07:12:56 --- join: Kumool (~Khwerz@adsl-64-237-235-188.prtc.net) joined #forth 07:14:09 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 07:15:34 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 07:21:24 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 07:28:21 --- join: proteusguy (~proteus-b@2001:44c8:42c7:e9c6:54e9:5edc:1401:bd5f) joined #forth 07:28:21 --- mode: ChanServ set +v proteusguy 07:35:13 --- quit: tabemann (Ping timeout: 268 seconds) 07:57:51 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 08:27:08 --- quit: proteusguy2 (Read error: Connection reset by peer) 08:27:29 --- join: proteusguy2 (~yaaic@cm-58-10-209-198.revip7.asianet.co.th) joined #forth 08:31:19 --- quit: proteusguy (Ping timeout: 252 seconds) 08:44:21 --- join: proteusguy (~proteus-b@cm-58-10-209-198.revip7.asianet.co.th) joined #forth 08:44:21 --- mode: ChanServ set +v proteusguy 08:49:02 --- quit: proteusguy (Ping timeout: 250 seconds) 09:01:36 --- join: proteusguy (~proteus-b@cm-58-10-209-198.revip7.asianet.co.th) joined #forth 09:01:36 --- mode: ChanServ set +v proteusguy 09:23:49 --- quit: X-Scale (Ping timeout: 240 seconds) 09:26:45 --- join: X-Scale` (~ARM@83.223.227.137) joined #forth 09:27:02 --- nick: X-Scale` -> X-Scale 10:03:43 --- quit: pierpal (Quit: Poof) 10:04:00 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 10:34:32 --- quit: Kumool (Quit: EXIT) 11:28:29 --- quit: gravicappa (Ping timeout: 240 seconds) 11:54:02 --- quit: pierpal (Quit: Poof) 11:54:22 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 12:22:17 --- quit: proteusguy2 (Ping timeout: 258 seconds) 12:47:31 --- join: dys (~dys@tmo-081-43.customers.d1-online.com) joined #forth 12:58:04 --- quit: dys (Ping timeout: 246 seconds) 13:04:58 --- join: arrdem_ (sid333803@gateway/web/irccloud.com/x-jzlviknpxdxiidmx) joined #forth 13:05:46 --- join: pointfree_ (sid204397@gateway/web/irccloud.com/x-fnwvlaqahvgbzddn) joined #forth 13:07:47 --- join: TheCephalopod (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 13:12:00 --- quit: arrdem (Ping timeout: 268 seconds) 13:12:01 --- quit: carc (Ping timeout: 268 seconds) 13:12:01 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 13:12:05 --- quit: siraben (Ping timeout: 268 seconds) 13:12:07 --- quit: pointfree (Ping timeout: 268 seconds) 13:12:07 --- join: carc (~carc@2001:41d0:52:cff::f85) joined #forth 13:12:09 --- nick: pointfree_ -> pointfree 13:12:12 --- quit: carc (Changing host) 13:12:12 --- join: carc (~carc@unaffiliated/carc) joined #forth 13:14:02 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-xbxcpheouhnjaclu) joined #forth 13:29:13 --- quit: xek (Ping timeout: 244 seconds) 13:47:21 are there any one-file Forths in C? 13:57:43 I have done a single file retro (repl & minimal image in a single ~1100 line .c file) 13:57:55 jonesforth 13:57:58 there's also https://github.com/paraplegic/OneFileForth/blob/master/src/OneFileForth.c 13:58:12 I don't see much value to "onefile forth" 13:58:40 I would definitely eyeball the makefile and wtf they subdivided, though 14:02:52 PoppaVic: I generally separate out the simulated I/O devices from the VM, and have an embeddable copy of the image as a separate file. 14:03:27 sometimes it's helpful to be able to just have a single file to deal with though 14:03:28 crc: all I mean is "one file" is usually a misnomer, or a clusterfuck. 14:04:09 meh.. for Arduino, maybe 14:04:13 additionally, sometimes a c compiler can generate slightly "better" code if it can analyse everything at once 14:04:13 ..or c++ 14:04:47 crc: dude, if the compiler is what you plan to save you, yer already gefuckt 14:04:54 https://forthworks.com/share/220728a9f93d76327ffc7b3e8ead4893 is a single-file copy of retro 14:07:15 "I am going to write a damned tool in C because I am pissed" - This is where I cheer folks on for "option that bastard, call it a day" 14:12:44 crc: yup - it definitely can help - esp. if each source file includes a bunch of the same headers as the other files.... for some stuff, i optimised my build by just using one source with a bunch of #include "file.cpp" 14:13:11 and, including SOURCE is considered "wrong" 14:13:39 yes - but this was a build optimisation 14:13:52 I don't generally obsess over optimizations 14:13:55 the_cuckoo: does.not.matter: it'd be considered WRONG 14:14:31 and again - a build time optimisation :) - not a development practice :) 14:16:15 this is especially true of c++ - if you have a lot of common headers, in a lot of small source files - the compilation time is spent processing the headers 14:17:47 you can develop and do incremental builds this way just fine, but if you want a fast 'build' for release, you can generate a source which includes each and process those headers once - this saves a lot of processing grunt n the server and is easier to manage cross platform than precompiled headers (which do pretty much the same thing in reverse) 14:19:20 if you're doing small mods on specific sources (as in, normal edit, build, test type dev stuff), you don't want to do this 14:21:47 and fwiw, it's pretty trivial to do it properly and implement everything in headers anyway :D 14:28:49 --- quit: PSnacks (Ping timeout: 250 seconds) 14:29:01 --- join: PSnacks (~PSnacks@p200300CB27033EFC6095E2F40BB6D367.dip0.t-ipconnect.de) joined #forth 14:35:14 --- join: dys (~dys@tmo-122-234.customers.d1-online.com) joined #forth 14:35:29 ... sorry - didn't mean to stop the discussion :) - fwiw, i think it does do better optimisation, but that's more of a side effect than the reason for doing it (and it's mostly about hardware at work not being able to handle builds for every checkin [overloaded virtualised box with multiple os's :)]) 14:37:40 but i think it's an interesting technique anyway and could be used to divide large files into a few generated files - like 1 for each core or somehthing - and really, the end result is fine - ther should be no difference in execution (honest) 14:38:09 sorry - large files = large projects with many files 14:38:23 (and don't mind me - i'll go back to lurking :)) 14:38:54 crc: Retro is one source of knowledge I'm following. I rewrote out the source of Nga one time to learn how it works better. 14:39:54 PoppaVic: I just mean "one file" as in "bare-minimum" really 14:44:55 WilhelmVonWeiner: near as I can tell, no one in here groks "bare-minimum" - just based on the arguments. 14:48:53 Or. perhaps more accurately: There are a few that grok it, but almost all arguments are against it. 15:00:34 --- quit: dys (Ping timeout: 246 seconds) 15:59:42 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 16:00:28 ahoy 16:00:55 --- join: Kumool (~Khwerz@adsl-64-237-239-252.prtc.net) joined #forth 16:03:46 hi dave0 16:03:54 hi crc 16:10:00 dave0: what are you up to 16:10:28 nuffing, just drinking my coffee! C4(___)~ C8(___)~ C3(___)~ C2(___)~ 16:10:39 how cute 16:10:55 --- quit: TheCephalopod (Ping timeout: 252 seconds) 16:11:29 I need coffee to stay focused 16:11:38 my eye strain has gotten seriously bad over the past couple days 16:12:42 I call it "blindness" - and it's gottten worse my whole life. 16:12:59 --- join: TheCephalopod (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:13:49 I'm 23 and want to keep my vision 16:14:08 I might go see the opthamologist, and if they won't have me i'll just see a regular optometrist. 16:14:09 There is going to be a point where.. It's just not worth living - I am far too old to think that braille can sub for vision. Not with my hobbies/skills 16:14:42 ok, um: an Optometrist is glasses-only; the opthemologist is the eyes themselves 16:15:01 I understand the difference, it's why I presented them in that order 16:15:22 hopefully there's something with my eyes that can be sorted, since I have slightly blurred vision with floaters 16:15:33 but if not, glasses will at least help 16:15:36 I can fake a lot, but it's getting worse.. And afaiac, ordering lenses of late is a fail: they NEVER seem "better" 16:16:34 ..in fact, the "new" glasses are on the passenger seat in the car - I am operating on lenses over a decade old - because the fuckers are CLEAR and WORK. 16:16:58 CLEAN and WORM? 16:17:15 ..the "new" glasses were wonky on day zero - not matching my eyes; andthe "scratch-protective-coating" is peeling/bad all over 16:20:17 I think I'm gonna spend the rest of tofay and tomorrow reading. My eyes can't take this at the moment. 16:20:25 Have fun forthin', forthers 16:54:09 --- quit: Kumool (Ping timeout: 240 seconds) 17:15:42 --- join: Kumool (~Khwerz@adsl-64-237-239-252.prtc.net) joined #forth 17:27:30 --- quit: dddddd (Remote host closed the connection) 17:29:00 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 17:40:13 I'm wondering how much of POSIX I should encode in the standard set of services 17:40:38 none 17:41:08 right now there are four services - TYPE, KEY, ACCEPT, and BYE 17:41:59 * PoppaVic sighs 17:42:09 you like sighing 17:42:42 No, I really like stabbing. 17:43:00 oh kay 17:43:03 I merely sigh overly often. 17:45:56 if we're not going to encode POSIX in the services, how are we going to access files on POSIX systems? and I don't recommend encoding standard C file calls in the services, as that's way too high level = and yes, you can say that many systems won't have POSIX, but they don't have to implement those services 17:46:34 Forth has nothing to do with POSIX. Never has. 17:47:33 so we basically say no file access for you? or do we provide a file layer, but make it overly high-level just so we can say that we're not providing a thin layer upon POSIX? 17:48:07 --- quit: Kumool (Ping timeout: 258 seconds) 17:48:46 or do we do the opposite, and provide a lower level system call interface 17:49:03 so that the user can directly call the Linux kernel without libc acting as an intermediary? 17:49:09 --- join: Kumool (~Khwerz@adsl-64-237-239-252.prtc.net) joined #forth 17:49:23 but how do we make that portable? (we can't) 17:51:23 tabemann: you continue to inflate and conflate. I find it really depressing 17:52:09 and you continue to make vacuous comments without any real explanation 17:53:02 it's great when you just sigh without explaining why you're saying other than implying that somehow you don't like something but you can't bother to say why 17:53:50 --- join: proteusguy2 (~yaaic@cm-58-10-209-198.revip7.asianet.co.th) joined #forth 17:54:01 like your comment above - inflate and conflate what? 17:54:45 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 17:55:30 I thought services were a way to have standardized operations that not all implementations have to implement - microcontroller forths will inevitably implement different services from POSIX forths, and yet the basic set of opcodes can remain the same 17:56:28 --- quit: rdrop-exit (Quit: Lost terminal) 17:56:29 --- quit: GreenGrasshopper (Ping timeout: 240 seconds) 17:56:48 --- join: GreenGrasshopper (~GreenGras@h081217214054.dyn.cm.kabsi.at) joined #forth 17:57:08 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 17:57:19 (I suspect most microcontroller forths won't have most of the services, as IO addresses will be directly exposed to be read and written by the Forth code, so no need for most services) 17:57:32 Good morning Forthwrights :) 17:57:38 hey rdrop-exit 17:57:48 Hi tabemann 17:59:55 I'm kinda arguing with PoppaVic - I was asking about how to implement file IO using services, and he just has to sign and say I "inflate and conflate" 18:01:10 he's against the idea of exposing POSIX using services 18:02:20 IO services can look like POSIX, but don't necessarily have to be POSIX 18:03:07 I don't think we should fully expose POSIX - POSIX concurrency constructs I'm against 18:04:45 On my POSIX umbilical host I have exit, read, write as services 18:05:45 You could add open and close 18:06:11 I'd also be for adding poll() 18:06:30 I've never used poll() 18:06:47 how do you multiplex events? 18:07:06 how do you multiplex? 18:07:07 I've used poll() and select() a lot; it basically allows building an event-based architecture around fd access and timing 18:07:29 wassa' "event"? 18:07:44 you know what an event is 18:08:11 I only use two file descriptors, both open in non-blocking mode 18:08:36 so you busy-wait? 18:08:58 poll() is good for waiting on file descriptors that are non-blocking without busy-waiting 18:10:31 like let's say you have a cooperative multitasker - each task checks file descriptors for input - but if both tasks are checking them for input, you could stop the multitasking and poll() against those file descriptors, allowing saving processor time (and battery life) while either task can be woken up when it gets input 18:12:01 My only POSIX Forth is the IDE for my umbilical, it only has two tasks, a user terminal, and a serial tether, I don't really care about battery life, I'm only running it as a development host. 18:12:17 key? is almost a poll 18:12:40 key? is not poll() 18:12:46 key? sounds like a flag, to me 18:12:46 key? is a nonblocking read 18:13:32 hmm yep 18:14:04 a key? loop is inefficient, because it'll use up a full core and kill your battery life 18:14:17 I don't do POSIX for targets 18:15:12 well yes, unless your target is a rpi or a beagleboard or like, it's likely not going to be running a POSIX OS, or any kernel for that matter 18:15:23 I do have to get going now, though, bbl 18:15:56 --- quit: PSnacks (Ping timeout: 268 seconds) 18:20:09 --- quit: tabemann (Ping timeout: 240 seconds) 18:27:13 --- quit: proteusguy (Ping timeout: 258 seconds) 18:30:57 --- join: proteusguy (~yaaic@2001:44c8:4406:21de:1:1:f5e4:a770) joined #forth 18:30:57 --- mode: ChanServ set +v proteusguy 18:31:37 --- quit: proteusguy2 (Ping timeout: 246 seconds) 18:42:24 --- join: PSnacks (~PSnacks@p200300CB2709B6FC6095E2F40BB6D367.dip0.t-ipconnect.de) joined #forth 18:44:23 --- join: proteus-dude (~proteus-b@cm-114-109-129-168.revip13.asianet.co.th) joined #forth 18:48:18 --- quit: proteusguy (Read error: Connection reset by peer) 18:48:26 --- join: proteusguy (~yaaic@cm-114-109-129-168.revip13.asianet.co.th) joined #forth 18:48:26 --- mode: ChanServ set +v proteusguy 18:51:36 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:ed08:95af:b87f:6b5c) joined #forth 18:51:38 --- join: probonono (~User@ppp103-111.static.internode.on.net) joined #forth 18:51:38 --- quit: probonono (Changing host) 18:51:38 --- join: probonono (~User@unaffiliated/probonono) joined #forth 19:01:19 why is there no division operator for double precision in gforth? 19:02:26 Croran: because yer not supposed to operate with them, they are a result? 19:06:25 hmm ok, well i'm calling the 'utime' function to get the current time in milliseconds past epoch as a double. I want to divide it by a million to get seconds... 19:06:36 what is the preferred method? 19:07:51 Croran: there is FM/MOD SM/REM UM/MOD 19:08:20 um.. 19:09:52 What's the cell-size of your gForth? 19:10:26 if you are screwing with utime, then why not not man 3 time? 19:11:37 milliseconds to seconds is divide by 1000, not a million 19:11:47 Croran, in a double, your first bit is the sign bit and the next eleven are the exponent. The rest are decimal fractions. You could ignore the second half of your double in memory and should be able to perform your operation after adjusting down to a single precision float (1 sign bit, 8 exponent, the rest fraction). 19:12:12 dave0: sorry i meant microseconds past epoch 19:12:43 i see fm/mod looks appropriate. thank you 19:13:51 isn't time_t 64 bits? Wouldn't be a double unless your Gforth is using 32-bit cells 19:14:23 utime cr .s 19:14:23 <2> 1547522117045815 0 ok 19:15:07 Is the top cell ever non-zero? 19:15:16 someday 19:15:31 I assume it could be someday? 19:15:31 i have gforth on NetBSD/amd64 and it is 64 bit cell 19:15:32 waste of space 19:15:52 Croran: if you have M*/ that's probably the best for you 19:16:58 since time_t is only ever representing a large natural number the exponent should always be zero actually. 19:16:59 dave0: oh... so i would use '1' for the n2 argument? 19:17:07 Croran: utime 1 1000000 M*/ d. 19:17:11 Croran: yah 19:17:30 thanks 19:17:38 --- join: tabemann_ (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 19:17:51 --- quit: tabemann (Ping timeout: 250 seconds) 19:17:53 I doubt time_t is 128 bits 19:18:19 i didn't even know there was a utime word 19:18:37 time_t is an integer 19:19:15 "Unix and POSIX-compliant systems implement the time_t type as a signed 19:19:17 integer (typically 32 or 64 bits wide) which represents the number of seconds since the start of the Unix epoch" 19:20:50 rdrop-exit, so a negative number is pre-epoch? 19:21:21 I assume 19:21:23 I think my gforth has 32-bit cells, even though I'm on a 64-bit OS 19:23:12 utime() has a precision of 1 second, utimes() has a precision of microseconds 19:25:26 gforth's utime seems to call unix gettimeofday() 19:25:45 That's from the Linux man page, didn't check any of the BSDs 19:25:56 `utime` in gforth doesn't say which epoch it uses 19:26:29 epoch is usually 1/1/1970 19:27:28 confirmed, my utime divided by a million matches the current unix timestamp 19:28:45 apparently 32-bit overflow for the normal unix timestamp happens on jan 19 2038 19:30:14 The gforth manual says "Report the current time in microseconds since some epoch.", so it *could* use a different epoch as a base. 19:30:41 Should be easy to find out 19:30:53 Croran, by that time multi-core cpus will be so much faster than memory access that bus contention will have dropped us back to 8-bit CPUs and 128-bit buses. :-) 19:31:09 haha 19:31:30 gotta ride to work... tata forthers 19:31:33 sounds like an interesting world 19:31:50 --- quit: proteus-dude (Remote host closed the connection) 19:32:27 Work? is that still a thing? Have fun Proteus-dude 19:35:55 --- join: proteusguy2 (~yaaic@2001:44c8:4144:fe7f:1:2:1a18:1a69) joined #forth 19:37:25 --- quit: proteusguy (Ping timeout: 268 seconds) 19:43:15 back 20:03:14 --- quit: rdrop-exit (Quit: Lost terminal) 20:31:23 --- quit: dave0 (Quit: dave's not here) 20:44:40 --- join: gravicappa (~gravicapp@h109-187-2-216.dyn.bashtel.ru) joined #forth 20:58:58 --- quit: GreenGrasshopper (Ping timeout: 246 seconds) 21:09:20 --- quit: pierpal (Quit: Poof) 21:09:38 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 21:29:25 --- quit: proteusguy2 (Read error: Connection reset by peer) 21:29:47 --- join: proteusguy (~yaaic@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 21:29:47 --- mode: ChanServ set +v proteusguy 21:31:54 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 21:34:07 --- join: dys (~dys@tmo-113-5.customers.d1-online.com) joined #forth 21:40:04 --- join: proteus-dude (~proteus-b@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 21:50:47 --- quit: proteusguy (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org) 21:51:19 --- quit: proteus-dude (Quit: Leaving) 21:51:43 --- join: proteusguy (~proteus-b@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 21:51:43 --- mode: ChanServ set +v proteusguy 22:32:00 How do I do multitasking on the Z80? 22:37:16 --- quit: Kumool (Quit: EXIT) 22:48:02 generally setup a task structure that contains a stack and a place to hold registers and then you round robin bringing those in and out of activity inside your scheduler. 22:50:32 Could I use interrupts to do multitasking? 22:50:47 I'm having trouble really groking what they are and how to use them 22:50:58 generally, unless you have multiple processors, it's not a real common practice - especially on 8bit environments. better to implement some notion of functional reactive style event handling. 22:51:58 you CAN use interrupts to do this but will significantly more overhead in an 8-bit environment. you basically move your scheduler from the inner interpreter into an interupt handling routine and move the tasks in and out of action. 22:52:27 Hm, then what would interrupts be useful for? 22:53:05 if you need pre-emptive multi tasking in an environment where certain code has priority over other code then interrupts allow hardware to guarantee real-time like results. 22:53:56 I see. 22:54:08 probably not something you'd ever need/want in your calculator. 22:54:22 The TI operating system makes use of interrupts 22:54:38 sure - that's generally how keystrokes are dealt with efficiently. 22:54:38 That's why ASM programs can be stopped by pressing ON, or how the calculator can be turned on in the first place 22:54:43 Or when the USB is plugged in 22:54:55 So it doesn't slow down the program at all? 22:55:12 using interrupts 22:55:26 it does if the frequency of interrupts (therefore the cost of task switching overhead) gets relatively high. 22:56:53 in terms of computer time, the time between keystrokes is generally quite long. that leaves 99+% of the time for the main computer task to do it's job. once the duty cycle of interrupts starts getting more frequent, just the cost of switching tasks can quickly be the majority of the work on your computer rather than actually doing the job of computing. 22:57:42 So you'd recommend that multitasking is implemented with a round-robin style? 22:58:03 Where each procress can hand control over by manipulating the return stack or something 22:58:35 I'd recommend you don't implement multi-tasking at all if it can be handled without it. :-) do you have a specific piece of functionality you're trying to accomplish? 22:58:51 Because say I'd like to execute FOO and BAR "in parallel", what if I don't want to manually manage switching control? 22:58:57 Just a curiosity 22:59:29 For instance, the test suite could be run "in the background" or something like that 22:59:30 then sure - round-robin cooperative multi-tasking is probably the simplest with the least practical overhead. 22:59:46 but then i'd have to specify when to give up control, right? 23:00:09 just add a YIELD somewhere 23:00:13 just remember that you're going to effectively reduce the available computer resources for each task by half (if two tasks) for example. 23:01:01 you can explicitly yield in your code or you can implement your inner loop to switch over after 'n number of cycles. Perhaps in your exit function. 23:01:18 Hm that would add overhead 23:01:25 Well any system will 23:01:26 "cycles" being the number of times exit gets called for example. 23:01:40 absolutely! 23:01:49 And perhaps the tasks could have their own stacks 23:01:54 especially in 8-bit environments - a task switch is crazy expensive. 23:02:01 they MUST have their own stacks. 23:02:05 Just so when a task crashes I don't bring the system with me 23:02:24 they must have their own 2 stacks plus space to store ALL the registers of the CPU that you might care about. 23:03:06 and generally they are allocated separate places in memory. the only thing they share is the base dictionary - which then may diverge on a task by task basis. 23:04:10 so any two-task system (if you want to limit it to 2) reduces the available resources of any task environment by half. 23:04:25 ...and you're already running in a pretty confined space. 23:04:28 --- quit: pierpal (Read error: Connection reset by peer) 23:08:08 remember - multi-tasking on any single cpu environment is strictly an illusion with overhead. the overall runtime of running two tasks sequentially will always be lower than that of two tasks in parallel so long as neither task is bound by some external i/o block which leaves the processor at idle much of the time. 23:09:18 multi-tasking can often be faked in a single threaded environment through the use of co-routines and far less overhead. 23:10:20 but that requires your code to be implemented in a co-routine style (which I think is pretty nice actually) - whereas a general multi-tasking solution lets the code just be ignorant of all that and code as if it was the only task in the system. 23:12:33 --- quit: dys (Ping timeout: 268 seconds) 23:21:51 I see 23:22:05 So explicit multitasking is better 23:23:13 well better at what? all depends on the nature of your problem honestly. 23:23:26 it's forth-like, hence popular. 23:58:42 proteusguy: Well, general multi-tasking still has tons of sync mechanisms. 23:59:41 TheCephalopod, sure depending on your implementation. But if you're willing to alter EXIT you can eliminate all that. 23:59:59 --- log: ended forth/19.01.14