00:00:00 --- log: started forth/05.09.04 00:56:38 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 01:09:56 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 01:49:13 --- join: Raystm2 (n=Raystm2@adsl-68-95-254-73.dsl.rcsntx.swbell.net) joined #forth 02:04:54 --- quit: Topaz (Read error: 110 (Connection timed out)) 02:15:32 and how is erlang? I mean how interesting is it? 04:28:26 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:43:01 hi tathi 04:45:00 Hi virl 05:06:00 --- join: geoffb (n=geoff@adsl-69-110-115-185.dsl.pltn13.pacbell.net) joined #forth 05:34:05 --- quit: tathi ("leaving") 05:49:35 --- join: masak (n=masak@130.238.83.176) joined #forth 06:10:45 --- quit: saon ("Lost terminal") 06:19:10 --- join: PoppaVic (n=pete@0-1pool72-56.nas24.chicago4.il.us.da.qwest.net) joined #forth 06:19:28 Howdy-doody 06:21:56 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 06:25:55 --- quit: crc (Read error: 110 (Connection timed out)) 06:32:24 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth 06:34:24 --- quit: saon ("Lost terminal") 06:55:32 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 06:56:24 --- quit: saon (Client Quit) 06:57:19 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 07:09:07 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 07:16:58 --- quit: Amanita_Virosa ("Gaming!") 07:38:22 hmm, I think I've streamlined as best-possible for now. 07:39:03 cool 07:39:33 http://rafb.net/paste/results/rkNpkf34.html 07:39:47 Near as I can tell, this optimizes flexibility and space issues. 07:40:12 see line 248 for a few clues. 07:40:27 looking good 07:42:19 I'd entertain any suggestions at this point. 07:43:10 what's res stand for? 07:43:20 return stack? 07:43:23 res)erved[12] cells 07:43:34 ok 07:43:44 and regs is registers 07:44:01 cell/dcell width "registers"/memory-slots, yeah 07:47:46 boolstack, that's a term I hadn't heard before. 07:47:56 is it a pretty common construct? 07:48:31 yeah, I'm still not sure we want it - it's tathi's experimental "treat a 32-bit # as a bit "stack"' thang. 07:48:57 gets 1/0 out of the way nicely, but it may be a pita 07:49:02 seems like a cool idea. 07:49:07 yah 07:49:22 kind of obvious, now that I think of it 07:49:37 I left it in because it seems likely that, internally, 32 levels of truth may well be sufficient. 07:52:30 yah sounds likely 07:52:59 I can tell it's good-looking code, even if I don't quite understand it all 07:53:45 well, I'm faking a lot. Based on his original header, and what I recall from a multiple of forth-engines, filtered thru a deep-experience in C. 07:54:03 cool 07:54:49 how does CELL work out with itself being used in _cell ? 07:54:52 The opcodes alone are a challenge. I've almost doubled his original list. 07:55:03 what line you mean? 07:55:16 136 07:55:48 oh, as a pointer. C lets you talk of a typedef pointer when the size itself is still unknown. 07:56:02 ok 07:56:55 I can't imagine there will be much casting required under this header. I'd be suprised if, internally, it ever needs casts. 07:58:05 gtg 07:58:12 nice chatting with you 07:58:13 CELL=4; DCELL=8; FOVM=32; defaults=8 07:58:13 OPSx=131 07:58:18 sure. Laters 08:10:08 Why have you had to extend the opcode list? 08:11:48 for what 131 opcodes? 08:12:02 sorry, I was editing.. 08:12:45 Umm, because I covered a lot of areas that seem to be common. Gymnastics, single, double, fp precisions, etrc 08:13:31 Quartus: did you look up the rafb? 08:13:34 I find this notation: PU[0]==IP0 [... mmapped space ...] UP0==PU[1] really opaque and hard to follow. 08:13:57 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 08:14:21 it's a self-note, and it's because I felt we could use either-end for 2 solutions at a time. Easy to discard. 08:14:45 easier to check limits, overlap and less harmful in the end - near as I can tell 08:15:21 Sorta' like the ancient stack "grows down, heap grows up" idea. 08:16:36 btw, the PU[0] would be an array-ref; IP0 would be a relation like forth uses for "starting point" words 08:20:32 http://rafb.net/paste/results/n3nhBS62.html 08:20:42 above is updated since talking with docl and such.. 08:38:56 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 08:39:23 Needs some docs. I don't, for instance, know what range_map and range_unmap do. 08:41:25 sorry. Trying to consider init - and tathi uses mapped-memory for those areas 08:41:54 Conveniences for vm setup/shutdown 08:42:48 I've never used mmap/munmap() before, so I'm sorta' thinking of enable/disable or allocate/deallocate 08:55:35 --- quit: saon ("Lost terminal") 09:04:06 I find it hard to follow. My vision of a VM goes documentation->reference implementation, not the other way 'round. 09:05:03 yep, I find it odd as well. I'm just thinking 32-bit (ala' tathi) plus C, plus structs/ptrs and a LOT of engine memories. 09:05:33 I'm more interested in hearing about the generic opcodes. But, again: I may need to write some docs. 09:06:35 as a rule, I'm guessing no one even thinks about them - let alone an engine. 09:06:38 I think so. You certainly don't want to tie yourself to a specific implementation. 09:06:57 damn right I don't 09:07:31 I think you run that risk if you base your engine description on a reference implementation, as opposed to the other way around. 09:08:20 not really 09:09:12 I've had decades of success in beginning from proto/struct and then starting code. It all evolves, (of course), but it gives you an idea of what and where and who and how. 09:10:08 I'm not saying you can't get from here to a finished engine that way. I'm talking about documenting the abstractions, thus allowing alternate implementations. 09:10:15 at this point, I'm more worried about the opcodes than my structs. I'm working from what tathi had, but I suspect the list should grow larger and possibly break at some point before 8-bit 09:11:00 at this point, there is no "alternatives" because we are using C to mask bitsets and endian. Certainly I can see it might make a diff. 09:11:28 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 09:11:38 Even if there's no alternative but to use your implementation, you'll need docs to explain it. 09:12:17 Absolutely. However, most of it is pretty clear - and where it isn't is where I need to consider docs or changes. 09:12:33 Clear to you, I'm certain. 09:12:40 I'd never release it at this point, just solicitt ideas 09:13:25 dude, if you can't read C - yeah, it needs deep-docs; if you CAN, it's pretty well self-documenting. I'd not expect to write source at this point. 09:13:44 I'd like to contribute ideas, but what you've got is too opaque for me to undertake the effort of deciphering *why* you're doing any given thing. I can read C. 09:13:55 Again, I say: the opcodes bug me. I'm thinking there are core-codes I am prolly missing. 09:14:16 I don't think it's very readable. 09:14:43 tathi: how/where would you change it? I know I'm looking at at-least 2 files. 09:14:47 I can follow it, but I know what I had to start with, and I've been following your code long enough that I'm starting to get the drift... 09:14:53 I recommend literate programming. 09:15:25 Quartus: ooh, yeah :) 09:15:32 tathi: yeppers. It'll need a bit better organization and (certainly) docs - since it IS an engine. 09:16:05 PoppaVic: I don't think the code is particularly bad, there's just nothing there about any of the design or concepts at all. 09:16:17 right. 09:16:20 so unless you already know what's going on, it's hard to put the pieces together into a coherent whole. 09:16:32 Still thinking of you initial code, and I know I gotta' tame that. 09:16:38 right. 09:17:18 tathi: anything on the opcodes? I just added some new ones to support callot and cuallot, etc. 09:17:52 http://rafb.net/paste/results/anIkMU20.html 09:18:14 Are those memory allocation opcodes? Strikes me as a very high-level thing for a VM to do. 09:18:14 you're probably all right on the opcodes...IMO they're usually not _too_ critical. 09:19:33 well, I'm thinking the core-set should let us asm-up an engine as easily as c-code data. Mostly byte/word/dword data. But, I'd hate to learn we needed a new opcode or opcode-table at the beginning. 09:19:51 yeah, VM might not be the greatest term. 09:20:03 bytecode engine or something. 09:20:11 righto 09:20:49 Ok. So I'm just floundering around; you don't even have a published statement of intent. I'll drop out of this until you document something. 09:21:10 intent? what's that? :P 09:21:13 I can see at least 4 ops I am prolly missing which would otherwise be cascaded 09:21:51 tathi, it's just a tad irritating to have this being done in a public forum when it's really a private project. 09:21:57 C@/C!, @/! would be easy and bypass the pushAT/fetching ops. 09:22:26 yeah, I don't think it's very appropriate for this channel either. 09:22:36 not even sure the AT stuff _needs_ register-emulation 09:22:49 If you want input from the rabble, then make it at least possible for us to know what you're aiming for. 09:22:56 If not, manage the project privately. 09:23:01 a forthish-engine is anappropos? 09:23:23 inappropriate 09:23:39 yes, it needs docs. I think it's about ready for some. 09:28:44 --- quit: PoppaVic ("Back in a few...") 09:45:25 --- join: PoppaVic (n=pete@0-3pool157-116.nas22.chicago4.il.us.da.qwest.net) joined #forth 09:46:02 OK.. Back. I think I see some stuff I can rearrange before I even try to document the ideas/structs. 10:14:23 laters, I'll try to beat this more... 10:14:26 --- quit: PoppaVic ("Pulls the pin...") 10:17:13 --- quit: Snoopy42 () 10:17:27 --- join: Snoopy42 (i=snoopy_1@dsl-084-058-159-144.arcor-ip.net) joined #forth 10:53:57 --- join: crc (i=crc@pool-70-16-145-98.phil.east.verizon.net) joined #forth 10:54:17 --- mode: ChanServ set +o crc 10:57:28 --- quit: tathi ("leaving") 11:21:58 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 11:22:17 --- quit: ayrnieu (Nick collision from services.) 11:22:22 --- nick: ayrnieu_ -> ayrnieu 11:58:57 --- part: masak left #forth 12:13:02 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 12:13:19 --- quit: ayrnieu (Nick collision from services.) 12:13:24 --- nick: ayrnieu_ -> ayrnieu 12:47:44 --- quit: OrngeTide ("gone") 13:19:34 --- quit: Topaz (Read error: 104 (Connection reset by peer)) 13:21:40 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 13:37:09 --- join: OrngeTide (i=orange@rm-f.net) joined #forth 13:47:43 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-146-100.arcor-ip.net) joined #forth 13:56:13 --- quit: Topaz (Read error: 110 (Connection timed out)) 14:08:19 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 14:08:19 --- nick: snoopy_16 -> Snoopy42 14:45:56 --- join: TheBlueWizard (i=TheBlueW@ts001d0687.wdc-dc.xod.concentric.net) joined #forth 15:15:55 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 15:16:13 --- quit: ayrnieu (Nick collision from services.) 15:16:19 --- nick: ayrnieu_ -> ayrnieu 15:18:27 --- quit: crc (Read error: 110 (Connection timed out)) 15:25:33 --- quit: TheBlueWizard (Nick collision from services.) 15:25:43 --- join: futhin (i=thin@bespin.org) joined #forth 15:25:43 --- mode: ChanServ set +o futhin 15:26:11 --- join: TheBlueWizard (i=TheBlueW@ts001d0516.wdc-dc.xod.concentric.net) joined #forth 15:28:39 --- quit: TheBlueWizard (Nick collision from services.) 15:29:33 --- join: TheBlueWizard (i=TheBlueW@ts001d0730.wdc-dc.xod.concentric.net) joined #forth 15:35:27 --- quit: TheBlueWizard (Nick collision from services.) 16:08:22 --- quit: futhin ("leaving") 16:48:34 --- quit: OrngeTide ("home") 17:13:22 --- join: crc (i=crc@pool-70-16-155-14.phil.east.verizon.net) joined #forth 17:13:42 --- mode: ChanServ set +o crc 17:56:04 --- quit: crc (Read error: 104 (Connection reset by peer)) 17:59:54 --- join: crc (i=crc@pool-70-110-135-196.phil.east.verizon.net) joined #forth 18:00:14 --- mode: ChanServ set +o crc 18:07:32 --- join: futhin (i=thin@bespin.org) joined #forth 18:07:32 --- mode: ChanServ set +o futhin 18:13:42 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 18:46:51 --- nick: futhin -> thinfu 19:15:08 dun dun dun 19:16:58 O Forth, our VM and interpretive lang! 20:24:04 --- quit: virsys (Read error: 110 (Connection timed out)) 20:25:27 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 20:28:14 --- join: virsys (n=virsys@or-65-40-182-100.dyn.sprint-hsd.net) joined #forth 23:22:15 --- quit: ayrnieu (Nick collision from services.) 23:23:02 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 23:34:59 --- join: OrngeTide (i=orange@rm-f.net) joined #forth 23:53:04 i think we should ban futhin till he produces a forth compiler :) 23:53:11 }:) 23:53:27 * I440r thwaps thinfu with an isforth manual 23:59:59 --- log: ended forth/05.09.04