00:00:00 --- log: started forth/10.03.05 00:33:10 --- quit: _dinya__ (Read error: Connection reset by peer) 01:18:11 --- quit: kar8nga (Remote host closed the connection) 01:32:29 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth 01:43:23 --- part: iaefai left #forth 01:47:51 --- quit: GammaRays (Remote host closed the connection) 01:48:26 --- join: GammaRays (~user@77.246.230.163) joined #forth 01:48:48 --- quit: ASau``` (Ping timeout: 245 seconds) 01:52:27 --- join: ASau``` (~user@77.246.230.163) joined #forth 02:15:38 --- quit: nighty__ (Remote host closed the connection) 02:56:42 --- quit: cataska (Quit: leaving) 03:18:23 --- quit: GammaRays (Ping timeout: 245 seconds) 03:21:17 --- join: GammaRays (~user@77.246.230.163) joined #forth 03:29:37 --- quit: scj (Ping timeout: 264 seconds) 03:35:40 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 03:35:40 --- join: scj (syljo361@boneym.mtveurope.org) joined #forth 04:18:23 --- quit: ygrek (Ping timeout: 245 seconds) 04:23:38 --- quit: kar8nga (Remote host closed the connection) 04:51:50 --- join: metaperl_ (~metaperl@adsl-157-132-72.cae.bellsouth.net) joined #forth 04:52:59 --- quit: metaperl (Ping timeout: 246 seconds) 04:53:40 --- join: metaperl (~metaperl@adsl-154-153-23.cae.bellsouth.net) joined #forth 04:56:27 --- quit: metaperl_ (Ping timeout: 265 seconds) 05:43:01 --- quit: GammaRays (Quit: ERC Version 5.3 (IRC client for Emacs)) 06:24:57 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 06:44:06 --- join: metaperl_ (~metaperl@adsl-154-153-23.cae.bellsouth.net) joined #forth 06:46:25 --- quit: metaperl (Ping timeout: 264 seconds) 06:46:25 --- nick: metaperl_ -> metaperl 06:48:52 --- join: TR2N (email@89.180.184.106) joined #forth 06:51:38 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 07:28:18 --- quit: metaperl (Ping timeout: 256 seconds) 07:40:12 --- quit: ASau``` (Quit: off) 08:33:47 I added unext to my processor. That was too good an idea to pass on, I decided. 08:34:26 I only get three opcodes per word, so I tweaked the implementation to allow the microroutine to span two cells (six opcodes max). 08:34:47 Not quite as simple as the one-cell implementation, but not so bad. 08:51:50 --- join: Snoopy_1611 (Snoopy_161@dslb-084-059-108-232.pools.arcor-ip.net) joined #forth 09:26:30 --- join: alex4nder (~alexander@wsip-72-215-164-129.sb.sd.cox.net) joined #forth 09:26:52 hey 09:40:17 hi 09:42:47 hi 09:42:52 how's it? 09:43:03 Working madly. 09:43:10 :) 09:43:24 nice. 09:48:20 I'm trying to get things organized at work 10:05:36 ASau: how's the work on pforth going? 10:55:27 --- join: Maki (~Maki@dynamic-78-30-167-37.adsl.eunet.rs) joined #forth 12:01:25 --- quit: alex4nder (Ping timeout: 264 seconds) 12:04:42 crcx: stall. 12:12:33 --- quit: ygrek (Ping timeout: 245 seconds) 12:12:41 --- join: forther (~62d2faca@gateway/web/freenode/x-hflbjftnzqsixwgb) joined #forth 12:12:49 hi 12:13:01 Hi. 12:13:31 What's up? 12:13:44 nothing 12:14:22 crcx: I've stopped at more invasive changes. 12:21:16 Mm, I am trying to decide if I am ambitious enough to register to vote. I really should. 12:24:43 ASau: ok 12:26:03 crcx: basically, the problem is that Forth insists on "one size fits all" approach. 12:32:50 in what way? 12:35:30 "Everything is a CELL." 12:36:32 most allow for access to other memory sizes when reading/writing 12:36:32 The main problem is that pointer is not "just" integer address. 12:37:22 Oh? 12:37:43 Deformative: "oh" what? 12:40:01 Pointers are not just integers? 12:40:12 --- join: crc_ (~charlesch@71.23.210.149) joined #forth 12:41:18 Yes. 12:41:36 Why not 12:41:37 ? 12:41:43 I've never seen a non-integer pointer 12:41:52 Me either. 12:42:22 Is 0x80083003 valid pointer? 12:42:45 maybe 12:42:51 So it is just the range that you are talking about? 12:43:00 "Maybe" isn't answer, either it is or it is not. 12:43:03 --- quit: crc (Ping timeout: 240 seconds) 12:45:53 just because a pointer points to a non-existant address doesn't mean it's not a pointer 12:47:20 Even when the address exists, it doesn't make it valid pointer. 12:47:38 There are two factors playing here: 12:47:59 1. Alignment restrictions (do remember unaligned access in 68k?). 12:48:07 A pointer is an unsigned integer, but that doesn't really matter since the memory interprets it as unsigned regardless, right? 12:48:11 2. Address bit width. 12:48:42 Oh, I see. So you're saying that 0x800083003 might be a valid char * but not a valid int *. 12:48:58 You cannot just come and say, "I want to have my Forth cells be int64_t." 12:49:54 When you say so, you have to map all pointer data consistently into int64_t. 12:50:29 Official pForth doesn't support it. 12:50:32 Neither does FICL. 12:50:45 Both assume that you run on, basically, VAX. 12:50:56 32 bit integers, little endian. 12:51:11 Unaligned octet addressing. 12:51:20 alignment isn't a problem in my forth :) 12:51:42 I know, all the world is VAX. 12:52:50 I only address 32-bit chunks 12:55:04 Ah, all the world is kinda ARM :D 12:56:13 I defined a virtual cpu and computer to use 13:07:03 Can someone comment on what !p+ is used for on the C18? 13:07:36 I see how @p+ scoops a literal out of the instruction stream, but I don't know why I'd want to do the corresponding write operation. 13:08:07 And yet Chuck spent a (precious) opcode on it, so it must be "for" something. 13:10:33 crcx: this cuts off all the world around which goes against primary goal of both pForth and FICL. 13:22:11 KipIngram: Search through comp.lang.forth if I remember correctly Jeff has commented !p+. 13:25:35 best use of !p+ when it's executed on port 13:26:17 or in unext 13:26:36 also it can be used to build "value" 13:26:50 Yes, it looks like it's discussed in connection with something called "forthlets." Apparently that's code that's loaded through a port? 13:27:00 but using on ports and inside unext is more important 13:27:29 not just ports 13:27:33 for example 13:27:45 begin @b !p+ unext 13:28:32 will fill the memory after begin ... unext with the data, received from the port, pointing by B 13:28:38 What does that do for you? When you're through with the unext you will start executing *after* the stuff you just copied. 13:28:48 no 13:29:22 No to what I said? But didn't you just move p past each word as you wrote it? 13:29:23 PC is incremented by !p+ 13:29:29 Right. 13:29:46 So it's pointing just past the last item that the loop writes. 13:29:53 yes 13:30:14 So execution will start there, won't it, when the unext loop falls through? 13:30:20 Or does it increment one more time first? 13:30:51 I assumed the thing fetched and then incremented. 13:30:52 execution will start just after latest word, stored by !p+ 13:31:05 Yes - that's what I thought I said. Sorry. 13:31:31 What would one use such a capability for? 13:32:06 storing the chunk of data 13:32:46 Ok, but I could have done that with !a+ as well, right? Is there a reason that doing it with p would be better in some cases? 13:34:35 1. you have to initiate A 13:34:52 2. sometimes A can be taken for something else 13:35:12 but yes, in general !a+ will do just fine too 13:35:35 Ok. So is "forthlet" a term used for a unext bundle? 13:35:52 from this point only unique !p+ feature is port execution 13:36:17 forthlet is no well defined term 13:36:48 personally I call the forthlet something you can send to the port 13:37:26 kind of c18's .exe format 13:43:03 --- quit: Maki (Quit: Leaving) 13:48:03 ASau: I have sockets and file I/O, which is enough for my current needs 13:58:52 I see. I will read up on port operation. Thanks very much 13:59:54 --- quit: qFox (Quit: Time for cookies!) 14:15:43 --- join: tathi (~josh@dsl-216-227-91-166.fairpoint.net) joined #forth 14:17:05 Hi all 14:46:15 Christ. All I'm finding in c.l.f is Jeff Fox castigating people for speculating about information in early-release marketing info. If he would have spent 10% of the space on *explaining things* instead of fussing at people he could have ensured that his fears of "false information spreading" would never come to pass. 14:49:47 Heh. 14:49:51 Yup. 14:50:13 What are you looking for? 14:51:44 Someone said that Jeff explained the intent behind !p+ in the C18 instruction set at some point. 14:51:53 That must have come later, though, after he was "allowed" to talk. 14:52:03 I've always found the elite Forth guys to be so damn secretive. 14:53:58 It's their IP so it's their right, but let's just say I'm glad the Linux kernel guys didn't choose that path. 14:54:18 Or Microsoft really would rule the world today. 14:55:07 --- quit: kar8nga (Remote host closed the connection) 15:00:10 Ok, now all I'm seeing (another part of the same thread) is stuff that seems to imply Jeff accused someone of copying Verilog, etc. etc. 15:00:19 Nothing seems to be really engaging with the technical material. 15:01:29 Yeah, sad. He used to be better, but a few years back he really started going off the deep end. 15:04:07 Another problem I'm running into is the site I'm searching this on won't seem to properly search for "!p+". It keeps taking the + as a meta-character that has its own meaning to the search engine. 15:05:30 I have several years archived locally -- the only one I see that looks even slightly useful is this: http://groups.google.com/group/comp.lang.forth/msg/8802e6d17bc056e8 15:06:15 Sounds like if the PC points to an I/O port it is not incremented 15:07:07 So you can use a micro for..next loop to read a bunch of instructions from another processor, then drop out and execute them? 15:07:18 But he certainly doesn't give all the details. 15:07:30 Oh, that does make a difference. That means you can execute a whole bunch of code from a port, then. 15:07:34 Hmm...I don't think I kept any of the Intellasys documentation around... 15:08:31 Wow, that post has some very annoying stuff in it too. 15:09:30 And you're right, it gives some tantalizing information but still doesn't really reveal the essence of it all. 15:10:19 I must not understand the way they hoped to make money on this. I'd have thought that if you were selling a processor and wanted people to crave it that you would make sure they really, *really* understood what it would let you do. 15:10:40 They must have had some grander plan than just selling the chips. 15:13:13 Since the C18 was meant to be a multi-core chip, but each ran code only from local memory, I expect all of this must have had to do with moving threads from one processor to another really efficiently. 15:19:18 Oh, hey, that Google groups page has a search box, and that actually seems to work. I found some more references. 15:29:28 This one has some good stuff in it: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/871249d0e1867ab7/3430001ff335bb15?lnk=gst&q=!p%2B#3430001ff335bb15 15:33:30 http://www.plans2reality.com/dox/SEAforth24A-7dp-v1_00n.pdf 15:54:34 --- quit: Deformative (Ping timeout: 248 seconds) 16:00:07 I used to work for a company that made programming systems for things like flash memories, microcontrollers, etc. Made it all the way up to engineering VP. A while after I left I thought about competing with them. 16:00:38 One of the ideas I had was to split the "pattern" (the data to be programmed which can get quite large in big flash devices) up and spread it out across numerous programming sites. 16:00:54 It would "circulate around," as each site programmed a different part of the device it was working on. 16:01:02 This would lower overall system memory requirements. 16:01:45 This C18 stuff we've been talking about might work the same way, with large algorithms broken up into pieces. 16:01:59 The pieces would "migrate around" from core to core, so that each core had the piece of the algo that it needed. 16:02:11 I could see all kinds of signal / image processing stuff working this way. 16:07:01 They talked about "floorplanning" a lot. 16:07:34 Within the core, or in terms of mapping applications onto the cores? 16:07:40 That's a common term in IC design. 16:07:41 mapping applications onto the cores. 16:08:17 That makes sense if they were thinking along the lines I just suggested; the app would have to be arrange so the code needed to migrate to the cores that were handy. 16:08:48 Sounded like they were talking about things being more static than that, but yeah. 16:10:04 Yes, the stuff I've read didn't really imply that code would move around an awful lot. Jeff specifically mentioned the fact that having a processor doing little instead of a lot eliminated the need for interrupts. 16:10:29 But that didn't necessarily mean the same little forever; it really just requires "a little at a time." 16:11:59 Fascinating - it really starts to come clear how all these ideas converge (lots of cores, small RAM, small stacks, easy core-to-core com, etc.) Exactly the kind of converence you'd expect from CM. 16:32:05 --- join: Deformative (~joe@c-76-112-68-135.hsd1.mi.comcast.net) joined #forth 17:08:03 --- quit: proteusguy (Ping timeout: 240 seconds) 17:20:59 --- join: proteusguy (~proteusgu@zeppelin.proteus-tech.com) joined #forth 17:50:21 --- quit: tathi (Quit: leaving) 17:55:13 Wait - when Jeff says "when the program counter is in register space the auto-increment is defeated" does he mean the "auto increment" associated with normal program execution, and *not* the "auto-increment" associated with @p+ / !p+? 17:56:09 Or all increment of p? 17:58:13 I guess it must be all of it. 18:17:15 --- nick: crc_ -> crc 18:17:18 --- mode: ChanServ set +o crc 18:19:39 right, when PC is on port !p+ does not postincrement PC, so it stays on the same port 18:20:33 I think it's explained in s40 datashit 18:22:51 also one of the place to ask the questions about c18 and s40 is http://groups.google.com/group/seaforth 18:24:16 I think I was not clear before, yes, PC doesn't increment when on register space 18:36:21 I think you were clear - I just got myself confused momentarily. 18:37:12 You know, I've now waded through reams of stuff from c.l.f, and I'm almost convinced that Jeff never actually got around to explaining this. He said many times that he "would soon," but I can't find any place where he delivered. 18:37:54 Just lots of "there's this amazing aspect to this no one's thought of, and if you will all quit speculating and be patient I will someday tell you about it." 18:38:50 You know what I think it was all about? If someone happened to guess the right answer, then any confidentiality agreements that got signed after that, by *anyone* would be null and void, because the idea was "out there" from a prior source. 18:39:13 It's standard in most CA's that if you can find the concepts available from a public source then confidentiality is no longer required. 18:39:33 So their goal was to *shut everyone up*, lest someone guess right. 18:39:44 It was all a shell game to protect their IP. 18:40:41 They had announce the product and reveal enough about it to attract interest, but they wanted to keep the CA-worthy window open for as long as possible. 18:41:09 I don't think so. It was patented before seaforth was discussed on c.l.f 18:42:28 Anything that got patented was available in the patent documents; why would Jeff have been unable to discuss it openly? Why did no one just go to the patent doc and look up the answer? 18:42:47 If it wasn't actually in a claim, in detail, then it wasn't covered by the patent. 18:43:21 Now, I suppose you could patent the physical operation of !p+ without having to discuss *why* it was valuable in full detail. 18:45:00 I think Jeff never been asked right questions 18:46:25 and I have no idea why ppl. on c.l.f didn't try to find out what's patented and available instead of just asking. probably bc asking is simpler 18:47:08 Well, that's certainly true. I'm guilty of it myself at times. Fastest possible route to the finish line; if someone can just give you an answer in two minutes then you don't have to spend two hours looking it up. 18:47:20 And when your boss is breathing down your neck that can seem like a pretty appealing gain. 18:47:43 :-) 18:48:01 I try to "pay it forward" by just answering questions when I know the answer, instead of saying "read documentation. :-) 18:50:45 Ugh, there are no resources to generate machine code from C like it is generated in forth. 18:50:54 No way to have a Forth-style dictionary in C. 18:50:56 :( 18:51:02 The valuable tidbits I've seen on this so far are 1) port pumps and 2) context switching. Jeff mentioned in one of those posts that he actually discovered !p+ himself, and was able to go from trashing three registers on context switch to trashing one. 18:55:35 I don't see how !p+ is relevant to context switching ... 18:56:11 in fact I don't see the ;oint of context switching in s40 18:56:47 why switch context if you can have 40 of it same time 18:57:07 Yeah, I know. I'm not looking at that post at the moment. But this all happened much earlier, on one of the earlier designs. 18:57:19 He cited it as the original motivation for !p+. 18:58:12 I guess he took something he otherwise would have trashed and saved it using !p+. 18:59:50 I'm not sure how you'd get it back without jumping through hoops. He talked at some length about how the earlier context switch led to trashing the three registers, but he just stated that with !p+ it went to one; he didn't lay it out. 18:59:57 hm ... I forgot if we had !p+ in i21 ... 19:00:15 Let me see if I can back up to that post. 19:01:01 F21. 19:01:27 they were close. f21 is Jeff's property 19:02:41 He was doing this from an interrupt. So that was one cell - on the return stack. And two from the data stack: one to save the value of a pointer register and one when you pushed the immediate you wanted to load into that pointer (to point it to the context save point). 19:03:22 So I guess you lose the return stack spot no matter what, but then you can store the stack top using !p+, fetch the pointer value, store it using !p+, etc. etc. 19:03:40 I see. 19:04:07 it makes sense. 19:04:55 But I agree with you - as they evolved toward the multi-core units I imagine that application became less and less important. 19:11:23 I guess once you had unext you could save most of it in one shot, couldn't you? 19:11:51 Seems like with a little cleverness you could write a snip of code that would either save the state or load it, right from inline memory. 19:13:27 heh i ported my wmdots demo (a windowaker dockapp) to GBA 19:16:03 Or maybe not. I think what you'd do is a !p+ right off the bat, to give yourself working room, but then you'd eventually put another copy of that in another place, so that you could restore it at the very end when you finished up: @p+ ret 19:16:28 Kind of tedious no matter what, I think. 19:24:23 Wow, Jeff *really* didn't like Bernd Paysan, did he? 19:24:37 At least not in 2006. 19:35:17 jeff fox? 19:35:55 I don't know. and actually don't care 19:39:24 but, yes, sometimes discussions on c.l.f get emotional 19:55:00 happens in here too 20:32:34 --- quit: proteusguy (Ping timeout: 264 seconds) 20:45:43 --- join: proteusguy (~proteusgu@zeppelin.proteus-tech.com) joined #forth 21:16:29 --- join: Al2O3 (~Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 21:27:39 --- part: TR2N left #forth 21:54:13 --- join: alex4nder (~alexander@70-7-194-72.pools.spcsdns.net) joined #forth 22:45:20 --- quit: forther (Quit: Page closed) 23:05:03 --- quit: alex4nder (Ping timeout: 240 seconds) 23:06:52 --- join: alex4nder (~alexander@dsl093-145-168.sba1.dsl.speakeasy.net) joined #forth 23:18:47 --- join: madwork_ (~madgarden@204.138.110.15) joined #forth 23:21:01 --- quit: segher (Quit: This computer has gone to sleep) 23:21:43 --- quit: madwork (Ping timeout: 245 seconds) 23:30:50 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 23:43:39 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth 23:57:08 --- quit: ygrek (Ping timeout: 245 seconds) 23:59:59 --- log: ended forth/10.03.05