00:00:00 --- log: started forth/18.10.03 00:11:22 --- join: dys (~dys@tmo-105-189.customers.d1-online.com) joined #forth 00:19:21 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 00:19:51 --- quit: tabemann (*.net *.split) 00:19:53 --- quit: groovy2shoes (*.net *.split) 00:19:54 --- quit: sigjuice (*.net *.split) 00:19:56 --- quit: ecraven (*.net *.split) 00:19:57 --- quit: ovf (*.net *.split) 00:33:08 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:b90b:3bee:a83b:ed44) joined #forth 00:33:08 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 00:33:08 --- join: sigjuice (~sigjuice@2604:a880:1:20::83:6001) joined #forth 00:33:08 --- join: ecraven (ecraven@www.nexoid.at) joined #forth 00:33:08 --- join: ovf (sid19068@gateway/web/irccloud.com/x-vfzbgjicbfsvzjzw) joined #forth 00:44:55 --- quit: KipIngram (Ping timeout: 240 seconds) 00:45:13 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth 00:45:37 --- nick: KipIngram -> Guest67650 00:52:57 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 00:52:57 --- quit: ncv (Changing host) 00:52:57 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 01:13:57 --- quit: pierpal (Read error: Connection reset by peer) 01:14:17 --- quit: tabemann (*.net *.split) 01:14:18 --- quit: groovy2shoes (*.net *.split) 01:14:18 --- quit: sigjuice (*.net *.split) 01:14:20 --- quit: ecraven (*.net *.split) 01:14:20 --- quit: ovf (*.net *.split) 01:27:39 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:b90b:3bee:a83b:ed44) joined #forth 01:27:39 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 01:27:39 --- join: sigjuice (~sigjuice@2604:a880:1:20::83:6001) joined #forth 01:27:39 --- join: ecraven (ecraven@www.nexoid.at) joined #forth 01:27:39 --- join: ovf (sid19068@gateway/web/irccloud.com/x-vfzbgjicbfsvzjzw) joined #forth 01:34:49 --- quit: dys (Ping timeout: 268 seconds) 01:35:35 --- join: dys (~dys@tmo-097-11.customers.d1-online.com) joined #forth 01:51:51 --- quit: tabemann (*.net *.split) 01:51:52 --- quit: groovy2shoes (*.net *.split) 01:51:52 --- quit: sigjuice (*.net *.split) 01:51:54 --- quit: ecraven (*.net *.split) 01:51:54 --- quit: ovf (*.net *.split) 02:03:38 --- quit: ashirase (Ping timeout: 244 seconds) 02:05:30 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:b90b:3bee:a83b:ed44) joined #forth 02:05:31 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 02:05:31 --- join: sigjuice (~sigjuice@2604:a880:1:20::83:6001) joined #forth 02:05:31 --- join: ecraven (ecraven@www.nexoid.at) joined #forth 02:05:31 --- join: ovf (sid19068@gateway/web/irccloud.com/x-vfzbgjicbfsvzjzw) joined #forth 02:07:27 --- join: pierpal (~pierpal@host168-226-dynamic.104-80-r.retail.telecomitalia.it) joined #forth 02:07:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:14:00 --- quit: pierpal (Read error: Connection reset by peer) 02:40:29 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 03:37:46 --- nick: Guest67650 -> KipIngram 03:37:59 --- mode: ChanServ set +v KipIngram 04:05:27 --- quit: jedb (Read error: Connection reset by peer) 04:17:15 --- join: jedb (~jedb@199.66.90.113) joined #forth 04:21:18 --- quit: nighty- (Quit: Disappears in a puff of smoke) 04:22:07 --- quit: jedb (Read error: Connection reset by peer) 04:31:55 --- join: jedb (~jedb@199.66.90.209) joined #forth 04:35:46 --- join: pierpal (~pierpal@host168-226-dynamic.104-80-r.retail.telecomitalia.it) joined #forth 04:41:04 --- quit: jedb (Ping timeout: 272 seconds) 04:51:07 --- join: jedb (~jedb@199.66.90.209) joined #forth 05:44:05 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:48:50 --- quit: pierpal (Ping timeout: 272 seconds) 06:41:09 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 06:41:58 --- quit: rdrop-exit (Quit: rdrop-exit) 06:42:44 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 07:22:10 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 07:26:48 --- quit: rdrop-exit (Quit: rdrop-exit) 07:36:12 --- quit: tabemann (Ping timeout: 252 seconds) 07:37:28 --- join: kumool (~kumool@adsl-64-237-235-198.prtc.net) joined #forth 07:47:22 --- join: backer (~backer@accordion.employees.org) joined #forth 08:01:59 --- quit: dave9 (Quit: dave's not here) 08:33:02 --- quit: kumool (Quit: Leaving) 09:12:00 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 09:14:45 --- quit: MrMobius (Ping timeout: 252 seconds) 09:14:45 --- nick: [1]MrMobius -> MrMobius 10:08:22 --- quit: ncv (Remote host closed the connection) 10:35:54 --- part: backer left #forth 10:59:50 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 12:38:37 --- quit: X-Scale (Ping timeout: 244 seconds) 12:44:51 --- join: kumool (~kumool@adsl-64-237-233-169.prtc.net) joined #forth 12:45:38 --- join: X-Scale (~ARM@166.21.108.93.rev.vodafone.pt) joined #forth 12:58:05 --- quit: kumool (Ping timeout: 268 seconds) 13:56:07 --- join: kumool (~kumool@adsl-64-237-233-169.prtc.net) joined #forth 14:18:31 --- join: mark4 (~mark4@cpe-2606-A000-8096-FE00-5A94-6BFF-FEA6-29D4.dyn6.twc.com) joined #forth 14:31:32 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 14:35:07 --- quit: dys (Ping timeout: 272 seconds) 15:07:42 --- join: [X-Scale] (~ARM@43.212.137.78.rev.vodafone.pt) joined #forth 15:08:12 --- quit: X-Scale (Ping timeout: 268 seconds) 15:08:23 --- nick: [X-Scale] -> X-Scale 15:40:28 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 15:42:22 hi 16:21:34 --- quit: wa5qjh (Remote host closed the connection) 16:23:45 --- join: wa5qjh (~quassel@175.158.226.120) joined #forth 16:23:46 --- quit: wa5qjh (Changing host) 16:23:46 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 16:34:50 --- quit: wa5qjh (Read error: No route to host) 16:40:42 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 16:42:07 --- join: siraben (~user@unaffiliated/siraben) joined #forth 16:43:13 --- quit: wa5qjh (Read error: Connection reset by peer) 16:46:53 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:49:57 --- join: wa5qjh (~quassel@175.158.226.120) joined #forth 16:49:57 --- quit: wa5qjh (Changing host) 16:49:57 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 17:01:57 --- quit: Zarutian (Ping timeout: 252 seconds) 17:03:53 --- quit: dave9 (Quit: dave's not here) 17:14:38 --- quit: groovy2shoes (Excess Flood) 17:15:00 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 17:33:03 --- join: yeahnukima (50b26e9b@gateway/web/freenode/ip.80.178.110.155) joined #forth 17:33:21 hello hello hello 17:33:39 what's up people ? 17:33:51 I NEED HELP 17:34:00 I'm using Forth to produce sounds on my calculator 17:34:26 what calculator are you using? 17:34:44 TI-84 17:34:54 TI-84+, technically 17:35:04 It has an I/O port 17:36:04 do you got an interpreter running on it? 17:36:26 I wrote an interpreter for it, yeah. 17:36:26 do you actually write the code on the TI-84 and then press ENTER? 17:36:34 http://github.com/siraben/ti84-forth 17:36:36 Yes. 17:36:45 This program: https://github.com/siraben/ti84-forth/blob/master/programs/music.fs 17:37:25 very cool 17:37:39 "NUM" is just a word that parses the next one as a number, "SMIT" is "sonic emit", basically there's an assembly instruction that sends data over a port 17:39:17 where are you taking it next? 17:39:58 Well, I don't have a block editor yet, so that should be implemented. 17:40:05 ;P 17:40:15 Currently every time I flash the program it resets the "image" which means I lose any words defined on the calculator 17:40:32 It would be good to have some sort of way to separate the blocks and main interpreter. 17:40:37 where did you learn your forth from? 17:42:01 Reading Starting FORTH and reading jonesforth 17:42:27 yeahnukima: You said earlier that you need help? 17:43:00 ya 17:43:02 i do 17:43:12 stumbled upon some interesting history 17:43:20 which doesn't seem to get me anyway 17:43:26 so came here to ask for some help 17:43:44 Alright. What is it? 17:44:15 at the bottom of this page 17:44:16 http://xanadu.com/zigzag/ZZdnld/zzRefDef/ 17:44:19 there is a table 17:44:29 i need more info about the first row 17:45:18 Ah, Xanadu, the greatest vaporware project. 17:45:27 Huh, I don't know any more about the first row than what I can see on the page. 17:48:06 --- join: tabemann (~tabemann@186-82-181-166.mobile.uscc.net) joined #forth 17:48:39 for the record : " Mark Miller & Terry Stanley ca. 1984 Forth Memory-management module designed as part of larger zzvim that was never built. " 17:48:59 will appreciate more info 17:49:53 yeahnukima: What have you used Forth for? 17:50:18 how much hours did you put in the ti84-forth? 17:50:55 it took me a long while, to kinda get into forth 17:51:10 I haven't been logging, but at least 10 hours in the past two weeks. 17:51:13 Mostly on weekends 17:52:19 mostly used forth to burn away hours of my life 17:52:44 What did you use to learn Forth? 17:52:53 I'm burning away hours working on my Forth implementation 17:53:19 i got introduced to ibniz, which i liked 17:53:22 I find that Forth is one of those little languages that you can implement with great value. 17:53:32 Especially if you're on a new target. 17:53:42 and then the spiral began.... so much forth systems.... 17:53:57 I would have defined more of my implementation within Forth itself. 17:54:10 So that only a couple of instructions needed to be figured out before the entire thing is ported. 17:54:54 i do very appreciate the eForth document and Threaded Interpretive Languages book 17:55:25 siraben: My approach to that was to define a *bunch* of macros. My primitives (roughly 200 of them) are now implemented using about 40 macros. 17:55:35 Sort of a "meta assembly." 17:55:49 So I'll just need to port the macros. 17:56:06 So I lowered the porting effort without giving away any of the efficiency. 17:57:41 I used some macros as well, such as `defcode' and `defworf' 17:57:44 Most of the macros are just one line long, but a few have more than one line - I already knew enough about Arm code to know that a few things will just take one line of code there but require more than one on x86. 17:57:46 defword* 17:58:18 Ah, it might be easier on other targets. Z80 is painful in some areas. 17:58:36 Namely, the lack of working registers. 17:58:49 Yeah, I think it would be hard to do what I did in a truly "universal" way such that you got optimum machine code on all targets. 17:58:56 But it extends your reach *some*. 17:59:27 I had about 3200 lines of machine code, but only about 500 lines of macros. 17:59:29 How do you get more memory from the OS in your implementation? 17:59:45 Oh, I cheat. 17:59:57 I reserved 1 GB in the .bss section. 18:00:04 And treat it as a heap. 18:00:10 .bss being like a static buffer? 18:00:22 .bss stuff doesn't have to be initialized and doesn't increase the size of your binary. 18:00:33 Yeah - I get that memory on program load. 18:00:41 Ah. I don't have that. 18:00:58 Linux has system calls to allocate memory, though. 18:01:04 I'm beginning to run short on memory, scratch space larger than 500 bytes is giving an invalid program error on my TI 18:01:05 --- quit: wa5qjh (Read error: Connection reset by peer) 18:01:12 I think there's a cap on program size. 18:01:22 KipIngram, and here I thought people said Forth was memory efficient :P 18:01:31 :-) 18:01:34 Well, it is. 18:01:34 But... 1 GB? 18:01:40 Because it's there. 18:01:47 I didn't want to have to even think about it. 18:01:58 bb... cheers. 10x for the talk. 18:02:02 --- quit: yeahnukima (Quit: Page closed) 18:02:04 Or maybe my assembler is acting up. 18:02:12 I'm intending this as an OS, and it will have "all of the RAM" when it's truly running that way. 18:02:26 I'm not very happy with the assembler I'm using, eventually I'll write my own. The macro system just isn't cutting it. 18:02:46 Plus it's just incorrect in some places 18:02:49 siraben, can the TI-83 run from flash or does it copy your program to ram first? 18:03:00 It has to copy to RAM. 18:03:09 I'll figure out the ROM calls to save/load from archived memory (flash) 18:03:14 There's 200KB right there. 18:03:43 MrMobius: Actually I have 20 KB free RAM, but for some reason my programs can't exceed around 8 KB in size 18:03:45 you mean copy parts out of flash into ram as you need them while the program is running? 18:03:55 Right. 18:04:00 yikes 18:04:00 For instance, to save/load images. 18:04:01 Oh, like overlays. 18:04:04 ya 18:04:07 overlays? 18:04:15 That's what we used to call that. 18:04:29 can you load two files and have the first load into ram then jump into the second stored in flash? 18:04:59 Nope. You can't run programs from flash. 18:05:01 Wait, maybe. 18:05:13 Because "applications", a calculator thing, are stored in flash. 18:05:16 thats weird. how does the OS accomplish it? 18:05:24 not disbelieving you just curious 18:05:29 I just need to sign my ASM file and flash it as an application 18:05:38 sounds like it's treating the flash like a disk drive. 18:05:47 So, yeah, the TI-84 is a little weird. 18:05:53 Most of the time data is stored in RAM. 18:05:55 I remember when that nonsense came out for the TI-89. I was very unimpressed 18:06:13 Like if you made TI-BASIC programs, they were all stored in RAM. Taking the battery out would clear RAM. 18:06:20 * KipIngram has no knowledge at all about TI calculators. 18:06:21 But you can archive things manually or through a ROM call 18:06:27 Haha 18:06:29 * KipIngram was an HP guy. 18:06:35 It's very TI specific 18:06:35 siraben, dont they have a watch battery to keep the ram while you change the AAAs? 18:06:48 Oh yeah, but I think mine ran out -_- 18:06:58 KipIngram, nice. I have an HP-48G at work. Used to have an HP-48GX in college 18:07:00 lol 18:07:47 I'm older - I had a 41CV in college, and later a 42S. 18:07:57 My wife has a 48GX she used in college. 18:08:12 she sounds like a keeper 18:08:15 * KipIngram sort of robbed the cradle. 18:08:24 Absolutely. 18:08:38 I want to build a rack of modems and throw them in a hunt group. 18:08:53 We are forced to use TI calculators. 18:08:59 KipIngram, did you look at the DM-41 and 42 recreations of those calculators? 18:09:16 Well, there are others that are allowed on standardized tests, but I don't want to re-learn my calculator for the sake of it. 18:09:21 I submit to the TI monopoly! 18:09:33 No, but I have superb implementations of both of them on my Android phone. 18:09:44 Visually stunning - they look like the real thing. 18:09:55 I use a TI-89 Titanium 18:09:59 The 42S one, at least, is a re-write, not an emulator-based thing that uses a rom image. 18:10:06 But it seems thoroughly correct just the same. 18:10:11 It's called Free42. 18:10:13 ya I think several if not all are rwrites 18:10:19 *rewrites 18:10:29 the DM-42 runs Free42 if im not mistaken 18:11:14 Back then I did a lot of programming on those. 18:11:30 But these days anything that needs a program seems easier to do some other way than on a calculator. 18:11:46 hehe thats true 18:12:01 I saw this 48G for $20 on craiglist and couldnt resist 18:12:11 for anything beyond trivial I just type it into excel or use python 18:12:21 * FatalNIX keeps reading 48G as 486 18:12:55 Yeah, spreadsheets really do make things quick. 18:13:49 There's a good book - "Algorithms for RPN Calculators," by Ball. 18:14:28 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:17:24 I would like to learn 41/42 style programming 18:17:48 I have worked on a few hobby calculator projects and I want to make one with decent keystroke programming 18:18:29 https://www.barnesandnoble.com/w/algorithms-for-rpn-calculators-john-a-ball/1001071886?ean=9780471030706 18:18:58 I actually preferred the 41's programming to the 42's. 18:19:07 They're not THAT different, but, different enough. 18:19:31 Maybe it's just because I was so good at the 41, and the 42... changed some things. 18:21:07 thats interesting 18:21:10 what was different? 18:22:30 The way labels were managed, to some extent. 18:22:45 It's been a long time. 18:22:51 LONG long time. :-) 18:23:16 Algorithms for RPN calculators? So using stack operations? 18:23:17 siraben i think jonesforth took 99% of its code from what used to be called isforth. i renamed it to x4 tho 18:23:31 because i have t4 and n4 is in the works (android ndk) 18:23:42 Huh. My implementation was inspired by jonesforth quite a bit 18:23:44 The 42 had a nice display - I really liked being able to see the top 2 numbers on the stack instead of just 1. 18:24:31 The 41 had MUCH better key technology. 18:24:49 not a fan of jonesforth myself 18:24:49 I could hold it in my left palm and touch type on it using several fingers of my right hand. 18:24:51 KipIngram, ya the display looks cool 18:25:03 one modified free42 to show all 4 registers on the screen 18:25:04 github.com/mark4th 18:25:32 wow. keys seem to be the main thing everyone hones in on on every HP model 18:25:49 I need to find a real 41 and try the keys out to see what the deal is 18:26:00 are they lighter than hp48gx keys? 18:26:10 Yes, and more "tactile." 18:26:49 the click 18:28:13 I think HP was just a very well-run company back then. 18:28:21 They hadn't yet reached "full corporate mode." 18:29:10 Another company that had a similar "hayday" was Palm. 18:29:22 I think that whole technology peaked with the Palm Vx. 18:29:28 That was a fantastic little gadget. 18:29:50 Then it was all downhill - they went with plastic screens, which wore out and stopped working well within months. 18:30:17 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 18:30:24 And their Graffiti was a superb text entry method. 18:30:29 back 18:30:31 Then someone sued them and they had to change it. 18:30:55 HP owned palm? i thought it was 3m? 18:31:06 did 3m inherit palm from HP ? 18:31:08 you mean 3COM 18:31:11 No, I didn't mean that. 18:31:13 was it 3com? 18:31:31 I was just noting that Palm also had a product line that 'peaked' and then declined. 18:31:35 3com sounds right. 18:31:57 I've tried tons of "organizer" apps for smart phones. 18:32:03 None of them hold a candle to the Palm Vx. 18:32:08 * tabemann finally fixed a major bug in his Forth implementation 18:32:17 Oh, what was it? 18:32:28 Bug stories are fun. 18:33:08 I was using the FREE function in a place where I should have been using my FREE! function - everywhere else in my code I'm using FREE!, but because I needed a primitive I was using FREE - and forgot how it was different from FREE! 18:33:13 FREE returns an error code 18:33:29 heh isforth once had a bug that if a comment was there the code worked but if i removed the comment it didnt :P 18:33:32 FREE! checks the error code and drops it, aborting if it's non-zero 18:33:42 :-) 18:33:45 mark4: Why don't you like jonesforth? 18:33:50 What was the root cause of that one, mark4? 18:34:05 siraben: because i think 99% of his kernel was taken driectly out of isforth 18:34:15 KipIngram: miss handling of EOL lol 18:34:30 i forget the details 18:34:36 Do you have a link to isforth? 18:34:47 its called x4 now and its on github 18:34:56 github.com/mark4th 18:35:07 I'm annoyed with Forth 2012 specifying that files are parsed line by line - because then you can't have code which looks across line boundaries 18:35:09 both x4 and t4 are there. t4 is the thub2 port 18:35:40 tabemann: isforth from day one memory mapped the ENTIRE file and treeated the map as TIB :) 18:36:00 I was thinking of doing that 18:36:03 t4 runs on the pi2 and up 18:36:12 Is it really that similar? 18:36:34 siraben: a lot of the kernel primitives are 18:36:39 One thing I should get better at is writing/reading code that is split across multiple files. 18:36:43 Maybe it's a coincidence? 18:36:48 I'd expect my code would work on ARM64 running Linux without modification 18:36:58 maybe but still x4 has a LOT MORE built in 18:37:00 How many ways can you implement 4+ 1+ AND OR NOT etc. 18:37:05 including a memory manager 18:37:17 including a terminfo parser and text user interface 18:37:21 curses like 18:37:32 and... nobody knows what x4 is and everyone talks about jonesforth 18:37:43 what assembly language is this: https://github.com/mark4th/x4/blob/master/src/kernel/logic.s 18:37:48 * tabemann is cheating by just using glibc's memory manager 18:37:58 Heresy! 18:38:01 x86_32 18:38:18 nasm 18:38:22 lots of macros 18:38:23 I'm still wondering where all the Forths for TI calculators are 18:38:24 Ah I see. 18:38:44 Here's a question: Should I make NEXT a macro or subroutine call? 18:38:48 need to look in macros.s :) 18:38:53 call NEXT vs in-lining instructions 18:38:55 a macro 18:38:59 what threading did you use 18:39:02 Direct 18:39:05 next can be inline or jump next 18:39:14 Oh, a jump then. 18:39:23 It would reduce my program size by a bit 18:39:28 x4 is direct threaded and i give the end user the option of picking inline next or jump next 18:39:32 * tabemann implemented NEXT via a #define 18:39:33 ^ metaphorical bit, not literally a bit 18:39:43 inline next is faster. jump is smaller but not enough to boterh 18:39:45 bother 18:39:46 Same here, it's a define. 18:39:58 how small do you need to be though 18:39:58 I still don't know how to do timing tests 18:40:19 if you're running on x86_32 you probably don't need the meager space savings through a JUMP NEXT 18:40:20 Well, size shouldn't matter in the end when I can load/restore from flash memory 18:40:25 Oh I'm on a Z80 18:40:36 that was in response to mark4 18:40:42 Right. 18:41:01 the size saving isnt even noticable lol 18:41:15 but neither is the speed difference 18:41:25 i just know one is smaller the other is faster 18:41:26 A JP instruction takes 10 cycles on my chip, looking at docs 18:41:47 My Forth isn't even aware of files - I'm doing it the old BLOCK way. 18:41:55 you might want a JP though, considering how little space you have, though, siraben 18:41:58 in x4 SI is the interprative pointer so next is a "lodsd" followed by a "jmp eax" 18:42:19 i would do jump next on any resource constrained system 18:42:35 also, jump next allows for a debuger to intercept next 18:42:47 ^ Yes. 18:42:56 Or you can replace next with a "next that profiles," or whatever. 18:43:05 right 18:43:31 KipIngram: whereas I'm using the filesystem because I'm assuming a OS, and it's silly to limit oneself to blocks when one has a filesystem aside from out of sheer traditionalism 18:43:37 brb, food! 18:43:40 I have no debugger, unfortunately. 18:43:49 All my testing is ad-hoc and interactive. 18:43:51 I have a macro for calling words 18:43:52 isforth used to have a fully working debugger 18:43:56 its not working any more lol 18:44:08 and I have a bit of a hack where I have a bit of commented out code in that macro 18:44:15 jonesforth is well documented, that's for sure. 18:44:19 I like well done literate programs. 18:44:33 which when uncommented dumps a log of every word called and how deep the return stack is to stderr 18:44:47 Ah, the luxury of working in an OS 18:45:25 so you literally get to see everything going on - at times I've added code so it also dumps the parameter stack too, but it makes the tty too cluttered so I normally don't use that 18:45:47 it is *so* convenient 18:45:57 it slows down execution a lot though 18:46:02 Where can I get a Z80 dissembler? 18:46:17 donno, but I'm sure they exist 18:46:17 dis-assembler* 18:46:33 Or maybe I should just write one in Forth 18:46:53 pretty sure i saw one in the debian packages 18:48:26 When I write an assembler, I'll probably target this "meta assembly" I did with the macros. 18:48:27 http://www.z80.info/z80sdt.htm 18:48:31 That will be strongly portable. 18:48:34 Those of you familiar with functional programming may be interested in http://www.complang.tuwien.ac.at/anton/euroforth2006/papers/lynas.pdf 18:48:43 "Adding Lambda Expressions to Forth" 18:48:46 Google does that with golang - the compiler generates a "meta assembly." 18:49:03 I've been experimenting with using the exception system as a way to implement backtracking 18:49:04 And they have a utility that can scrape processor data sheets to determine the translation from that to the actual machine code. 18:49:15 Ah I see. That's interesting. 18:49:19 A generalized disassembler. 18:49:30 How do you distinguish between data sections though? 18:49:54 Well, I was talking about an assembler. 18:49:59 Not a disassembler. 18:50:01 Oops, yeah. 18:50:17 Has anyone here read the paper "META II: A Syntax-Oriented Compiler Writing Language" ? 18:50:39 The only way I'd know to do a disassembler would be to say "Start here - stop when you come to NEXT or an invalid opcode." 18:51:07 My mind is melting. This is like meta-forth 18:51:09 http://www.ibm-1401.info/Meta-II-schorre.pdf 18:51:10 You could experiment with starting in different places and choosing the one that gave the "most sensible" result. 18:51:22 Right. 18:51:40 KipIngram: Are you familiar with that paper? 18:51:41 --- quit: wa5qjh (Quit: No Ping reply in 180 seconds.) 18:52:08 ALGOL 60, hm. 18:52:30 No, I don't think so. 18:52:44 you can't stop when you encounter a next 18:52:58 what if there's a branch over it 18:53:03 Yes, true. 18:53:09 Hm? Branching over a NEXT? 18:53:12 I've tried to avoid that. 18:53:13 I don't have any of that. 18:53:16 Multiple exit points. 18:53:18 All my assembly primitives end with NEXT 18:53:26 well, i guess you could keep up with the possuble branches but that sounds tricky 18:53:34 Yeah, I agree. 18:53:42 Oh, some of them have "jp tru" and "jp fal" which jump to the subroutines that return true or false on the stack. 18:53:55 So just have some well-defined exit points. 18:53:57 I'm interested in being able to automatically "unroll" simple words into machine code. 18:54:04 So that would also need to know where words ended. 18:54:14 --- join: wa5qjh (~quassel@175.158.225.193) joined #forth 18:54:15 --- quit: wa5qjh (Changing host) 18:54:15 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:55:03 Is there an ultimate Forth assembler that can have assembly data sheets be fed into it, with what each opcode does and so on, and output a Forth system? 18:55:18 Generating systems instead of writing them, so to speak. 18:55:35 I dont think that would be an easy thing to make efficiently 18:55:43 probably best way is to just have some way of looking up a length somewhere, or always terminate words with some magic number that is invalid machine code 18:56:05 Program synthesis is one area of research happening right now, so who knows. 18:56:48 zy]x[yz: Yes, I'd considered the former. 18:56:53 A byte count in the header. 18:57:11 there was a really good x86 assembler for tom zimmers FPC for dos 18:57:15 but it was a 16 bit assembler 18:57:20 Or perhaps I should start with a smaller example: Given input ( a b c d -- d b c a ), generate a Forth word which performs that operation. 18:57:22 I think I may also want some machine-consumable stack effects indicator. 18:58:04 siraben wouldnt it be easier to define a minimal set of primitives and recode the primitives for every new architecture? 18:58:20 MrMobius: Yeah. 18:58:31 it seems like making a custom file with a description of the architecture might be a similar amount of work 19:00:59 I definitely think this macro approach is sensible. 19:01:14 It gets 99.9% of the efficiency of machine code, but with a lot less per-processor porting required. 19:01:31 You actually have the primitives represented in a portable format then. 19:02:42 And the approach includes aliasing register names - it's much nicer to look at that code and see TOS, IP, SP, RP, etc. 19:14:06 * tabemann is happy that abort no longer makes his code segfault 19:16:27 * KipIngram would like to figure out how to intercept and handle exceptions. 19:17:26 Use stack frames! 19:17:39 I'm implementing CATCH and THROW, it's just juggling frames 19:17:50 Forth makes it entirely easy to brick yourself. Fetch from an "address" that's not really a valid address yet, etc. 19:17:57 Oh, for sure. 19:18:06 KipIngram: Surely you've heard of TempleOS 19:18:18 --- quit: catern (Excess Flood) 19:18:54 It was created by a schizophrenic programmer who recently passed away, but it was a full-fledged OS. Reminds me of the Forth way of things. 19:20:01 Well it's still available on its website. He wrote his own filesystem, language (HolyC), compiler and so on. There are some interesting ideas there. 19:20:19 siraben: No, I hadn't, but I looked it up. 19:20:26 Um, "interesting" history. :-) 19:20:35 --- join: catern (~catern@catern.com) joined #forth 19:21:09 Just a trigger warning about some of his videos on YouTube, he swears quite a bit 19:21:13 yeah, I've been chasing segfaults recently, and almost all my segfaults are originating in Forth code and not in C code 19:21:26 When C is a safer language :) 19:21:51 Does it make sense to write a Forth in C? It's more portable for sure, what else? 19:21:51 well my C code is far, far simpler than my Forth 19:21:57 Well, most other language require you to read RAM via a named variable. 19:22:11 You're just not given the "flexibility" Forth gives you. 19:22:47 I would still recommend beginners to start with a language that has error handling, some type checking etc., before Forth perhaps. 19:22:54 siraben: portability is the main reason - I'd like to run my code someday on a Raspberry Pi without having to recode it 19:23:16 Ah, I have a Raspberry Pi in my drawer, I should write a Forth for it. 19:23:29 But it's more of a computer than an embedded device. 19:23:47 tabemann: Like pforth? 19:23:49 the raspberry pi is a "big" embedded device 19:24:05 Perhaps too big for Forth? 19:24:21 I have a 16 GB SD hard attached to it. 19:24:29 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 19:24:32 SD card* 19:24:35 I wouldn't say too big for Forth, but big enough that you essentially can do everything you could do on a PC on it 19:24:39 I think Forth could run an RPi just fine. 19:25:06 What's the current Forth operating system? 19:25:14 what do you mean? 19:25:29 An OS that I could flash to a USB stick and run, for instance. 19:25:43 Editor, shell, filesystem, etc? 19:25:57 they've gotta be out there 19:25:59 --- quit: wa5qjh (Quit: No Ping reply in 180 seconds.) 19:26:00 There's one out there called ForthOS that is bare metal on x86 tech. 19:26:13 I haven't been able to run http://www.forthos.org/ 19:26:24 It doesn't boot, perhaps I'm doing something wrong in the flashing process. 19:27:10 the problem with modern PCs is they have too much proprietary driver shit going on 19:27:19 even with Linux you've got the binary blobs 19:27:31 Yes. That's what I don't like about my Mac currently. 19:27:33 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 19:27:39 I need proprietary blobs 19:27:53 I mainly forsee targeting embedded devices with Forth on bare metal 19:27:56 Eventually I'll switch over to a device that runs free software top-down 19:28:42 Webassembly is another interesting target, don't you think? 19:28:56 An assembly language in the browser 19:29:05 webassembly is interesting indeed 19:29:11 t4 runs on the rpi just fine 19:29:20 >I mainly forsee targeting embedded devices with Forth on bare metal 19:29:21 sub threaded 19:29:23 me too 19:29:36 does t4 run on the rpi on bare metal? 19:30:02 It's really hard to catch invalid memory access, maybe I should just stop trying to 19:30:29 I don't try to catch invalid memory access, I just segfault when that happens 19:30:40 Right. It's the programmer's responsibility. 19:30:48 no 19:30:51 under linux 19:31:11 What about in an embedded system? 19:31:45 one hack I implemented is I made a DEBUGGER word - so that when under gdb you set a breakpoint on the af_prim_debugger primitive, that breakpoint will catch when the code reaches DEBUGGER - and then one can do things like manually examine the stack and memory 19:31:47 I'd still like to catch those bad accesses (because hardware can do that) and run my Forth error treatment instead of just dying. 19:32:03 How do you check for bad access? 19:32:14 I could read from any 16-bit address 19:32:43 Ok, so I don't mean "not valid in terms of your program." 19:32:47 I mean "there's nothing there." 19:32:59 The memory management units on modern processors can throw an exception when that happens. 19:33:11 the only way I can see is to have bounds checking in your @ and ! primitives... but that'd be fucking slow 19:33:12 I'd just need to have my own code at the exception handling location. 19:33:20 Processors can throw exceptions? 19:33:24 in my code I could trap SIGSEGV though 19:33:26 Sure. 19:33:41 siraben: KipIngram means modern processors 19:33:47 Oh. 19:33:50 In Linux if you try to write to your code region, the hardware has been told that's a read-only memory range. 19:33:58 It will raise an exception. 19:34:02 Yes - modern processors. 19:34:03 Ah, so it's embedded within the processor itself. 19:34:06 How convenient. 19:34:07 in my Forth, for instance, if I felt like it, I could trap SIGSEGV and act accordingly 19:34:10 Yes. :-) 19:34:26 whereas siraben's problem is that they can address any word in the memory space without a problem 19:34:26 Perhaps I could just rig ! to do a bounds check within the program's data section 19:34:45 And define something like !! to do no checking 19:34:55 that would work 19:34:58 --- join: wa5qjh (~quassel@175.158.225.193) joined #forth 19:34:58 --- quit: wa5qjh (Changing host) 19:34:58 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 19:35:04 but it'd be slow 19:35:09 siraben: Do you have your headers separate from your definitions? 19:35:23 tabemann: Which is good and bad. I have a word called MEMVIEW to visualize RAM and it just reads as the user scrolls 19:35:28 KipIngram: What do you mean? 19:35:28 of course my stack checks in my Forth are slow... but I can always comment them out 19:35:45 Do you check after execution of each word? 19:35:54 KipIngram means that you want to be able to write to the data space 19:35:56 In FIG Forth you had your header, and then the primitive code or Forth definition (or variable space or whatever), IMMEDIATELY followed that. 19:36:06 I have a pointer in the header to those things. 19:36:06 but you don't want to be able to write to your word headers 19:36:21 which you could enforce by having word headers outside the data space 19:36:31 So I can totally re-vector any definition by changing the CFA and /or PFA pointers in the header. 19:36:34 so your bounds check would not allow writes to word headers 19:36:38 Yes, I have headers. [Link to prev (2 bytes)] [Length and flags (1 byte)] [Word name (n bytes)] [NULL (1 byte)] ... 19:36:45 So I could vector in a ! that did bounds checking while I was developing. 19:36:52 Then use the standard ! when I was done. 19:37:05 Ah but IMMED and HIDE write to the flag byte 19:37:22 Well, when you CREATE the header you write to all of it. 19:37:31 That has to be a writeable range. 19:37:40 I see. 19:37:53 In most systems that permissions stuff applies to 4kB blocks. 19:37:57 I probably won't bother with trapping SIGSEGV, because usally when that happens it means memory is fatally corrupted, so there's no point trying to recover anyways 19:37:58 But at the assembly level using SMC is fine, right? 19:38:05 So once you filled up a 4kB block you could mark it read only if you wanted to. 19:38:11 There's a syscall for that. 19:38:35 ^I mean self-modifying code 19:38:59 forth using direct threading *is* self-modifying code in a way 19:38:59 tabemann: My error recovery system images the whole process, and if an error is encountred anywhere in the line it restores it. 19:39:08 So my errors revert me to the state the system had at the start of the line. 19:39:12 That's how DOES> is implemented, it changes the "call docol" to "call dodoes" 19:39:27 KipIngram: Ah that makes sense. 19:39:36 okay, I've gotta go, bbl 19:39:54 My current ad-hoc solution is to save the stack pointer and return address at the start of the program and restore those on exit so it exists cleanly. 19:40:03 exits 19:40:30 My error recovery is pretty much a sledge hammer. 19:40:44 It's only one step short of imaging the WHOLE SYSTEM. 19:40:49 Just does it at the process level instead. 19:40:57 But it works well. 19:41:05 If I run this, with an empty initial stack: 19:41:10 1 2 3 4 5 bad_word 19:41:17 I have an empty stack on recovery. 19:41:19 But if I run 19:41:20 1 2 3 4 5 19:41:23 bad_word 19:41:30 I have 1-5 on my stack after recovery. 19:41:49 If I break a : definition across multiple lines, it doesn't re-image on each one. 19:42:29 Waits for me to finish, and if an error occurs anywhere before we get an end of line swith STATE=0 I revert to the start of the line tha topened the : def. 19:42:52 The error recovery does a lot of work, but it's only done when I'm typing stuff at the keyboard. 19:42:59 I'm the slow boat, so the overhead isn't a problem. 19:43:25 A friend suggested that I also error recovery on block loads, if I had edited the block since the last successful compile. 19:43:28 I like that idea. 19:43:50 --- quit: tabemann (Ping timeout: 244 seconds) 19:44:03 That would mean I could load a hundred blocks of known-good-code without error recovery overhead. 19:44:22 But if the code hasn't been "proven" yet via a successful compile since the last edit, then the error recovery will run. 19:44:40 Geez, I'm tired tonight. Going to go ahead and hit the sack. 19:45:24 On my host forth I have SAVE and RESTORE which I can save and restore the entire host image. 19:54:46 Ah I see. 19:55:34 I do a SIMG and LIMG (save image, load image), which saves and loads all the new definitions 19:55:59 And I use TI's group feature to save a snapshot of the entire program in flash memory 19:56:08 So if I segfault and RAM clear, then I just recover from flash. 19:56:23 * siraben finally got S" and ." to work 20:04:45 --- quit: jedb (Ping timeout: 252 seconds) 20:05:22 I only do this on my host forth not on the target. 20:13:32 My preference is to use an umbilical/tethered Forth on the host computer and use it to produce target machine code and/or 20:13:32 target Forths. 20:16:11 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:b90b:3bee:a83b:ed44) joined #forth 20:17:15 --- join: jedb (~jedb@199.66.90.209) joined #forth 20:17:30 That way I can make a target Forth as fat or thin as I want. 20:18:04 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 20:18:11 hi 20:18:44 e.g. instead of having separated headers on the target, you can just keep the headers on the host. 20:21:30 Umbilical forths give you more flexibility. 20:21:43 thats the only way to do a tethered forth 20:21:57 they do if the interface between host and target is seamless 20:27:32 If interfacing your host Forth to the Target isn’t feasible, you could still fallback on using the host Forth as a plain cross-compiler to generate a target image. 20:27:59 --- quit: dddddd (Remote host closed the connection) 20:29:03 Having a tethered Forth allows you to take advantage of however much interactivity the target can bare. 20:31:51 From putting a placing a few bytes of machine code on the target to building a full-fledged Forth environment on the target. 20:32:01 i never actually wrote a tethered forth lol 20:32:25 wrote an avr assembler for x4 20:32:35 planning on doing one for avr 20:32:42 but im not even sure i still have that assembler anywhere 20:36:11 I find that tethered Forth give you the best of both worlds, you can make your Host development as sophisticated as you like without burdening your targets. 20:37:16 yup 20:37:58 Your host Forth can be on a protable token-threaded VM on an OS, while your target Forth could be bare-metal SRT with inlining for example. 20:38:22 Simplifies life in both directions. 20:38:53 i never implement compiler optimizations 20:39:14 t4 is srt but totally non optimizing. 20:39:29 so if i have dup = push of r0 the opcode for push r0 is not compiled inline 20:40:21 I only implement some very simple optimizations that can be turned off. 20:40:30 ya 20:40:58 i had toyed with the idea of doing a peephole just for academic 20:42:17 Optimization is usually overkill for a host Forth since you’re only using it as a development environment. 20:46:10 i mean optimizing for the target 20:48:33 Right, since you’re using SRT it would be easy to add inlining as a first step, then you could always layer on a simple peephole optimizer if it’s worth the trouble. 20:51:55 The rulebase for the optimizer can get very large, best to store it on the host. 20:56:47 I use explicit inlining, by ending a inlining definitions with « ;inline » instead of « ; ». 20:57:21 Sorry for the typos, still on my first coffee of the day 21:05:15 --- quit: siraben (Ping timeout: 268 seconds) 21:06:38 heh typos are common from this keyboard too 21:06:57 i have not done this, it was on the possible list 21:07:14 right now im working on fixing my android ndk forth after google broke it lol 21:07:29 had to do major major surgery 21:07:49 im slowly fixing it all. 21:07:54 Ouch, good luck. 21:08:06 i also want to do x64 forth and a A64 forth 21:08:25 aarcg64 has no thumb2 21:09:02 but i really really need to write the x86 32/64 assembler, an arm/thumb2/aarch64 assembler first 21:09:18 a lot on the todo lost 21:09:19 list 21:09:27 I haven’t done any x86 assembly in decades, my eyes glaze over when I read Agner Fog’s manuals. 21:09:43 what are those? 21:09:53 x86 16 and 32 is easy 21:10:04 not even looked at 64 but i know its different 21:10:41 i think arm 64 removes everything that was worthwhile in thumb2 and gives nothing in return 21:10:44 my opinion 21:11:13 He’s an expert on the x86-64 instruction set. I’ll get you the link. 21:11:54 if/when i do my x86 assembler it will do 100% if the encodings in OCTAL. that is the only way x86 makes any sense 21:12:53 https://agner.org/optimize/#manuals 21:12:53 I don’t think I’ll ever need to write x86 assembly again. 21:13:18 y? 21:13:50 I’m currently porting my old Forth from DOS to POSIX, I’m using a byte-coded VM written in C for the host Forth. 21:14:57 lol 21:15:12 --- quit: dave9 (Quit: dave's not here) 21:15:16 not a fan of forths in c but i can see the reason why people do it 21:15:38 its just that my take is that unless (and until) a forth is 100% self hosting it is not a real forth 21:15:45 x4 and t4 are not self hosting 21:15:58 i.e. assembler/metacompiler are a must 21:16:07 and forth does not usually have an extension to compile c :P 21:16:21 --- quit: KipIngram (Ping timeout: 252 seconds) 21:16:37 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth 21:17:02 --- nick: KipIngram -> Guest50250 21:17:45 watching terminator 1 21:17:58 im waiting for the 6502 assembler bit lol 21:23:54 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 21:27:08 --- join: wa5qjh (~quassel@175.158.225.193) joined #forth 21:27:08 --- quit: wa5qjh (Changing host) 21:27:08 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 21:28:43 For the host Forth I wanted a portable VM for POSIX compliant OSs, C is the most strightforward way to get that. It’s basically a virtual two-stack processor that runs on any Unix derivative (or emulator thereof). On top of that I have my Host Forth code and can forget all about C, the host Forth can metacompile itself. All target develpment is in Forth and target-specific assembly. 21:31:01 I haven’t watched Terminator since the original theater run. 21:34:22 Ever since I watched the new Chuck interview video I’ve had a hankering to revisit the Sourceless Forth concept. 21:36:03 Gotta walk the dogs. Cheers. 21:36:14 --- quit: rdrop-exit (Quit: rdrop-exit) 21:43:07 --- quit: wa5qjh (Ping timeout: 246 seconds) 21:44:53 --- join: wa5qjh (~quassel@175.158.225.196) joined #forth 21:44:53 --- quit: wa5qjh (Changing host) 21:44:53 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 22:17:26 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 22:19:13 sourceless forth works how? 22:20:31 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 22:38:33 --- quit: kumool (Quit: Leaving) 22:39:34 --- quit: wa5qjh (Quit: No Ping reply in 180 seconds.) 22:42:04 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 22:42:06 2 22:42:08 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 22:42:53 --- quit: rdrop-exit (Client Quit) 22:43:40 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 22:44:31 I was asked the same question recently on Reddit, so I’ll just copy the answer I gave there: 22:44:36 My understanding of the concept of sourceless programming is development through interactive assembly/disassembly. 22:44:37 Your development environment doesn't store source code per se, it stores object code and some supplemental information (labels and comments). When you wish to view or edit your program, the system disassembles the object code with the help of a processor instruction table and the supplemental information to produce a source "view" of the program. 22:50:03 --- quit: wa5qjh (Remote host closed the connection) 22:52:30 --- join: wa5qjh (~quassel@175.158.225.196) joined #forth 22:52:30 --- quit: wa5qjh (Changing host) 22:52:30 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 23:11:17 --- quit: mark4 (Ping timeout: 260 seconds) 23:13:22 --- join: leaverite (~quassel@175.158.225.196) joined #forth 23:13:22 --- quit: leaverite (Changing host) 23:13:22 --- join: leaverite (~quassel@freebsd/user/wa5qjh) joined #forth 23:13:45 --- quit: wa5qjh (Ping timeout: 252 seconds) 23:23:39 --- quit: leaverite (Ping timeout: 252 seconds) 23:25:15 --- join: wa5qjh (~quassel@175.158.225.201) joined #forth 23:25:15 --- quit: wa5qjh (Changing host) 23:25:15 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 23:29:23 --- quit: wa5qjh (Remote host closed the connection) 23:32:45 --- join: [X-Scale] (~ARM@43.212.137.78.rev.vodafone.pt) joined #forth 23:35:22 --- quit: X-Scale (Ping timeout: 272 seconds) 23:35:22 --- nick: [X-Scale] -> X-Scale 23:59:59 --- log: ended forth/18.10.03