00:00:00 --- log: started forth/08.03.14 01:00:02 --- join: qFox (i=C00K13S@234pc222.sshunet.nl) joined #forth 01:10:35 --- join: uiuiuiu_ (n=ian@schihei.net) joined #forth 01:18:38 --- quit: uiuiuiu (Read error: 104 (Connection reset by peer)) 01:29:10 --- join: ygrek (i=user@gateway/tor/x-c95269c8ecb2192e) joined #forth 01:42:28 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 02:10:13 --- quit: arke (Success) 02:34:56 --- quit: nighty^ ("Disappears in a puff of smoke") 02:46:11 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 02:47:10 --- quit: ygrek (Remote closed the connection) 03:06:25 --- quit: sauvin (Read error: 104 (Connection reset by peer)) 04:03:15 --- quit: proteusguy (Read error: 110 (Connection timed out)) 04:04:16 --- join: proteusguy (n=proteusg@ppp-124-120-221-227.revip2.asianet.co.th) joined #forth 04:37:53 --- quit: proteusguy (Read error: 104 (Connection reset by peer)) 05:40:53 --- join: proteusguy (n=proteusg@ppp-124-120-221-227.revip2.asianet.co.th) joined #forth 05:56:52 --- join: lukego (n=lukegorr@p12502-adslbkksp4.C.csloxinfo.net) joined #forth 06:02:31 I would quite like to understand how to port / retarget a Forth system, like what's the general strategy. any pointers? 06:04:37 Did you have a particular system in mind? 06:08:58 I'm working with a Forth written by a friend. I'm developing on x86 (Mac) and targetting ARM7 (lpc2129). The forth system is bootstrapped from a compiler written in C that implements a large enough subset of Forth to create the initial dictionary and provide portable runtime versions of NEXT, etc. the bit I'm looking at now is how to add applications once the Forth has been bootstrapped. 06:10:25 it should be straightforward in principle to load the applications from source directly into the bootstrapped target, but that seems a bit funky since the target is not very powerful and I don't think it should be a real development machine (may be wrong). alternatively I could include more applications in the bootstrap image but that would involve extending the bootstrap compiler's C-implementation to handle more and more forth words th 06:10:57 so I'm wondering if there's some middle ground, e.g. where I could bootstrap on the host, extend the image on the host directly in forth, then install the image on the target. 06:11:54 my thinking is not very clear at this stage, in case you hadn't noticed. ;-) 06:29:18 --- join: madgarden (n=madgarde@bas2-kitchener06-1096620635.dsl.bell.ca) joined #forth 06:48:36 --- quit: ecraven ("bbl") 07:36:34 the paper "A Portable Forth Engine" by Ertl mentions the possibility of having portable forth images and using special memory access words like A! and A, to make them relocatable, but he doesn't say which released implementations actually have fully portable images. anyone know where to look? 07:37:20 I think that refers more to relocatable images than portable ones, as such. 07:37:48 Gforth can make a relocatable images, as I recall. 07:38:01 ah and I see he's one of the authors of Gforth. I'll look there first 07:40:24 --- join: Quartus__ (n=Quartus~@209.167.5.2) joined #forth 07:41:24 Compiling on-demand from source is a perfect reasonable option. 07:41:29 perfectly 07:41:32 saves a lot of grief 07:48:39 yes looking at all the code in Gforth's cross-compiler makes that sound quite believable. but I wonder if my target is too small to be nice for this, just 16KB ram 07:55:18 also our 'image' is split into two parts: the read-write RAM part and the read-only ROM part 08:12:25 --- quit: Quartus__ (Read error: 104 (Connection reset by peer)) 08:20:57 --- quit: Raystm2 (Read error: 104 (Connection reset by peer)) 08:24:01 It sort of depends on what capabilities you want in the target Forth. 08:24:40 We use the C-based pForth on ARM targets, and we've tweaked it in several ways. 08:26:07 I've done some work to treat the dictionary as read-only after we've finished compiling code, but I have not yet done the work to split the dictionary into separate read-only code and read-write data regions. 08:26:58 Doing that will require rewriting some of the Forth-based core, and I think it *may* make the system non-ANS compliant. 09:02:32 --- join: JasonWoof (n=JasonWoo@unaffiliated/herkamire) joined #forth 09:02:32 --- mode: ChanServ set +o JasonWoof 09:36:53 --- quit: JasonWoof (Read error: 104 (Connection reset by peer)) 09:38:30 --- join: JasonWoof (n=JasonWoo@unaffiliated/herkamire) joined #forth 09:38:30 --- mode: ChanServ set +o JasonWoof 09:55:02 --- quit: lukego () 10:01:41 --- quit: JasonWoof ("Leaving.") 10:02:55 --- join: Quartus__ (n=Quartus~@209.167.5.2) joined #forth 10:12:16 --- join: JasonWoof (n=JasonWoo@unaffiliated/herkamire) joined #forth 10:12:16 --- mode: ChanServ set +o JasonWoof 10:45:26 --- join: edrx (i=edrx@189.25.194.9) joined #forth 10:45:34 --- part: edrx left #forth 11:16:30 --- nick: Def -> Deformative 12:04:57 --- join: ygrek (i=user@gateway/tor/x-6b401ee86a1196f6) joined #forth 12:47:07 --- quit: fadec (Remote closed the connection) 12:58:25 --- join: arke (n=arke@p57A74301.dip.t-dialin.net) joined #forth 12:58:25 --- mode: ChanServ set +o arke 13:31:58 --- quit: omg911 (Read error: 110 (Connection timed out)) 13:51:45 --- quit: JasonWoof ("Leaving.") 13:56:24 --- quit: madwork (Read error: 104 (Connection reset by peer)) 13:56:25 --- join: madwork_ (n=foo@204.138.110.15) joined #forth 14:17:52 --- join: lament (n=lament@S010600110999ad06.vc.shawcable.net) joined #forth 14:17:55 TreyB, it shouldn't affect compliance. 14:26:44 --- quit: arke (Read error: 110 (Connection timed out)) 15:08:08 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 15:08:08 --- mode: ChanServ set +o tathi 15:55:20 --- join: arke (n=arke@p57A73E64.dip.t-dialin.net) joined #forth 15:55:21 --- mode: ChanServ set +o arke 15:59:11 --- quit: ygrek (Remote closed the connection) 17:19:24 TreyB, Quartus Forth runs on a similar model, and is compliant. 18:11:37 --- quit: qFox (":tiuQ)") 18:24:40 --- quit: Deformati (SendQ exceeded) 18:52:23 --- quit: tathi ("leaving") 18:53:09 --- join: snoopy_1711 (i=snoopy_1@dslb-084-059-109-115.pools.arcor-ip.net) joined #forth 19:10:08 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 19:10:30 --- nick: snoopy_1711 -> Snoopy42 21:09:55 Cool. I have not really thought through all of the details, and we don't require ANS compliance for our purposes, but it would help with training and such if we could use ANS materials. 21:10:34 It's entirely possible to separate code and data-space, and to seal off the dictionary from normal access, and still retain compliance.; 21:11:14 If that's what you're planning, of course :) 21:13:48 From a footprint point of view, we'd like to use the "precompiled" headers and code in ROM, and then add code and data in RAM at run time (where we'd typically discard the headers after compiling the RAM-based parts). 21:14:17 Once you're talking about a non-interactive Forth system -- a turnkeyed app, for instance -- compliance is no longer at issue;. 21:15:35 Yeah, we build all of our Forth code on a desktop system and then embed it as part of another file that we upload to the device (typically a cell phone but also data cards). 21:16:41 Quartus Forth does something akin to that -- builds stand-alone executables that can be exported and run on any Palm OS. 21:16:48 For remote diagnostics (and perhaps just the coolness of it), I'd like to have the ability to interact with the device via SMS or WAP messages. Sort of a text console via text messaging. 21:17:04 That would be interesting. 21:17:10 You'd need to keep the headers around for that. 21:18:01 We need the base system headers on the device because we compile on the device. 21:18:30 Sure. 21:18:56 But once we've compiled the downloaded code, we interact with the forth system via xt's and we toss the headers to save RAM. 21:19:15 Right. I'm thinking, in terms of your SMS console. 21:20:46 Firing up an interpreter doesn't cost too much, but keeping the headers around does. I could probably afford it for a little while, and if the device didn't receieve any more forth console SMSs after some timeout, it would toss the whole thing. 21:21:51 It would become a lot cheaper once I can use the precompiled base and headers out of ROM. Then I only need enough RAM for system variables and the new code. 21:22:06 I have a plan, I just don't have the time :-) 21:22:30 :) 21:26:04 I need to sort through the pForth forth sources and figure out how to allocate the mutable data separately from the code. Then I can copy the mutable data to the start of the RAM segment when I create a compile-capable VM. 21:26:21 That sounds workable. 21:27:01 I will happily accpet suggestions from the more experienced implementers in the channel ;-) 21:27:33 As much as I've done something that sounds quite similar, it sounds good. Happy to help with anything that crops up as you proceed. 21:28:38 It may take some time before I get to it, but I'll speak up when I do. 21:31:14 I'd really like to offer some of these changes back to the pForth maintainer, but our source trees have diverged so much that it means a lot of work. 21:31:36 Is it actively maintained? 21:32:01 It hasn't changed in some time, but the site remains active. 21:33:18 It seems to work well enough as a general C-based forth that I can see why development might have stopped. 21:33:46 Well, there can be many reasons. Plans but no time, sometimes :) 21:34:32 Most folks using it probably don't have the resource constraints that would encourage them to do the work. RAM and ROM come cheap to general computing devices these days. 21:35:47 A middle-ground cell phone sort of stradles the line between "real" embedded work and small systems work. 21:35:58 True. 21:39:30 Thanks for the chat. I need some sleep, for tomorrow I move a yard of mushroom soil (half composted cow manure) into my mom's garden. As payment she's promised either shrimp gubmo, boiled crawfish, or both. Plus she gets to visit with the grandkids :-) 21:39:40 I do too. Later! 21:57:10 well, I don't move the mushroom soil tomorrow. But I do need some sleep. :) 23:12:38 --- join: ball (n=ball@216.176.80.183) joined #forth 23:36:19 --- part: ball left #forth 23:48:41 --- join: sauvin (n=sauvin@c-98-213-60-175.hsd1.il.comcast.net) joined #forth 23:59:59 --- log: ended forth/08.03.14