00:00:00 --- log: started forth/18.10.10 00:03:23 --- quit: wa5qjh (Remote host closed the connection) 00:06:56 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth 00:06:56 --- quit: wa5qjh (Changing host) 00:06:56 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 00:08:42 --- quit: ovf (Read error: Connection reset by peer) 00:08:55 --- quit: carc (Ping timeout: 252 seconds) 00:08:55 --- quit: ecraven (Ping timeout: 252 seconds) 00:09:50 --- join: ovf (sid19068@gateway/web/irccloud.com/x-bqdsbdcafvheyibw) joined #forth 00:10:02 --- quit: sigjuice (Ping timeout: 252 seconds) 00:10:51 --- join: ecraven (~ecraven@www.nexoid.at) joined #forth 00:10:54 --- join: carc (~carc@unaffiliated/carc) joined #forth 00:13:02 --- join: sigjuice (~sigjuice@107.170.193.86) joined #forth 00:24:06 hi , i just found badusb project, which found a usb drive could be easilly flash firmware 00:25:05 and after checked their firmware building script, i found its a 8051 chip , so cant us build a 8051 forth into that usb drive and act l like a usb devices :D 00:33:27 --- join: yoplaid (~gf@147.83.107.200) joined #forth 00:33:36 hi there 00:34:35 --- quit: yoplaid (Quit: Changing server) 00:35:51 --- quit: carc (Ping timeout: 252 seconds) 00:39:56 --- join: carc (~carc@unaffiliated/carc) joined #forth 01:01:31 --- join: yoplaid (~gf@147.83.107.200) joined #forth 01:11:06 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 01:11:06 --- quit: ncv (Changing host) 01:11:06 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 01:19:30 --- quit: Keshl (Read error: Connection reset by peer) 01:19:46 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 01:29:28 --- quit: MrMobius (Read error: Connection reset by peer) 01:32:19 --- join: leaverite (~quassel@175.158.225.194) joined #forth 01:32:19 --- quit: leaverite (Changing host) 01:32:19 --- join: leaverite (~quassel@freebsd/user/wa5qjh) joined #forth 01:32:51 --- quit: wa5qjh (Ping timeout: 252 seconds) 02:04:24 --- quit: ashirase (Ping timeout: 252 seconds) 02:09:28 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:23:14 --- quit: jedb (Read error: Connection reset by peer) 02:25:58 --- join: jedb (~jedb@2604:6880:c742:5ad0::f1e) joined #forth 02:31:21 --- quit: dave0 (Ping timeout: 252 seconds) 02:32:39 --- quit: jedb (Ping timeout: 264 seconds) 02:44:59 --- join: jedb (~jedb@116.251.60.75) joined #forth 02:49:06 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 02:50:05 --- quit: jedb (Ping timeout: 268 seconds) 02:50:56 --- quit: leaverite (Remote host closed the connection) 02:55:18 --- quit: nighty-- (Quit: Disappears in a puff of smoke) 02:59:18 --- join: jedb (~jedb@199.66.90.113) joined #forth 03:01:03 --- quit: yoplaid (Quit: leaving) 03:01:40 --- join: yoplaid (~gf@147.83.107.200) joined #forth 03:02:46 --- quit: yoplaid (Client Quit) 03:17:35 --- join: siraben (~user@unaffiliated/siraben) joined #forth 03:27:05 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth 03:27:05 --- quit: wa5qjh (Changing host) 03:27:05 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 03:29:53 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:30:14 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 03:40:05 --- quit: Guest16778 () 03:40:28 --- join: Guest16778 (sid285816@gateway/web/irccloud.com/x-yraezmldtuamuowk) joined #forth 03:40:55 --- nick: Guest16778 -> mstevens 03:41:02 --- quit: mstevens (Client Quit) 03:41:17 --- join: mstevens (sid285816@gateway/web/irccloud.com/x-fdrwinwgvyzlhnde) joined #forth 03:44:56 hi KipIngram :-) 03:45:19 pointfree: That's interesting. Perhaps my next target would be this: https://www.vexrobotics.com/276-2194.html 03:47:23 The proprietary languages that VEX provides are utter trash. I'm using a C compiler called PROS https://pros.cs.purdue.edu/cortex/api/index.html#gyroshutdown 03:47:40 But I could learn ARM ASM and see what I can come up with. 03:48:12 i heard ARM asm is rather nice but never actually used it 03:48:21 ^PROS is awesome because I can write actual C code. 03:48:58 The students at Purdue University behind it are pretty dedicated. There's full support for multitasking and threads, for instance. 03:49:51 Hm, but if I'm using C should I build a Forth on top of that or go straight to assembly? 03:50:24 yunfan: do you know which usb device this was? So I can buy one? 03:50:58 Anyone know what language this is: https://github.com/purduesigbots/pros/blob/master/firmware/cortex.ld ? 03:51:30 siraben: looks like a gnu linker script 03:51:38 siraben: gnu ld 03:52:28 https://github.com/purduesigbots/pros/blob/master/src/motorcontrol.c#L164 could be re-written in Forth, perhaps? 03:52:44 Looks like most things are just pin read/writes. 03:56:44 Yeah, after looking through the kernel more I don't think I'll be writing a Forth in ASM, but rather in C. 03:56:56 How would I do things like stack operations? Maintain a constant array? 04:00:40 there are some C forths on github 04:00:51 I guess you can find one of your "level" 04:11:00 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 05:09:48 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 05:15:46 --- quit: epony (Quit: QUIT) 05:16:27 --- join: epony (~epony@unaffiliated/epony) joined #forth 05:19:34 pforth is a solid c forth 05:31:53 Yes, it is, and generally VERY easy to build. I've used it several times over the years. 05:35:24 Ah. So I might find a way to modify the build process so that I can have a Forth interpreter plus all the standard "words" of the PROS kernel 05:35:51 Interop between the C functions and parameter stcak 05:36:06 --- quit: epony (Quit: QUIT) 05:49:57 --- join: epony (~epony@unaffiliated/epony) joined #forth 06:05:18 --- quit: wa5qjh (Ping timeout: 252 seconds) 06:06:58 --- quit: Guest88437 (Quit: HydraIRC -> http://www.hydrairc.com <- Chicks dig it) 06:08:46 --- join: X-Scale (~ARM@43.212.137.78.rev.vodafone.pt) joined #forth 06:09:19 :-) 06:13:12 What would be an efficient way to do it though? 06:13:40 Should I reuse compiled code? 06:14:21 I can't advise - it's just not something I've ever had an interest in. 06:15:44 Right as well write assembly. 06:15:48 Might* 06:16:07 For the embedded stuff I'm interested in, I like Forth as a way to get away from other code like that. 06:17:50 Right. 06:18:15 My Forth stack isn't the processor stack. How does the code you're trying to call deliver its results? 06:18:27 function returns, pointer parameters, etc.? 06:18:28 Well, it returns from C 06:18:52 I mean where do the functions put results, for use by the caller? 06:18:56 long int ftell ( PROS_FILE * stream ) 06:19:04 Ok, function return. 06:19:06 I think the regular stack, right? 06:19:10 Yes. 06:19:20 So I'd probably just call it and move the result to the Forth stack. 06:19:28 I don't know how this works in C. So it's the same as pushing the parameters and then doing an assembly equivalent of a CALL ? 06:19:35 Guess you'd have to move the parameters to the stack too. 06:19:35 Ah, right. 06:19:45 Or prepare them on the Forth stack and then point SP at that. 06:36:30 --- quit: catern (Excess Flood) 06:38:46 --- join: catern (~catern@catern.com) joined #forth 07:15:18 One of the ideas that didn't appeal to me much at all in that early doc was in section 8, "Programs that Think." 07:15:26 Ooops - wrong channel. 07:16:59 I was referring to that old doc of Chuck's - in section 8 he talks about matching parts of words against the dictionary and things like that. 07:17:04 Feels very non-Forthy to me. 07:17:24 Somewhere in there he also discusses implementing infix, which I'm just so glad Forth DOESN'T do. 07:17:37 I absolutely feel like it was so early that his ideas weren't fully refined yet. 07:25:20 But some of the "different from today" ideas are kind of interesting. 07:25:38 He has a disk-based thing that seems to be the forerunner of vocabularies; I find that quite intriguing. 07:30:09 --- join: kumool (~kumool@adsl-64-237-238-107.prtc.net) joined #forth 07:40:23 --- join: ncv_ (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 07:40:23 --- quit: ncv_ (Changing host) 07:40:23 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 07:40:33 --- quit: ncv (Read error: Connection reset by peer) 07:40:55 --- quit: tabemann (Ping timeout: 250 seconds) 08:16:27 It's pretty forward thinking for his time. 08:16:44 Does anyone here know how to do 32 bit multiplication on an 8-bit chip? 08:16:47 I'm trying to implement D( 08:16:50 D* I mean 08:16:56 has anyone ported a forth to the ESP32 ? 08:17:15 --- quit: dave9 (Quit: dave's not here) 08:17:39 If yes, second question is: has anyone developed a TCP/IP stack on it 08:39:36 --- quit: kumool (Quit: Leaving) 08:50:25 I read something about esp32 lately on news or mailing list... try to google it 08:58:57 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 09:00:11 --- join: dys (~dys@2a01:598:b001:93db:226:5eff:fee9:68d2) joined #forth 10:00:25 --- quit: ncv_ (Remote host closed the connection) 10:12:03 --- quit: jedb (Ping timeout: 244 seconds) 10:14:51 --- join: rixard (~rixard@h-112-233.A444.priv.bahnhof.se) joined #forth 10:24:59 --- join: jedb (~jedb@199.66.90.113) joined #forth 10:31:27 --- quit: rdrop-exit (Quit: rdrop-exit) 10:33:21 siraben: What multiplication does your chip have? 10:33:43 Absolute worst case you can shift and add. 10:34:19 32-bit by 32-bit could give 64-bit, so your output and the adds you do into it would have to carry out to 64-bits. 10:34:26 --- quit: rixard (Quit: rixard) 10:34:36 But if you do that, you just do this: 10:34:42 1) initialize 64-bit output to zero 10:35:01 2) test lsb of input A. If it's set, add B to output. 10:35:17 3) shift b left one bit (in a 64-bit window) 10:35:28 4) shift a right one bit. 10:35:35 Repeat 31 more times. 10:36:18 That's really just the binary version of grade school long multiplication. 10:37:09 And yes, I agree Chuck's stuff was all very advanced for the time. 10:37:21 Wasn't meaning to be critical at all - I think the guy is amazing. 10:38:47 It's no surprise to me that the ideas might have had some rough spots at the beginning - what's really more interesting to me is that there's some stuff in there we seem to have dropped along the way, that looks like it might be useful. 10:42:05 Specifically what I'm talking about is his early vocabulary ideas (at least I think that's what these are). 10:42:21 He had this notion of being able to aim a variable at a disk block (i.e., put the block number in the variable). 10:42:44 If a word isn't found in the dictionary, and fails numeric conversion, before throwing an error he checks a key/value structure in that block for the word. 10:42:55 If it's found, he pushes the value to the stack - if not, error. 10:43:09 Ok, so that's "interesting," but where I think it could be *useful* is in handling database tables. 10:43:17 DB tables are BIG and inherently disk resident. 10:43:43 I'm picturing a small section at the start of the db table range that has key/value pairs, among which will be the *field names* for that table. 10:43:51 They'd return the offset in the row for the table. 10:44:16 Also included would be the small bits of data needed to manage the table records (last used, free list, etc.) 10:44:26 And info on the schema - row size primarily. 10:44:39 Though the field name variables would be schema info too, I guess. 10:44:59 This way everything about the table is in one place - that info doesn't have to be "side stored" anywhere. 10:46:02 So while I think modern vocabularies are probably "better at what they do," I think the disk resident nature of this old idea actually fits well in this particular usage. 10:48:55 The mechanism can also be used to name blocks, which combined with a simple linking of blocks gives you a rudimentary file system. 10:49:33 Historically I've been negative toward file systems in Forth, but I really can't deny that having a logically related body of source code reside in a suitably named entity makes sense. 11:05:35 KipIngram: so, could you implement something like HATFS (an diskette filesystem for DCPU-16) ontop of it? 11:09:06 Hmmm. Google search for hatfs file system didn't pull up anything direct, at least not toward the top of the search. 11:09:17 Got plenty of stuff on "hdfs" and hadoop, but no hatfs. 11:09:23 I'm not familiar with it. 11:17:36 --- quit: jedb (Ping timeout: 268 seconds) 11:25:15 huh, it seem like it has disapeared from the net then 11:25:30 it is rather simple filesystem format basically 11:29:55 --- join: jedb (~jedb@199.66.90.113) joined #forth 11:32:15 it starts with an header (saying it is hatfs, sector/block size, how many blocks there are and such), followed by a bitmap telling which sectors/blocks are in use then followed by a strip link array. 11:33:53 that array links 'strips' together. Say you have block 42 of a strip and need the next one, you use 42 as an index into the array and get say 45 11:35:15 after the strip link array you get the actual data blocks/sectors 11:36:41 So you could do that without any of the naming, right? Just hard code data items at locations in blocks? 11:36:47 each strip starts with a small header telling you if it is a file, a directory (or maybe something else that wasnt in the spec), and how long it is (big endian unsigned two cell number) 11:37:09 All this mechanism really does is give you a way to attach names to specific values, with the "catalog" residing in a disk block or blocks. 11:37:32 I just thought it would be a handy way to put field names with the table they went with. 11:37:39 and iirc the 'root' directory is the first 'strip' following the strip link array 11:38:53 --- quit: nighty- (Excess Flood) 11:39:16 directories are basically an array of 16 cell values where the first cell tells you the strip starting block/sector of the file/directory named. The rest is the name. 11:39:27 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 11:40:47 this is the simplest filesystem format I have seen that supports hierchies. 12:12:29 --- quit: jedb (Ping timeout: 268 seconds) 12:18:40 --- join: jedb (~jedb@199.66.90.113) joined #forth 12:29:41 is there a state-smart or stateless tick in gforth? 12:35:45 see ' makes reference to (') which leads me to believe it's state smart. 12:35:53 Otherwise what's (') for? 12:35:57 That's kind of a guess, though. 12:36:39 Well, but it doesn't say it's immediate. 12:36:52 If I compile : test ; immediate and then see test, it tells me it's immediate. 12:37:18 I think it's not immediate. 12:37:23 : test ' ; 12:37:39 test behaves the same way ' does - and nothing special seems to happen at compile time. 12:43:19 --- quit: jedb (Ping timeout: 245 seconds) 12:56:45 --- join: jedb (~jedb@199.66.90.113) joined #forth 13:04:37 ' shouldn't be immediate 13:04:52 ['] is supposed to be the immediate version 13:05:31 I don't know of any state-smart version; maybe ['] should be 13:06:32 --- quit: Keshl (Quit: Konversation terminated!) 13:16:16 FIG-Forth had a state smart tick, ANS is just being weird 13:16:17 shame 13:18:51 what was it called? 13:28:32 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 13:33:58 Was there a ['] word? 13:34:55 No, just ' 13:34:55 No, not according to here: 13:34:58 http://forthworks.com/forth/papers/compare.pdf 13:35:01 Not in FIG at least. 13:43:57 ' does what again conceptually? 13:45:39 right it 'quotes' the next word 13:46:38 that is looks up the string of the word in the dictionary and leaves the pfa/cfa address 13:47:26 It places the xt of the next word on the stack - from what I can tell ' execute just executes the word. 13:47:58 handy when you are doing CREATEion 13:52:47 Then ['] is just an immediate version. 13:56:58 hmm does ' do the equiv of ' DOLIT , after it has looked up the xt, while ['] only looks up the xt and puts it onto the stack? 13:57:29 I think they both leave the word on the stack. 13:57:35 The xt rather. 13:58:15 so why not make ' immediate? it can be postponed if needed, no? 14:00:10 It could be, yes. 14:00:18 I don't know a good reason. 14:01:13 Oh, hmmm. 14:01:20 No, : test postpone ['] ; 14:01:25 doesn't behave the same as ' 14:01:33 I'm overlooking something. 14:02:00 ['] really isn't just an immediate version of ' 14:02:09 Looks like maybe it does do a literal action. 14:02:19 ' just looks up a word and pushes its xt 14:02:34 ['] does ', and then also compiles it as a literal into the current word 14:02:52 Right - so you were right, Zarutian. 14:02:56 zy]x[yz: so I basically had it wrong way around 14:04:30 : ' defined >xt state unless exit then lit ; immediate ( something like that ) 14:05:29 but then if you want ' behavior in your word, you'd have to postpone ', but that state-aware logic then might lead to some unexpected behavior 14:05:41 so now that I think of it, maybe it's a good thing that ' and ['] are separate 14:06:46 why? 14:07:37 because otherwise it sort of requires the user to know how ' works in order to use it in a word 14:08:12 isn't that the point in any word at all 14:08:22 I mean it requires them to know implementation 14:08:27 you don't know how dup works until you RTFM 14:08:38 I can use dup without knowing how it's implemented 14:09:06 well it's exactly the same as knowing how ' works 14:09:29 the standard having ' and ['] is what causes your problem of identifying implementation details 14:09:34 even then, RTFM 14:44:03 --- quit: proteus-guy (Ping timeout: 264 seconds) 14:56:46 --- join: proteus-guy (~proteusgu@2403:6200:88a6:329f:79ca:228a:ed9:7d2) joined #forth 14:59:23 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 15:02:01 --- quit: MrMobius (Ping timeout: 246 seconds) 15:02:01 --- nick: [1]MrMobius -> MrMobius 15:13:34 is there a cannonical way to let INTERPRET, WORD etc read from a given string? (basically string is given on stack as: addr length) 15:23:11 What do you mean by canonical? 15:23:24 Could you point TIB and >IN at the string? 15:23:40 I mean, that's what LOAD does, right? 15:24:07 Save old TIB and >IN values on the return stack, reload them, and INTERPRET. 15:24:20 You'll get control back when it hits the NULL - restore TIB and >IN. 15:24:44 Since that's what LOAD actually does, I think it's fair game. 15:25:19 It needs to be a null-terminated string, though. 15:25:34 I know that would work in FIG, but I don't know if the standards have evolved in a way to preserve it. 15:43:28 Well, that tries to work in GForth, but as far as I can tell it doesn't use null to end the interpretation of a buffer. 15:44:32 I can't test it in mine, because TIB isn't a variable in my system. 15:44:48 It points into the command history region. 15:44:54 KipIngram: didnt know how to phrase the question but you have answered it. 15:47:40 I know that in eForth 'KEY? is what get @EXECUTEd by KEY? to fetch the next character. I can probably have an version that changes where 'KEY points to and fetch the characters from a string 15:48:11 (and restore that afterwards) 16:07:33 KipIngram: Multiplication on the Z80? Hah. There's no instruction for that. 16:07:46 I'm using a routine to do 16bit by 16bit multiplication 16:07:51 Ok, then you'll have to do it bitwise s I outlined. 16:07:57 Right. 16:10:28 This is weird. I'm trying to get more space for HERE in my implementation. Allocation and "HERE !" work but then defining new words cause a crash. 16:22:16 crc: oy! http://forthworks.com/forth/standards/FIG/glossary.txt is missing FLUSH 16:27:55 TI should have gone with an 8051 16:28:00 it has hardware multiply :P 16:28:31 *kidding* 16:29:01 siraben, how do the address registers work for accessing more than 64k of ROM? is it bank switched? 16:30:02 No, it should just be a simple HERE ! 16:30:22 MrMobius: Oh you're talking about address 16:30:36 There's no bang switching. 16:30:37 bank 16:31:07 I'm suspecting that it has something to do with overwriting sections of RAM with data 16:31:18 siraben, so what assembly instruction would I use to load something from address 0x10000 for example? 16:38:59 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth 16:38:59 --- quit: wa5qjh (Changing host) 16:38:59 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 16:43:08 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:43:36 Zarutian: FLUSH wasn't present in the oldest FIG listings I've looked at 16:44:34 --- quit: siraben (Ping timeout: 245 seconds) 16:54:36 --- join: Guest88437 (~ARM@43.212.137.78.rev.vodafone.pt) joined #forth 16:54:57 crc: yet it is refered to by BLOCK and other related words. 16:55:45 --- quit: X-Scale (Ping timeout: 252 seconds) 17:01:00 Poor documentation from the early days. 17:01:38 siraben: HERE isn't a variable. 17:01:47 DP is the variable. 17:01:49 I should upload some later listings & files sometime 17:01:52 : HERE DP @ ; 17:02:30 Though if you wrote this you may have made HERE the variable name. 17:03:44 Why would BLOCK run FLUSH? 17:04:16 I thought there was a BLOCK-WRITE for BLOCK to use if it had to free a buffer. 17:04:24 That doesn't seem like a good time to write all of them. 17:25:17 --- quit: epony (Quit: QUIT) 17:33:45 --- join: epony (~epony@unaffiliated/epony) joined #forth 17:42:01 --- quit: wa5qjh (Remote host closed the connection) 17:43:57 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth 17:43:58 --- quit: wa5qjh (Changing host) 17:43:58 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 17:56:32 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 17:59:50 crc: oh, okay. 18:07:36 --- quit: unrznbl[m] (Ping timeout: 250 seconds) 18:10:37 --- join: unrznbl[m] (unrznblmat@gateway/shell/matrix.org/x-icwzczokmhwjyjce) joined #forth 18:14:54 --- join: tabemann (~tabemann@136-86-181-166.mobile.uscc.net) joined #forth 18:19:37 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 18:29:51 --- nick: Guest88437 -> X-Scale 18:37:19 WilhelmVonWeiner: yes, that's phison 2303 based usb pendrive, i just bought 3 yesterday ,very cheap 18:37:43 WilhelmVonWeiner: there is kingston DT100G3 which is use this 18:38:10 WilhelmVonWeiner: also you could search for phison 2303 , someone had a infopage about this 18:38:43 WilhelmVonWeiner: https://www.quora.com/Which-USB-drives-contain-Phison-2251-03-2303-controller-type 18:43:57 --- quit: wa5qjh (Remote host closed the connection) 18:46:03 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:52:05 --- quit: NB0X-Matt-CA (Ping timeout: 268 seconds) 19:02:40 next thing to implement - history! 19:03:06 (now that yanking doesn't make attoforth crash anymore) 19:04:39 tabemann: what is attoforth? 19:04:51 it's the forth implementation I'm working on 19:05:10 right now I'm busy essentially re-implementing Readline in Forth 19:06:29 which platform does it target? 19:08:16 Linux, at this point primarily 64-bit (since it doesn't really implement double-cell sizes for IO properly yet) 19:08:35 well, it should work on any Unix-like 64-bit system, including Cygwin 19:08:52 ah, its a c implementation 19:09:00 yes 19:09:15 does c version has threading types? 19:09:21 like itc, dtc? 19:09:25 or ttc? 19:09:30 it's ITC 19:10:48 that may be slow, but it has things that make it slow already, like range checks on the stacks, and a countdown during execution for determining when to switch task 19:11:12 even though some of those things are optional (the range checks can be easily commented out) 19:11:37 In my host Forth I avoided Readline, and used the non-standard LaForth approach instead. 19:12:22 I'm not using Readline but rather rewriting its functionality 19:13:10 I’m doing word at a time input processing instead of line at a time. 19:14:04 No need for Readline style functionality. 19:14:18 But therefore non-ANS. 19:15:08 Simplifies many things. 19:16:53 I like being able to edit my lines before entering them too much 19:17:20 right now I've got basic editing (including on multiple lines of the terminal) combined with kill and yank implemented 19:18:43 I have both plain yanking and rotate-the-kill-ring-and-yank implemented 19:20:16 Fair enough. I prefer to execute words as soon as a space or newline is entered. 19:23:22 The word becomes part of history as soon as the space or newline is entered. 19:27:36 brb 19:38:38 --- quit: epony (Quit: QUIT) 19:39:38 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 19:40:20 hi 19:40:30 hello :) 19:40:39 hi rdrop-exit 19:42:16 but how to implemnt these threaded code in language except asembly? 19:43:16 you dont need readline, you could ask user to execute rlwrap ./yourforth 19:51:29 how do you implement threaded code not in assembly? 19:52:21 simple - have compiled code consist of addresses of words, which contain pointers to primitive functions, and have the inner interpreter dereference those addresses and call those function pointers 19:52:40 I don’t find ITC and DTC that useful anymore, I only use the two ends of the spectrum on my Forths, either SRT/NC or TTC. 19:53:55 TTC on hosts, SRT/NC on targets. 19:54:04 there is forth's written in c 19:54:44 srt=subroutine threading? 19:54:50 yes 19:54:56 what's ttc & nc? 19:55:15 Token Threaded Code, Native Code 19:55:17 ttc is token threading 19:55:24 ah thanks 19:55:50 what's the point of TTC on hosts? to support downloading code to targets? 19:56:28 I always thought of TTC as something for very memory-challenged systems with overly big word sizes (think 32 bit words on a system with 32Kbytes of RAM) 19:56:57 My development environment is an umbilical (AKA tethered Forth). 19:57:27 whereas my Forth is a Forth for "big" systems 19:57:28 My development environment is an umbilical (AKA tethered) Forth. 19:57:50 (where, say, a Raspberry Pi is "big") 19:58:53 I could scale it down, but I probably would need to drastically revise its IO system for it to be embeddable 19:59:30 considering it runs in two OS threads, one for Forth, and one for the IO system, which is centered around a poll-loop 20:00:37 okay, I need to go, the coffee shop is closing - but I will be back on soon enough 20:00:50 The Forth coding for SRT/NC and TTC are very similar, one is dealing with instructions for real processor, the other instructions for a virtual processor. 20:01:04 The Forth coding /style/ 20:05:09 --- quit: tabemann (Ping timeout: 252 seconds) 20:12:25 In an umbilical Forth setup, there are two Forths, the one on the host machine is only used as a cross-development IDE, it talks to and cross-compiles/cross-assembles code on the target. 20:14:00 The target Forth, if any, can use whatever form of threading you find most appropriate for that particular target. 20:15:10 The code you cross-develop to a target can be anything from minimal machine code routines to a full onboard Forth. 20:16:05 --- join: epony (~epony@unaffiliated/epony) joined #forth 20:16:28 For example, you could store the headers on the host, and keep the target headerless. 20:17:24 but isnt forth use goto instead of call to execute native code? 20:17:40 if in c, how you use goto some function written in c? 20:19:53 For SRT you lay down a call instruction, or if the definition is an inline one, you lay down a copy of its code. 20:22:24 Ah, you’re asking about C, sorry 20:25:57 I don’t implement SRT in C, only TTC. I implement SRT in the target’s machine code, not C. 20:26:35 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:b90b:3bee:a83b:ed44) joined #forth 20:40:23 tabemann: ah, you came, will you please answer my question? 20:40:47 but isnt forth use goto instead of call to execute native code? 20:40:52 if in c, how you use goto some function written in c? tabemann 20:41:08 I'm not using goto 20:41:23 so you use c's funtion invoking? 20:41:29 I'm using a loop which calls the function pointed to by the address pointed to by the IP 20:41:44 and each primitive has code at the end to advance the IP 20:41:58 that will use the cpu's hardware stack 20:42:08 no, it does not 20:42:37 because ITC functions start with a primitive that pushes the IP onto the Forth return stack 20:42:53 and end with the address of a primitive to pop the IP off the Forth return stack 20:46:23 If your loop is « calling » the function, than presumably that call is using the hardware stack… maybe I misunderstood. 20:46:48 but it only goes one level deep and is independent of the Forth return stack 20:47:42 it is inefficient I admit, but as this Forth is not aimed at microcontrollers (unless you call the Raspberry Pi a "microcontroller"), a bit of inefficiency is not a problem 20:50:16 --- quit: wa5qjh (Remote host closed the connection) 20:52:37 I tend to use TTC when speed is not the major concern, the last ITC Forth I wrote was for MSDOS. 20:52:59 tabemann: its not only one level deep if you call another function in your native code 20:53:17 or am i missed something ? 20:53:49 there's two basic levels - the inner interpreter, and the primitives called by the inner interpreter 20:57:28 Is your Raspberry Pi 64-bit? 20:57:41 there are both 32-bit and 64-bit Raspberry Pis 20:58:10 I don't own one at the moment, but I intend on acquiring one at some point 20:59:55 I was just thinking that ITC with 64-bit cells might not be a good fit. 21:00:45 I could easily change Attoforth to TTC if memory becomes a concern 21:00:57 --- join: NB0X-Matt-CA (~nonlinear@unaffiliated/discrttm) joined #forth 21:01:07 but mind you, the Raspberry Pi isn't a proper microcontroller, having more in common with a modern smartphone 21:03:33 I can imagine, anything that can run a Unix has to be a beast. 21:05:49 Your target Forth would not be very different from a desktop Forth on such a target I imagine. 21:06:20 yes exactly 21:06:54 I would write my Forth quite differently were I targeting a microcontroller, e.g. having support for compiling to flash 21:07:42 and yes, if I were, say, writing a Forth for an ARM-based microcontroller, I would use TTC, because 32-bit words are just too big when your RAM is measured in kilobytes 21:08:21 --- quit: epony (Quit: QUIT) 21:08:56 the only reason to not even use 16-bit cells in such an environment is that flash and IO addresses might be higher than 64K 21:08:56 --- join: epony (~epony@unaffiliated/epony) joined #forth 21:09:04 Or just use SRT/NC on an ARM. 21:09:08 Gotta go, dog needs his walk. Nice chatting, see you later. 21:09:12 see ya 21:09:21 --- quit: rdrop-exit (Quit: rdrop-exit) 21:16:57 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth 21:16:57 --- quit: wa5qjh (Changing host) 21:16:57 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 21:20:09 --- quit: dave9 (Quit: dave's not here) 22:36:18 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 23:24:17 --- quit: dys (Ping timeout: 252 seconds) 23:59:59 --- log: ended forth/18.10.10