00:00:00 --- log: started forth/19.01.15 00:01:08 --- nick: TheCephalopod -> john_cephalopoda 00:36:15 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 01:01:03 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 01:11:48 proteusguy: Ah so it looks like I can write an interrupt that executes every 1/140 of a second 01:12:25 --- join: grosged (~grosged@bop62-1-88-178-198-84.fbx.proxad.net) joined #forth 01:12:26 So it could be continually reading for the "shutdown" key, perhaps 01:12:38 hello there 01:12:39 I'll continue reading about interrupts 01:12:42 Hi 01:12:50 hi siraben 01:13:30 I've seen a few mistakes in your last forth.asm (ti84-forth) 01:13:46 Ah, which one? 01:13:50 but not sure how to modify one line 01:13:52 I didn't test it 01:13:56 I can modify it 01:13:58 Which line 01:14:09 line 461 01:14:11 .dw comma, getc, dup, lit, 34, neql, zbranch 8, c_comma, branch, 65518, drop 01:14:22 just after zbranch 01:14:30 Ah the comma 01:14:31 Thanks 01:14:47 zbranch, 8 ? 01:14:52 I should set up continuous integration for that 01:14:57 Yeah 01:15:02 ok thx 01:15:13 I make a PR ;) 01:15:29 siraben, yep that's what pre-emptive multi-tasking means. 01:16:03 And in that interrupt I suppose I could have it switch back and forth between tasks 01:16:14 So if it's just one task, I should be fine 01:16:15 exactly 01:16:33 And use a word to disable interrupts 01:16:51 well remember each interrupt results in the overhead of pushing/poping all the registers into a safe location. 01:17:39 x86 actually has a special command for that. I doubt that (e)Z80 has, though. 01:17:40 This guide finally made things clock https://www.ticalc.org/pub/text/z80/intguide.txt 01:17:41 Click 01:18:02 Right, I can do that with EXX and ex af, af' 01:18:27 So those two instructions swap the shadow registers in 01:19:20 john_cephalopoda, x86 has a "special" command PUSHA/POPA - but it takes the exact same amount of time as pushing them individually. So frustrating. haha 01:19:52 So then does disabling interrupts make my code faster? 01:20:58 proteusguy: Heh. What a great command. :þ 01:22:06 exx is 4 cycles, ex af, af' is another 4 01:22:09 That's 8 01:35:42 I've been reading forth.asm ... trying to understand...difficult when someone else 's program 01:36:08 I think I'd better learn forth 01:36:22 seriously 01:36:23 :) 01:37:59 grosged, generally the best way people learn forth is to write their own. ;-) 01:39:57 yes, it's a possibility 01:41:48 for now, although I know Z80 assembly, I don't master enough TI-calculators (system calls, hardware) 01:42:07 That's my problem number 1 01:43:15 And concerning computers, I've read that x86 assembly would not be the same either on Windows or Linux 01:43:38 (a question of sys call again ?) 01:46:32 I'm afraid so 01:51:48 I found a site which explains Forth using schemas 01:51:50 http://forth-retro.pagesperso-orange.fr/machine.htm 01:52:01 interesting ! 01:52:16 --- quit: PSnacks (Ping timeout: 268 seconds) 01:52:31 --- join: PSnacks (~PSnacks@p5B2466EA.dip0.t-ipconnect.de) joined #forth 01:54:57 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 02:02:44 grosged: read this https://www.bradrodriguez.com/papers/moving1.htm 02:03:08 And continue with part 2,3,4 etc 02:03:15 ok thx ! 02:04:10 --- quit: ashirase (Ping timeout: 245 seconds) 02:04:27 My implementation is inspired by https://github.com/nornagon/jonesforth/blob/master/jonesforth.S 02:05:06 grosged: Moving Forth is helpful for implementing Forth, but not so much for learning Forth. 02:05:36 I know 02:06:16 by the way, did you know that lots of books about Forth are freely available on archive.org ? 02:06:25 (mainly old books) 02:06:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:13:31 The rodriguez papers are absolutely ideal for 8-bit systems. The 6809 is brilliant. 02:16:59 6809 seems to be better 02:18:21 cpu are not equal when programming a Forth implementation 02:19:09 I guess that microcontroller versions are rather "tricky" 02:24:00 6809 is the best CPU for implementing forth short of a forth cpu. It has built in support for a 2nd stack and it's architecture is quite clean. Not a lot of weird special exceptions like Z80 02:25:52 nowadays, the only way to use a 6809 based computer is a homebrew one, isn't it ? 02:26:18 (I mean : new machine) 02:27:49 Hmm, I'd like to have a very minimal Forth core plus a set of well-defined, optional APIs. 02:52:45 proteusguy: ah, cool. 02:54:43 6809 fpga cores and simulators are all over the place. not hard to get hold of and use. 02:56:09 Australian VHDL programmer John Kent synthesized the 6809 processor and it is freely available to hobbyists and others to use in FPGA designs.[citation needed] On some[which?] platforms the core has been clocked as high as 40 megahertz. 02:56:15 (read on wikipedia) 02:59:32 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 02:59:49 re 03:13:44 --- quit: PSnacks (Quit: Quit) 03:18:34 I have a raspberry pi lying around, could be a valuable Forth target 03:38:47 --- quit: grosged (Quit: Leaving) 03:39:44 --- quit: dave0 (Quit: dave's not here) 04:13:17 ARM assembly is monstrously annoying... 04:13:58 --- quit: proteusguy (Quit: Leaving) 04:46:23 why? 04:49:02 --- quit: pierpal (Quit: Poof) 04:49:19 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 04:54:48 You have to type it with your THUMBs! 04:55:46 doesn't look too bad to me 04:57:37 yea, it's quite nice 05:33:16 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 05:35:13 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 05:39:53 --- quit: jedb (Ping timeout: 246 seconds) 05:42:19 --- join: jedb (~jedb@199.66.90.113) joined #forth 05:57:25 --- quit: pierpal (Read error: Connection reset by peer) 06:12:05 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 06:22:09 --- quit: pierpal (Ping timeout: 240 seconds) 06:31:15 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 06:35:13 --- join: Kumool (~Khwerz@adsl-64-237-239-252.prtc.net) joined #forth 06:35:25 --- quit: pierpal (Ping timeout: 246 seconds) 06:43:54 --- join: proteusguy (~proteus-b@cm-58-10-154-221.revip7.asianet.co.th) joined #forth 06:43:54 --- mode: ChanServ set +v proteusguy 07:19:39 been thinking about a case word - considering this form: CASE [ CONDITION OPEN CLOSE ]* [ DEFAULT OPEN CLOSE ] ENDCASE - the diference being that the comparator is specifed in the case rather than being assumed to be equality (hence it works with non-literals such as strings or even objects) 07:26:11 and i've also been thinking about the 'language' aspects of my project - i know i could reimplement in python (with, i think, identical usage in the core system - only, you wouldn't have c++ object on the stack - you'd have python objects) - it's been years, but i don't see any reason why java wouldn't work (since it has Object at the base which is more or less equivalent to any) 07:27:18 (no interest in doing either - just a theoeretical thing :)) 07:30:49 --- quit: tabemann_ (Ping timeout: 268 seconds) 07:43:26 why open? 07:44:19 to separate the condition tokens from the tokens executed if the condition is true 07:45:00 the default case doesn't need them, but i think it makes it more consistent 07:45:14 so it's just another way of linking several if elif? 07:45:21 yup 07:45:47 do you have elif? 07:45:59 no 07:46:03 ok 07:46:10 i guess that would be the first step 07:47:11 hmm - i think that would be more or less identical? 07:48:06 maybe 07:48:15 how do you implement branches? 07:48:18 fwiw, i'm not using those words - in my stuff, it comes out like: |{ +> 0 == { $ "yay" } +> 0 < { $ "too low" } +> 0 > { $ "too high" } } 07:48:33 that looks pretty unreadable 07:48:40 :D 07:48:55 it's easier over multiple lines 07:49:10 just wanted to avoid the spam :) - will post a link later 07:49:58 --- quit: Kumool (Ping timeout: 246 seconds) 07:51:39 branching - well, that aspect is difficult to discuss in isolation - the parser itself creates a tree like structure i guess 07:52:03 --- join: Kumool (~Khwerz@adsl-64-237-239-252.prtc.net) joined #forth 07:52:08 ah ok 07:52:28 so you're not following the classic single pass conditional/branch system? 07:52:41 well, it is single pass 07:53:03 but no, not quite the same i guess 07:53:04 classic is just one stack 07:53:27 where you drop the address of dest and origs 07:53:42 ah - k 07:54:24 and later pop them off and either ! the correct dest or POSTPONE BRANCH , to get to orig 07:54:54 https://github.com/corecode/forth/blob/master/x86.fs#L275 07:56:50 in my case, words in the dictionary have a few types - functions which have the form void f( stack & ), parsers which have the form f( stack &, std::string ) [they become active and all following tokens are passed to there until they say done] and lists of words, literals and parser objects (evaluated and ready for execution) 07:58:00 functions are primitives and lists of words are what is called a thread usually? 07:59:59 i guess - a function of the f( stack & ) form is normally just registered in the dictionary as a very straighforward function pointer ie: ("+" -> add where add is void add( stack &s )) 08:00:12 yes 08:03:13 --- join: jedb_ (~jedb@199.66.90.113) joined #forth 08:03:44 the main issue is deferring mapping of words to functions until execution - ie: if someone changes the definition of a word, the list execution should use the new word - but if it's doing it in a loop, it shouldn't do the mapping of 'word' to function on every iteration - first occurence does the switch 08:04:08 why? 08:04:13 that's not hyperstatic 08:04:44 --- quit: jedb (Ping timeout: 268 seconds) 08:05:20 you've lost me at hyperstatic :) - it's definitely trying to be as dynamic as possible 08:05:25 aha 08:05:39 i think that's not the typical forth then 08:05:56 sounds tclish 08:06:00 which makes it horrible 08:06:08 :D 08:07:50 well, it's like i have a word which produces a mathematical table - default, the implementation of the item is just i j * - but if i want to change the table to use i j in a different way, i can just rewrite the function - ie: i j hypot 08:08:15 next time i run n table, it gives me that calc rather than the original 08:10:07 so why not pass in the XT 08:10:38 ['] * TABLECALC 08:10:41 and after the first iteration of the first item, it 'optimises' the list of strings (i j hypot) to function pointer or lists 08:10:45 or, use an indirection 08:11:14 VARIABLE TABLEFUNC ['] * TABLEFUNC ! 08:11:53 so how do you clear this optimization? 08:11:53 sure - there are other alternatives - but so far, i haven't even added variables :) 08:12:38 it belongs to the 'parser' which evluates the outer loop - as soon as it completes, it's gone (unless it itself is part of an outer loop) 08:12:58 oh, so you're not doing anything close to a forth 08:13:07 you're building a dynamic stack language 08:13:24 nope - just borrowing the stack approach and some of the word defintions 08:13:29 ok 08:15:06 makes it FORTH-like, but it's definitely not FORTH - a basic subset of stuff will port over, but it's very small subset 08:15:31 ok 08:20:42 and fwiw, it would be trivial to make it 'hyper-static' - basically just do the mappings for word to definition at the point of parsing rather than execution - hmm - will think about that aspect i guess 08:20:52 yes 08:39:30 some things you say ends up sounding far too complicated 08:40:09 like the lists 08:40:10 weird 08:40:29 yea for a forth definitely 08:51:04 --- quit: nighty- (Remote host closed the connection) 09:07:10 possibly true :) - and i definitely agree about the list stuff being weird, but... complex... no :) - what i hope to end up with lists basically being vector objects on the stack which can be iterated over to extract the contents or addressed by index for query/update 09:09:58 the basic idea is just [ args ] and i think that's fairly straightforward 09:26:20 --- quit: X-Scale (Ping timeout: 244 seconds) 09:49:39 --- join: dys (~dys@tmo-081-92.customers.d1-online.com) joined #forth 10:01:39 --- join: GreenGrasshopper (~GreenGras@h081217214054.dyn.cm.kabsi.at) joined #forth 10:44:40 --- quit: gravicappa (Ping timeout: 272 seconds) 10:56:33 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 10:58:25 hi 11:06:18 well, freel free to point and laugh (or entirely ignore) :) - this is a quick knock up of the rpany cases stuff (pluarlised since case is a reserved word in c++) - https://gitlab.com/lilo_booter/rpany#cases and the first draft of the parser/executor as state machine - https://gitlab.com/lilo_booter/rpany/blob/master/include/rpany/vocab/cases.hpp (i was forced to change the word to something which md wouldn't 11:06:20 screw up) 11:07:16 first draft - probably needs fixing/clarifying of course 12:37:49 --- join: presiden (fwiw@unaffiliated/matematikaadit) joined #forth 12:54:41 --- join: X-Scale (~ARM@83.223.243.74) joined #forth 13:12:58 --- nick: jedb_ -> jedb 13:25:00 --- quit: xek (Ping timeout: 245 seconds) 15:02:20 What are the official forth standards? Forth 79, Forth 83, Forth 94, and Forth 2012? 15:06:46 --- quit: dys (Ping timeout: 246 seconds) 15:19:07 2012 isn't really official 15:19:18 DPANS is the only official official standard 15:22:45 what does "official" mean here? 15:33:00 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 15:45:11 so 79 and 83 were not ANSI standards? 15:53:02 Ok I see. So 94 ans forth is the only ansi standard. 16:00:36 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 16:05:16 Good morning Forthwrights :) 16:09:46 Croran: also Open Firmware (IEEE 1275) 16:28:49 --- quit: GreenGrasshopper (Quit: Leaving) 16:34:11 --- quit: pierpal (Ping timeout: 268 seconds) 16:37:47 thanks 16:58:09 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 16:59:25 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:00:45 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 17:29:21 --- join: tabemann_ (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 17:37:48 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 18:42:20 --- quit: proteusguy (Remote host closed the connection) 18:49:56 --- quit: dddddd (Remote host closed the connection) 18:59:48 --- join: smokeink (~smokeink@42-200-118-69.static.imsbiz.com) joined #forth 19:08:14 --- quit: tabemann_ (Ping timeout: 250 seconds) 19:10:46 --- join: tabemann_ (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 20:01:01 --- join: proteusguy (~proteus-b@110.164.217.65) joined #forth 20:01:02 --- mode: ChanServ set +v proteusguy 20:03:11 Croran, the only standard that matters is that there isn't any standard worth using so build your own or use something that happens to get you what you need. 20:08:36 --- quit: tabemann_ (Ping timeout: 258 seconds) 20:09:43 I agree with Proteusguy 20:14:44 --- quit: proteusguy (Ping timeout: 258 seconds) 20:34:10 --- quit: newcup (Ping timeout: 252 seconds) 20:39:41 --- join: proteusguy (~proteus-b@182.232.102.57) joined #forth 20:39:42 --- mode: ChanServ set +v proteusguy 20:56:42 --- join: gravicappa (~gravicapp@h109-187-2-216.dyn.bashtel.ru) joined #forth 21:31:18 --- quit: pierpal (Quit: Poof) 21:31:36 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 21:31:53 --- quit: smokeink (Remote host closed the connection) 21:32:09 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 21:34:54 --- join: dys (~dys@tmo-096-119.customers.d1-online.com) joined #forth 21:35:42 Standardization only matters if multiple people are collaborating across different implementations 21:35:53 In most cases it doesn't really matter 22:03:39 --- quit: pierpal (Quit: Poof) 22:03:58 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 22:14:33 --- quit: Croran (Ping timeout: 260 seconds) 22:18:48 --- quit: proteusguy (Remote host closed the connection) 22:36:10 Yeah if there's a problem with forth its that it doesn't really scale for collaboration. Generally one or two person projects. 22:36:49 --- quit: proteus-guy (Remote host closed the connection) 22:42:13 Hmm.. You could always decompose the problem and generate solutions to those problems 22:44:24 79 83 94 which one require a smallest core words set? 22:44:33 Yes 22:48:00 --- quit: pierpal (Quit: Poof) 22:48:19 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 22:56:42 --- join: proteusguy (~proteus-b@mx-ll-180.183.125-167.dynamic.3bb.co.th) joined #forth 22:56:42 --- mode: ChanServ set +v proteusguy 22:57:10 --- quit: pierpal (Read error: Connection reset by peer) 22:57:33 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 23:01:52 --- quit: proteusguy (Ping timeout: 258 seconds) 23:08:53 --- quit: Kumool (Quit: EXIT) 23:13:49 --- join: proteusguy (~proteus-b@180.183.125.167) joined #forth 23:13:49 --- mode: ChanServ set +v proteusguy 23:48:14 --- quit: dys (Ping timeout: 268 seconds) 23:59:59 --- log: ended forth/19.01.15