00:00:00 --- log: started forth/19.05.04 01:41:18 --- join: dys (~dys@tmo-116-122.customers.d1-online.com) joined #forth 02:02:49 --- quit: pierpal (Ping timeout: 244 seconds) 02:04:19 --- quit: ashirase (Ping timeout: 250 seconds) 02:06:23 --- join: pierpal (~pierpal@host41-236-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 02:07:31 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:51:39 --- quit: dys (Ping timeout: 255 seconds) 03:01:28 --- join: dys (~dys@tmo-086-110.customers.d1-online.com) joined #forth 03:52:46 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:57:04 --- quit: pierpal (Ping timeout: 245 seconds) 04:26:36 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 04:49:47 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 04:51:28 --- quit: pierpal (Remote host closed the connection) 06:11:46 --- join: X-Scale (~ARM@46.50.7.20) joined #forth 06:31:13 --- quit: Zarutian (Read error: Connection reset by peer) 06:31:19 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 06:31:45 --- nick: Zarutian_2 -> Zarutian 07:56:50 --- quit: gravicappa (Ping timeout: 246 seconds) 08:13:44 --- join: gravicappa (~gravicapp@h109-187-4-38.dyn.bashtel.ru) joined #forth 10:31:31 --- quit: zy]x[yz (Read error: Connection reset by peer) 10:32:15 --- join: zy]x[yz (~corey@unaffiliated/cmtptr) joined #forth 10:38:20 --- join: dave42 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 10:40:49 --- quit: dave9 (Ping timeout: 245 seconds) 11:25:16 scoping is such a pain in the ass 11:25:22 so glad it's not a forth thing 11:26:08 i've been doing all these stupid python tricks to avoid having every function start with `global x y z etc ...` and it's all a ballache 11:27:22 --- quit: Zarutian (Ping timeout: 252 seconds) 11:27:53 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 11:34:25 that's because python got scoping wrong 11:36:15 --- join: silenus2 (~silenus2@95.35.187.135) joined #forth 11:39:55 anyone here use mecrisp on an msp430? i'm a newb trying to figure out how to enter a ud 11:40:03 i tried $10000 .. 11:40:11 that doesn't work 11:45:25 --- quit: ashirase (Ping timeout: 250 seconds) 11:47:25 --- quit: gravicappa (Ping timeout: 258 seconds) 11:51:53 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 11:58:25 --- quit: ashirase (Ping timeout: 248 seconds) 12:08:44 --- quit: tabemann (Ping timeout: 245 seconds) 12:15:19 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 12:21:05 --- quit: ashirase (Ping timeout: 268 seconds) 14:28:07 so i found the answer 14:28:19 char z 0 1 cx! 14:28:32 that stores a 'z' at 0x10000 14:28:38 thanks 14:28:44 yw 14:51:19 Rickta59: keep up the good work. And do idle here andor stick around if you have more questions. 14:58:08 --- join: mark4 (~mark4@cpe-2606-A000-808F-FD00-E9AD-8D1C-B65D-7DAD.dyn6.twc.com) joined #forth 15:06:59 --- quit: dys (Ping timeout: 268 seconds) 15:30:13 --- quit: Zarutian (Read error: Connection reset by peer) 15:30:19 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 15:32:12 --- nick: Zarutian_2 -> Zarutian 16:37:48 --- part: silenus2 left #forth 16:54:08 --- quit: john_cephalopoda (Ping timeout: 258 seconds) 16:55:07 c[_] Good morning Forthers :) 17:07:34 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:46:50 May the forth be with you all 17:47:28 Keep on Forthin' jn__ 17:47:30 You must be the famous Obi jn__ Kenobi. 17:47:37 heh :) 17:48:03 i was a little surprised that noone in here made that joke yet, yesterday/today 17:48:16 given the date 17:48:58 Oh, totally didn't realize. 17:50:48 What about the date? 17:51:05 rdrop-exit: May the 4th. May the Force. 17:51:21 Ah :) 17:51:32 lol 17:52:00 It's already the 5th here 17:52:21 Same here. 17:52:30 And it's 3 am, so... Night :þ 17:52:38 Didn'y occur to me at all yesterday 17:53:25 I'll remember that in coming years 17:53:56 yeah, it's past midnight here, too (in europe), but i reckon the 4th still has a few hours in asia 17:54:16 It's the 5th in Asia 17:54:31 way, how do timezones work 17:54:39 s/way/wait/ 17:54:44 Asia's ahead 17:55:22 ah, then in america :) 17:55:24 It's almost 9am in my time zone 18:30:36 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 19:30:34 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 19:31:27 hi 19:31:45 hi dave0 19:31:58 hey 19:32:12 hi tabemann 19:32:17 hi rdrop-exit, tabemann 19:34:21 I should write a version of hashforth I can target at an embedded platform 19:34:45 and I mean real embedded, not the likes of the raspberry pi 19:35:20 the big problem will be that the current design of hashforth assumes that everything is done in RAM 19:36:12 so I'll need to modify thing so it can effectively compile to flash 19:38:03 tabemann: You could have a compiletoram and compiletoflash switch word like mecrisp-stellaris 19:38:28 pointfree: I was thinking of something like that 19:39:08 the only thing is that I have a word table that I'd have to split between RAM and flash 19:39:46 because hashforth is TTC 19:40:49 I'd have to do something like either have the top bit in a token indicate whether it is in RAM or flash 19:41:10 or keep two copies of the table, one in flash and one in RAM 19:41:31 two copies would definitely be faster, but there might not be much RAM to go around 19:54:19 --- join: gravicappa (~gravicapp@h109-187-4-38.dyn.bashtel.ru) joined #forth 20:05:03 --- quit: tabemann (Ping timeout: 250 seconds) 20:07:20 --- quit: Keshl_ (Quit: Konversation terminated!) 20:14:57 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:33:57 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 20:38:00 tabemann, embedded is certainly the home domain for forth. 20:38:55 but couldn't you just have a word that knows the memory map of the device and then could determine whether or not any object/word is in RAM, ROM, Flash, etc? Don't think you need a bit or flag to indicate that. 20:43:19 hashforth is TTC 20:44:47 so each word as encoded does not indicate where in memory it is stored 20:47:50 proteusguy: FF does that, but: now you need to use an address that is larger than the largest space to "unify" it and still clue it 20:49:11 tabemann, it ultimately has an address for the encoding itself right? 20:49:26 proteusguy: that address is in the table 20:50:18 so the isflash word, for example, would look up the word in the table and make the determination, no? Perhaps I misunderstand your structures. 20:50:41 the thing is that one will want separate tables for both flash words and RAM words 20:51:00 or one table for flash word and a second table in RAM that mirrors the flash table and also contains RAM words 20:52:02 the former is slower because the code will have to check which table to use for each word executed 20:52:21 the latter is faster but takes up more RAM because there has to be a table in RAM that contains all words together 20:55:47 tabemann, ah makes sense. so the word would have to check both tables and be a bit smart but can still make the determination. 20:56:56 or it would have to use a flag, like the highest bit in the token, to indicate which table to check 21:03:46 If you're doing a portable VM, then you use tokens for the VM opcodes, the number and size of the tokens is fixed. 21:05:10 rdrop-exit: the issue is that with embedded platforms it may be undesirable to do an all-RAM VM, whereas a VM for a larger system would most likely be all-RAM, and this introduces different design considerations 21:05:55 I'm aware of that 21:08:43 But it doesn't bear on what I said. 21:09:30 My understanding of your hashforth was that you intended to have a portable instruction set. 21:10:27 the instruction set is not the issue 21:11:53 it's that it might be desirable to split the token space into in-flash tokens and in-RAM tokens 21:12:01 It is in the sense that if you're implementing that instruction set on the target, you're not add another layer of overhead by having another set of tokens above that. 21:12:15 * going to add... 21:14:02 the most compatible approach would be to have one table for tokens in flash in flash, and another table for all tokens in RAM, but on highly memory-contrained systems this might not be feasible or desirable 21:14:26 I don't think you're catching my drift 21:17:04 you're saying I shouldn't use a unified token namespace for both opcodes and non-opcode words because that will complicate implementation across multiple systems 21:17:11 Is your Hashforth project still aimed at creating a portable Forth virtual machine? 21:17:56 If so, that machine needs an instruction set. 21:18:05 it does have one 21:18:50 The instruction set (or whatever subset of it is implemented on a particular target) will be a fixed number of fixed sized tokens. 21:19:14 this issue is more like that both tiny systems like the Blue Pill and big systems like the Raspberry Pi run the ARM instruction set, but have wildly different considerations in practice 21:22:09 rdrop-exit: you're still thinking of tokens as instructions whereas I'm thinking of tokens as words of any sort 21:22:44 If you're alreading dealing with a tokenized set of opcodes as described above 21:22:54 where some of those words are primitives 21:23:12 you're rarely going to implement another level of tokens above that. 21:23:42 it's not another level of tokens above that 21:23:50 It is 21:24:02 it's that primitives and non-primitive words exist in the same namespace 21:24:19 there's not two namespaces 21:24:27 It has nothing to do with namespaces 21:25:42 "another level of tokens" is simply that the token namespace would be bifurcated, one for words implemented in flash and one for words implemented in RAM 21:27:50 You have two instruction pointers, the real machine's and the Virtual Machine, right? 21:28:07 * machine's, right? 21:28:31 yes 21:29:40 that's naturally a result of the VM running TTC code 21:29:44 The real machine's instruction pointer executes real machine opcodes, the virtual machine's instruction pointer executes VM instructions. 21:33:25 i.e. the opcodes of your portable VM instruction set. 21:35:17 You can, but don't need to, add another layer of tokenization, but what's the justification? 21:37:03 You're already getting a major performance hit from having a virtual instruction set, why add another? 21:38:40 There's a difference between implementing a TTC Forth on a target to save space, vs implementing a virtual machine instruction set for portability reasons. 21:40:08 --- quit: dddddd (Remote host closed the connection) 21:44:38 you're missing something 21:44:59 In the latter case you would likely end up with a fixed number of fixed sized virtual opcodes, e.g. bytecodes or some similar tokens, with which you do subroutine threading (optionally with inlining) for your primitives and secondaries. 21:45:02 I'm not implementing a Forth that executes TTC code on top of a VM that executes virtual machine code 21:45:58 rather the virtual machine is implemented like an ITC Forth, except the Forth code that is executed is as tokens rather than addresses 21:48:24 each token is an index into a table containing three things, a code pointer, a data pointer, and a secondary code pointer 21:48:30 the code pointer points at native code 21:48:51 for all non-primitive Forth words it is either docol or dodoes 21:49:33 or docreate 21:50:21 the data pointer for primitives and docol Forth words is null, but for docreate or dodes Forth words it points to the data pointer pushed onto the stack 21:50:26 All this time I had understood that you were implementing a portable instruction set, something like a Forth alternative to the JVM instruction set. 21:50:41 My bad 21:51:05 the primitives are meant to be portable 21:51:22 what I mention above is just implementation details not visible to the user 21:51:57 So the primitives are your instruction set in effect 21:52:05 yes 21:52:16 Back to square one 21:52:50 If that's the case then what I said still applies 21:55:48 --- part: PoppaVic left #forth 21:56:08 you thought I was implementing a forth that executed TTC on top of a VM executing VM instructions, where in fact I was implementing a Forth on top of a VM executing TTC code which are both VM opcodes and Forth words 21:56:32 hence why you kept on thinking that I was doing multiple levels of indirection and whatnot 21:57:56 You still are, the instruction set is the key to the portability. 22:00:13 If I wanted to write something to run on your VM, I would write to the VM instruction set and ignore the rest. 22:01:27 Just like I can ignore the Java when I write to the JVM. 22:01:52 * ignore JAVA 22:02:00 that's like writing JVM code without method calls 22:03:26 ok 22:05:18 In fact if I were writing to you VM, I would probably use an umbilical and keep the headers in the development environment. 22:05:29 * your VM 22:05:57 actually, there is a way to do calls without using the token mechanism with my VM, even though it's convoluted 22:06:04 first push the return address onto the return stack 22:06:13 then push the address one wants to call onto the return stack 22:06:17 then execute EXIT 22:06:32 the thing is that this is far less efficient than just using the built-in token mechanism 22:08:44 As I said earlier the main driver for putting a TTC forth on a target is to save space, if it's portability your after then using the tokens are fixed in number and size and comprise a portable instruction set. 22:09:34 * then you use tokens that are... 22:09:39 Sorry for the typos 22:10:56 I gotta walk the dogs, see you later or tomorrow. Keep on Forthin' 22:11:25 --- quit: rdrop-exit (Quit: Lost terminal) 23:59:59 --- log: ended forth/19.05.04