00:00:00 --- log: started forth/10.02.18 00:03:09 --- quit: segher (Quit: This computer has gone to sleep) 00:18:07 --- quit: skas (Quit: Leaving) 01:44:41 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 02:59:47 --- join: nizchka (~nizchka@h59237.upc-h.chello.nl) joined #forth 03:07:20 --- quit: TR2N (Ping timeout: 252 seconds) 03:09:29 --- join: GeDaMo (~gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth 03:50:44 --- join: maht (~maht__@85-189-31-174.proweb.managedbroadband.co.uk) joined #forth 03:51:13 --- quit: flash (Ping timeout: 252 seconds) 03:51:39 --- join: flash (~flash@61.149.172.1) joined #forth 04:03:26 --- quit: nighty__ (Ping timeout: 252 seconds) 04:18:59 --- quit: GeDaMo (Quit: Now I lay me down to sleep; Try to count electric sheep) 04:29:01 --- quit: nizchka (Ping timeout: 272 seconds) 05:03:56 --- quit: kar8nga (Remote host closed the connection) 06:20:42 --- quit: gogonkt (Ping timeout: 256 seconds) 06:40:35 --- join: gogonkt (~info@59.38.223.14) joined #forth 07:04:38 --- quit: Quartus` (Ping timeout: 240 seconds) 07:37:47 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth 08:09:04 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 08:25:03 --- join: GeDaMo (~gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth 09:20:09 --- join: snotforbrains (~snotforbr@ip68-226-15-108.ga.at.cox.net) joined #forth 09:34:16 --- quit: mathrick (Read error: Connection reset by peer) 09:38:51 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth 09:52:21 --- quit: kar8nga (Remote host closed the connection) 10:03:55 --- join: Quartus` (~Quartus`@74.198.8.60) joined #forth 10:13:27 --- join: Maki (~Maki@dynamic-78-30-167-37.adsl.eunet.rs) joined #forth 10:22:25 --- quit: Deformative (Ping timeout: 264 seconds) 11:03:19 --- quit: madwork (Read error: Connection reset by peer) 11:04:20 --- quit: Quartus` (Ping timeout: 260 seconds) 11:10:03 --- join: madwork (~madgarden@204.138.110.15) joined #forth 11:13:42 --- join: Quartus` (~Quartus`@74.198.8.60) joined #forth 11:16:39 --- join: xjrn (~jim@astound-69-42-10-25.ca.astound.net) joined #forth 11:25:53 --- join: Deformative (~joe@bursley-183118.reshall.umich.edu) joined #forth 11:28:46 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 11:33:51 --- join: segher (~segher@84-105-60-153.cable.quicknet.nl) joined #forth 11:34:41 --- quit: madwork (Ping timeout: 268 seconds) 11:41:51 --- join: alex4nder (~alexander@wsip-72-215-164-129.sb.sd.cox.net) joined #forth 11:41:52 re.. 11:42:00 Evening. 11:42:17 Wooo. 11:42:23 My group agreed to do a forth for our project. 11:42:24 Horay. 11:52:03 nice 11:53:17 --- join: madwork (~madgarden@204.138.110.15) joined #forth 11:53:29 --- quit: Deformative (Ping timeout: 256 seconds) 12:16:42 --- join: crcz (~Administr@216.1.43.130) joined #forth 12:21:42 --- join: TR2N (email@89-180-219-106.net.novis.pt) joined #forth 12:22:16 Hey, Deformative - congrats. Salesmanship points for that one. 12:24:59 You know that "virtual memory" idea I floated yesterday, where I proposed mapping a block of the target's memory space to a buffer residing on the host? 12:25:26 I planned on putting the dictionary and "development code" like the outer interpreter and so on there. 12:26:05 I doubt that will work - the concept is sound but it'll probably be prohibitively slow because I'd really like to use a bit serial connection between the host and target. 12:26:08 Memory mapped I/O? 12:26:20 Not exactly. 12:26:32 Quite similar. 12:26:47 Yes, but not really I/O in the general sense. Just a comm link. 12:28:03 Whenever the target referenced a memory location in the host range, the logic handling this would freeze the target in its tracks, shift the access information (address for reads, address and data for writes) out to the host, receive the appropriate reply (which would include the data for reads), and release the target for continued opertion. 12:28:25 So as far as the target was concerned it would behave just like a local memory access. It would just take a while, but the target state would be frozen during that time. 12:28:56 Obviously you wouldn't get valid timing and so on, but actual application code would be compiled to the target, so when you tested those words they'd run at speed. 12:29:49 The idea was to be able to compile only the absolutely required application *code and data* (no headers, etc.) to the target's RAM, thus minimizing the RAM required on the target. 12:30:00 And yet still have the whole thing run like an actual, proper Forth system. 12:30:49 Maybe I shouldn't rule it out without trying it (in fact, I probably will try it), but it occurs to me that threading through the outer interpreter, searching the dictionary, etc. etc. in fact involves a *lot* of memory access. 12:31:58 I could try to do it more properly and transfer a block of data on misses, like a more realistic virtual memory system, but that becomes a lot more complex in terms of logic. 12:33:57 If I could make this work, though, then it does double duty, serving also as the basis for KEY and EMIT. Those would simply read from / write to a specific memory address in the host block. 12:34:10 So it would be the only host interface I would need. 12:36:08 I imagine that if I make it work on blocks so that a "miss" transfers the entire, say, 256-byte block containing the needed address into a buffer on the target I'd get acceptable performance. 12:37:39 256-octet block is too small. 12:38:07 1024 octet block is rather small, and you make it 4x smaller. 12:39:15 I have very limited RAM on some of the FPGAs I want to use. That's the whole problem; if I had enough to make 1k acceptable for this purpose I'd just put the whole system in target memory. 12:40:20 Maybe I turn the whole thing around; instead of having the target capable of referencing memory on the host, maybe I make the host capable of accessing target memory and starting / stopping the target processor. 12:40:53 Then I have a software emulation of the processor running on the host, which would let me do development without being hooked to the target at all as well as move code to the target for testing at a later phase. 12:41:07 That's more software work, but it solves this problem pretty handily. 12:41:52 Then I could do stuff like run code on both the emulator and the processor and then compare the results. 12:42:38 --- quit: snotforbrains (Ping timeout: 252 seconds) 12:43:59 --- quit: Snoopy_1611 () 12:49:07 KipIngram: Maybe you should consider an umbilical Forth system. Cross compiler saves headers on the host and code is placed on the target. 12:49:51 If you don't need interpreter at later times... 12:50:00 On the target. 13:02:49 --- join: Deformative (~joe@bursley-183118.reshall.umich.edu) joined #forth 13:03:38 That's essentially what I am thinking, I believe. But I do rather like the idea of having an emulator that will let me develop code without the umbilical attached. 13:04:24 It will know whether the umbilical is attached, and if it is it will also keep the target's memory (a small amount at low addresses) in sync wit the host. 13:04:45 When it runs code living in emulator low memory it will also run that code on the target. 13:05:05 --- join: Snoopy_1611 (Snoopy_161@dslb-088-068-217-016.pools.arcor-ip.net) joined #forth 13:05:32 If a mismatch between the emulator and target memory images ever occurs then there is a problem. 13:06:16 Obviously once I have other hardware in the loop then the images won't match, but I'd expect an exact match only during the early parts of development, or "except for certain locations," etc. 13:09:28 Virtual description of the processor was quite handy for my project too. Especialy in early stages as you say. 13:09:51 But my system has resident interpreter. 13:11:40 Basic compiler takes about 2.5k words without headers. 13:12:48 Plus 2k for headers, which are in high, non executable, region. 13:14:12 You can place headers in DDR on your board if you decide to use it :) 13:30:04 --- quit: GeDaMo (Quit: Now I lay me down to sleep; Try to count electric sheep) 13:41:31 --- quit: alex4nder (Quit: bbl) 13:53:00 --- quit: Deformative (Ping timeout: 264 seconds) 14:00:31 My boards don't always have that. That's a very constrained thing; I absolutely can't put extra resources on board just to support this tool. 14:00:52 This approach is going to work; I already have an emulator executing the first few instructions. 14:14:02 --- join: Deformative (~joe@141.212.212.197) joined #forth 14:18:42 KipIngram: Good luck with your project. Over and out. 14:18:48 --- quit: Maki (Quit: Leaving) 14:27:24 --- quit: kar8nga (Remote host closed the connection) 14:34:33 --- quit: qFox (Quit: Time for cookies!) 14:55:07 --- quit: Quartus` (Ping timeout: 246 seconds) 15:06:34 --- quit: Deformative (Ping timeout: 256 seconds) 15:11:28 --- join: erider (~chatzilla@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #forth 15:11:42 --- quit: erider (Changing host) 15:11:43 --- join: erider (~chatzilla@unaffiliated/erider) joined #forth 15:19:57 --- join: Deformative (~joe@bursley-183118.reshall.umich.edu) joined #forth 16:13:35 --- join: nighty__ (~nighty@210.188.173.245) joined #forth 16:13:57 --- join: skas (~skas@eth488.act.adsl.internode.on.net) joined #forth 16:51:39 --- quit: Snoopy_1611 (Ping timeout: 268 seconds) 17:26:00 --- quit: Deformative (Ping timeout: 260 seconds) 18:11:49 --- join: Deformative (~joe@bursley-183118.reshall.umich.edu) joined #forth 18:28:03 --- quit: tathi (Quit: leaving) 19:13:54 --- join: Snoopy_1611 (Snoopy_161@dslb-084-059-127-011.pools.arcor-ip.net) joined #forth 19:15:28 Ok. That emulator works. I only have a handful of instructions defined, though (NOP, RET, JMP, LIT). But I wrote a poor man's assembler that lets the emulator read a source file when it fires up to define the emulator ram space. 19:15:53 And I wrote a monitor screen that shows me the instruction pointer, what's about to execute, the contents of a bunch of the ram, and so on. 19:16:20 Now I need to define rest of the instructions and start building the outer interpreter. 19:16:34 I'm really tempted to try that "FIRST / THIRD" thing; that was slick. 19:26:14 --- quit: ASau (Ping timeout: 265 seconds) 19:26:24 yeah it was neat 19:31:01 This "assembler" is brutally simple. No labels; all addresses are hard coded. Every line starts with the target address where that line should get assembled. 19:31:06 Abit of source might look like this: 19:31:14 0000 LIT LIT NOP 19:31:24 0002 1234 19:31:29 0004 5678 19:31:38 0006 ! NOP NOP 19:31:54 That would be equivalent to 1234 5678 ! 19:32:13 I could have put the ! on the first line; I was just making an example. 19:32:25 That is, I could have put it where the NOP on the first line is. 19:33:29 Putting an address on every line surely does make it easy to arrange stuff all over the memory map however I want. If I want something in low memory, that's where it goes. If I want it in high, that's where it goes. 19:35:34 KipIngram: have you downloaded it and tried it 19:56:10 Tried what? The FIRST/THIRD thing? 19:56:27 yes 19:57:21 I marked the paper on my Delicious. I haven't tried to use it yet, though. 19:57:46 I spent today building this emulator and getting the kinks out of it. 19:58:12 was it hard to get going 19:58:46 Not so bad. Just some stupid C++ errors. Things like putting & instead of % in format strings and so forth. 19:58:49 Forehead slappers. 19:59:24 hmm 19:59:25 Writing the emulator itself was nothing. It was the monitor screen that dumps registers and memory and the assembler that took more effort. 19:59:35 it worth trying I would say 19:59:48 I think I will. 20:00:35 Thought I don't really want "THIRD"; I want Forth. So I may start with THIRD and hack his source code to patch it up. But I haven't read the paper carefully enough to see what all of the differences are. 20:03:41 The idea here, I think, is that headers will always go in high memory. Stuff that actually matters (code, variables, etc.) will go either high or low, in a completely flexible way. 20:03:56 So I'll put the stuff that my app has to have low, and everything else high. 20:04:12 Then when I get it working I should be able to copy low ram to the fpga and it should run. 20:18:36 What's the standard syntax in "real Forth" for flexibly compiling to two different memory areas? 20:19:19 I don't need any fancy checking to make sure they don't collide; I just need to be able to target all the pointers in a quick and easy way. 20:19:55 I also don't know that I really care about having distinct vocabularies and so on. If I wind up with that fine, but it's not something I insist on. 20:20:47 A linear, monolithic dictionary would be just fine with me. That would mean, though, that FORGET would have to prune back both memory areas. If I have to FORGET each area separately that's fine too. 20:37:56 But if they were threaded together as one linked list, then it wouldn't be too hard to get FORGET to wind them both back, would it? The headers would all be linked in one list, so that would take care of itself. All it would take would be FORGET to know where the dividing line between "low" and "high" memory was, and update LO_HERE and HI_HERE, or something like that. 20:39:27 Maybe I'll treat high memory in an entirely conventional way, with the headers and the code all mixed together. Low memory defintions will be "body-less" in high ram; instead there will just be a pointer in the definition to low ram where the "business end" lives. 20:40:07 Then FORGET will just have to cut LO_HERE back to the lowest value pointer associated with a forgotten word. HI_HERE it will handle just like it normally handles HERE. 20:40:15 Anyone see a problem with that? 20:58:28 --- quit: erider (Ping timeout: 256 seconds) 22:09:20 --- join: ASau (~user@83.69.227.32) joined #forth 22:11:42 KipIngram: Fun. 22:45:46 --- quit: skas (Quit: Leaving) 23:26:15 KipIngram: no need to blame people, C++ changed in past. 23:35:04 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth 23:36:10 --- join: alex4nder (~alexander@dsl093-145-168.sba1.dsl.speakeasy.net) joined #forth 23:36:11 hey 23:38:41 Mrngng. 23:59:59 --- log: ended forth/10.02.18