00:00:00 --- log: started forth/19.06.13
00:06:04 --- quit: mtsd (Quit: leaving)
00:20:05 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
00:27:02 --- quit: Croran (Ping timeout: 252 seconds)
00:37:02 --- part: tp left #forth
01:27:23 <WilhelmVonWeiner> I love how non-busy this channel
01:27:25 <WilhelmVonWeiner> is
01:32:03 <rdrop-exit> c[_] Hello Forthlings
01:33:14 <WilhelmVonWeiner> I'm writing a stack cpu suspiciously similar to Nga in nim
01:33:37 <WilhelmVonWeiner> as an object type, so you can embed it in other things. 
01:33:42 <WilhelmVonWeiner> Not sure why yet.
01:34:33 <rdrop-exit> What do you mean by "as an object type"?
01:35:27 <dys> maybe an VHDL block?
01:35:52 <WilhelmVonWeiner> i just meant object
01:36:04 <rdrop-exit> I see, cool
01:36:05 <WilhelmVonWeiner> but Nim objects don't have encapsulated functions
01:36:24 <WilhelmVonWeiner> they're basically fancy structs afaik
01:36:37 <dys> oh, so by CPU you mean VM, and not hardware?
01:37:10 <WilhelmVonWeiner> ah, yeah, a soft core
01:37:33 <WilhelmVonWeiner> VHDL wouldn't be too hard though, but I don't know of any Free Software VHDL compilers
01:37:38 <WilhelmVonWeiner> synthesisers
01:37:40 --- quit: mtsd (Quit: Lost terminal)
01:38:28 <dys> I learned VHDL at university, but switched to verilog for my humble experiments now, since there is a completely free software toolchain yosys/icestorm available
01:38:45 <dys> i really hated messing with the 10GB closed-source monstrosities of the FPGA vendors…
01:38:57 <WilhelmVonWeiner> I too followed that pat
01:39:18 <WilhelmVonWeiner> though I haven't written verilog in a year or so
01:39:59 <rdrop-exit> Verilog/System Verilog is ok, quite a few gotchas, but I still prefer it to VHDL
01:41:00 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
01:42:21 <rdrop-exit> Is this the Nim you speak of? https://en.wikipedia.org/wiki/Nim_(programming_language)
01:42:28 <WilhelmVonWeiner> yep
01:42:58 <WilhelmVonWeiner> I use it instead of C++ or Rust or whatever
01:43:35 <rdrop-exit> I used to have a DOS Forth called Nimble
01:46:39 <WilhelmVonWeiner> oh cool
01:48:23 <rdrop-exit> Just did a quick read of the Wikipedia page
01:49:13 <rdrop-exit> "The goal for Nim is to be as fast as C, as expressive as Python and as extensive as Lisp."
01:49:50 <rdrop-exit> Whatever that means
01:50:45 <WilhelmVonWeiner> Compiles to C, nonrestrictive syntax, extensive compile-time macro system
01:52:07 <WilhelmVonWeiner> macros have access to the entire AST
01:57:12 <rdrop-exit> I've already got C, which compiles to C, and Forth with has nonrestrictive everything
01:58:07 <rdrop-exit> Can't say the description entices me
01:59:13 <rdrop-exit> I'd rather not need an AST
01:59:42 <WilhelmVonWeiner> The AST is the source file
02:00:28 <WilhelmVonWeiner> https://nim-lang.org/docs/macros.html
02:01:54 <WilhelmVonWeiner> you don't have to mess with the AST directly, there are templates which are more like C preprocessor macros
02:04:24 --- quit: ashirase (Ping timeout: 258 seconds)
02:06:35 <rdrop-exit> Words, stacks, blocks, and I'm good. :)
02:07:40 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:10:42 <rdrop-exit> C for when I need to play nice.
02:14:18 <WilhelmVonWeiner> I never really write C in my day to day life.
02:14:30 <WilhelmVonWeiner> Nim has replaced my C, Python and C++ usages mostly.
02:15:27 <WilhelmVonWeiner> I'd still use C for writing firmwares 
02:17:44 <rdrop-exit> I only used C++ on one project, it was at the height of the OOP craze, the C++ was implemented as a C preprocessor macros. Twas a long time ago.
02:19:52 <rdrop-exit> Never had to deal with C++ again after that one project.
02:27:42 <rdrop-exit> It's not that I particularly like C, it's a lesser of evils type of thing.
02:50:59 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
02:54:48 --- quit: proteusguy (Remote host closed the connection)
04:11:40 --- quit: Keshl (Read error: Connection reset by peer)
04:12:00 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
04:42:34 --- quit: dddddd (Remote host closed the connection)
04:44:56 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:46:42 --- quit: Keshl (Read error: Connection reset by peer)
04:47:16 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
05:08:38 --- quit: Keshl (Read error: Connection reset by peer)
05:08:44 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
05:09:36 --- quit: Keshl_ (Read error: Connection reset by peer)
05:10:04 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
05:56:44 --- quit: mtsd (Quit: leaving)
06:07:05 --- quit: cheater (Ping timeout: 245 seconds)
06:13:15 --- join: proteusguy (~proteusgu@cm-58-10-208-84.revip7.asianet.co.th) joined #forth
06:13:15 --- mode: ChanServ set +v proteusguy
06:30:31 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth
06:33:59 --- join: X-Scale` (~ARM@167.247.28.37.rev.vodafone.pt) joined #forth
06:35:29 --- quit: deesix (Ping timeout: 246 seconds)
06:35:46 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth
06:35:50 --- quit: X-Scale (Ping timeout: 248 seconds)
06:35:50 --- nick: X-Scale` -> X-Scale
06:51:57 --- quit: dave0 (Quit: dave's not here)
06:58:54 <zy]x[yz> i like c
07:00:12 <WilhelmVonWeiner> same
07:03:16 <zy]x[yz> i just wish i was smart enough to understand how to parse it
07:09:48 <crc> john_cephalopoda: try this http://forth.works/15b80f32f5417619304c8937bdccfabf.html for a `s:replace-all`
07:13:15 <john_cephalopoda> crc: I replace directly when getting the string now. Way shorter and in this case also works.
07:13:55 --- quit: xek_ (Ping timeout: 244 seconds)
07:37:26 <WilhelmVonWeiner> linux's syscall interface is so unhelpfully documented.
07:37:39 <WilhelmVonWeiner> unhelpfully undocumented.
07:41:37 <zy]x[yz> yeah
07:42:02 <zy]x[yz> i've used this https://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/
07:47:30 <crc> what information do you seek, and for which architecture?
07:48:02 <crc> https://fedora.juszkiewicz.com.pl/syscalls.html has syscall numbers and links to man pages relating to most of them for quite a few architectures
07:50:30 --- quit: deesix (Ping timeout: 248 seconds)
07:50:30 --- quit: dddddd (Ping timeout: 248 seconds)
07:56:05 <WilhelmVonWeiner> just the kinds of structs and arguments into each syscall
07:56:35 <WilhelmVonWeiner> seeing "sa_family_t" is unhelpful when it turns out to be an alias of "unsigned short"
07:56:45 <WilhelmVonWeiner> after grepping it in the source tree
07:57:07 <WilhelmVonWeiner> zy]x[yz: aweseome link dude
07:57:23 <zy]x[yz> ty i copied and pasted it myself
07:58:34 <WilhelmVonWeiner> I've been using this somewhat https://elixir.bootlin.com/linux/v3.19.8/source/
08:01:28 <WilhelmVonWeiner> crc: I'm on amd64, using the syscall interface in Lina Forth to write a sockets library.
08:01:41 <WilhelmVonWeiner> using sockets.f from gForth is cheating
08:04:11 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
08:05:40 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth
08:13:19 <remexre> anyone here implemented a relatively comprehensive amd64 assembler? I think I'm losing it trying to come up with naming conventions for the words with all the fancy addressing modes and all
08:13:46 <WilhelmVonWeiner> john had one but the code is very repetitive and unfactored
10:42:18 --- quit: rdrop-exit (Quit: Lost terminal)
10:53:20 --- quit: dys (Ping timeout: 245 seconds)
11:08:41 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
11:42:10 --- join: dys (~dys@tmo-110-61.customers.d1-online.com) joined #forth
11:45:56 <Zarutian> tp: mecrisp ya say. Been looking into putting it on an ATMEGA328p
11:48:29 <WilhelmVonWeiner>   
11:49:01 <Zarutian> when rdrop-exit returns: those three points on some people new to Forth not getting it are quite spot on.
11:50:41 <Zarutian> I have the habbit of cutting down and refactor word definitions in such a way it looks like the Retro quoted blocks style.
11:51:02 <Zarutian> though I am terrible at naming things so the name of the words themselfs might get a bit long.
11:52:01 <Zarutian> I got how Forth works (but not nescisarly how it is used) from reading Stack Machines The New Wave by Philip Koopman.
11:52:58 <Zarutian> which also helped me to appreciate excamera's J1 design.
11:54:32 <WilhelmVonWeiner> yeah, the only one I struggled with initially was long definitions
11:54:49 <WilhelmVonWeiner> Sam Falvo's "Over the shoulder" Forth video helped dearly
11:55:03 <WilhelmVonWeiner> I almost never write definitions over a line long now
11:56:01 <Zarutian> I often do but then I am putting in stack diagrams because I have conceptually few items on stack but each such takes an cell.
11:57:19 <Zarutian> takes more than an cell.*
11:57:20 <Zarutian> sorry
12:04:03 <WilhelmVonWeiner> I usually start with what I want
12:05:02 <WilhelmVonWeiner> : DUNGEON  ROOMS CORRIDORS DOORS  CLEANUP  DRAW ;
12:06:32 <WilhelmVonWeiner> : ROOMS   SIZE POSITION  COLLISION? IF RECURSE THEN  PLACE ;
12:06:48 <WilhelmVonWeiner> just as a demonstration not actual code
12:41:39 --- quit: gravicappa (Ping timeout: 245 seconds)
12:50:33 --- join: xek (~xek@host-89-228-113-212.dynamic.mm.pl) joined #forth
13:19:19 <john_cephalopoda> remexre: My code is only x86, not _64, and I focussed on a RISC-like subset of x86 assembly.
13:21:52 <remexre> john_cephalopoda: okay, so you have like MOVL-RR, MOVW-MR, MOVB-RM, ADDL-RR, etc?
13:36:22 <john_cephalopoda> I called that stuff MOVR8, MOVR16, MOVR32 (for R->R) as well as "MOVR2Mxx" and "MOVM2Rxx" for reg to memory and memory to reg respectively, with xx being 8, 16 or 32.
13:37:12 <john_cephalopoda> It is pretty primitive, mainly the MOV commands are implemented. It doesn't even have ADD in yet. Code is at https://github.com/jmf/impexus/blob/master/arch/x86/asm_x86.fth
13:43:17 <remexre> okay, I'll give it a look; thanks!
13:44:19 <remexre> tbh kinda considering not having CODE support on my x86(_64) implementations, and only shipping assemblers for ARM and RISC-V...
13:50:57 <john_cephalopoda> Heh
13:57:53 --- quit: xek (Ping timeout: 246 seconds)
14:02:23 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth
14:03:34 <dave0> hi
15:16:40 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
16:41:37 --- quit: john_cephalopoda (Ping timeout: 248 seconds)
16:54:58 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
18:23:12 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth
18:46:13 <rdrop-exit> c[_] Good morning Forth aficionados
18:47:11 <dave0> hi rdrop-exit 
18:47:22 <rdrop-exit> hi dave0
18:48:53 <crc> good evening
18:49:03 <rdrop-exit> hey crc
18:56:47 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth
19:03:45 --- quit: dave0 (Ping timeout: 245 seconds)
19:04:27 --- quit: dave9 (Ping timeout: 252 seconds)
19:05:32 <crc> I’m starting on a new tool for work; will be using forth for much of it :)
19:08:01 <rdrop-exit> Excellent :)
19:09:51 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth
19:11:44 <tabemann> back
19:11:48 <tabemann> hey guys
19:11:57 <crc> hi tabemann 
19:12:05 <rdrop-exit> hi tabemann
19:12:29 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth
19:12:41 * tabemann is stuck coding in java and javascript for work
19:15:57 <rdrop-exit> I feel for you
19:16:00 * tabemann should figure out how to set up a cross-compiling environment with gcc on linux
19:17:08 <tabemann> at least I get to do developing; my previous job was in C/C++/Objective C (all mixed together) and Java, but I did very little developing per se (as I ended up essentially as a tester)
19:18:29 <tabemann> on another note, I implemented a little tool recently
19:18:50 <tabemann> to convert the codebase of hashforth, aside from the runtime itself, from uppercase to lowercase
19:19:45 <tabemann> (if I change my mind again I could easily repurpose the tool to turn the code back to uppercase again)
19:21:33 <crc> I am able to choose the languages and tools I use. I'd hate being forced to use a language I disliked.
19:22:24 <rdrop-exit> 0 source  ASCII - Miscellanea - Case
19:22:25 <rdrop-exit> 1
19:22:25 <rdrop-exit> 2 : lower-case? ( x -- -1|0 ) byte a byte z between ; inline
19:22:25 <rdrop-exit> 3 : upper-case? ( x -- -1|0 ) byte A byte Z between ; inline
19:22:25 <rdrop-exit> 4
19:22:27 <rdrop-exit> 5 bl constant case%
19:22:29 <rdrop-exit> 6
19:22:32 <rdrop-exit> 7 : >lower-case ( x -- x' ) dup upper-case? case% ~ ;inline
19:22:34 <rdrop-exit> 8 : >upper-case ( x -- x' ) dup lower-case? case% ~ ;inline
19:22:37 <rdrop-exit> 9
19:23:10 <tabemann> see, it's not that simple, because I didn't want to change the case of comments, strings, or characters after CHAR or [CHAR]
19:24:06 <rdrop-exit> makes sense
19:24:30 <rdrop-exit> Need more coffee brb
19:26:13 <tabemann> crc: on a couple occasions I've been able to choose languages, e.g. when I created a testing framework at one job and when I chose an extension language at another job, but for the most part I've come into preexisting projects, where they can't change languages midstream
19:26:26 <rdrop-exit> back
19:26:32 <PoppaVic> front
19:27:03 <tabemann> wb
19:27:15 <rdrop-exit> Hi PoppaVic
19:27:21 <tabemann> hey
19:27:21 <PoppaVic> howdy
19:28:12 <crc> tabemann: in my case, I'm the only one doing any programming and have considerable latitiude in deciding how to proceed on projects.
19:30:10 --- quit: dave0 (Quit: dave's not here)
19:35:35 --- join: kori (~kori@unaffiliated/kori) joined #forth
19:39:45 <rdrop-exit> We should not be ashamed of bits. We should be proud of them. -- Alexander Stepanov
19:42:54 <rdrop-exit> Although Stepanov is mainly associated in people's minds with C++, I think he makes some interesting general points.
19:43:23 <rdrop-exit> (unlike Stroustrup)
19:45:03 <rdrop-exit> "I still believe in abstraction, but now I know that one ends with 
19:45:04 <rdrop-exit> abstraction, not starts with it. I learned that one has to adapt 
19:45:04 <rdrop-exit> abstractions to reality and not the other way around."
19:48:03 <rdrop-exit> Here's another one:
19:48:12 <rdrop-exit> “To see how to make something more general, you need to start 
19:48:12 <rdrop-exit> with something concrete. In particular, you need to understand 
19:48:12 <rdrop-exit> the specifics of a particular domain to discover the right
19:48:13 <rdrop-exit> abstractions.”
19:52:05 <tabemann> I agree completely
19:54:44 * ttmrichter applauds.
19:57:26 <rdrop-exit> "It is so sad that many people consider binary representation as a 
19:57:26 <rdrop-exit> low level thing, it isn't.
19:57:28 <rdrop-exit> "
19:59:48 <rdrop-exit> "We should view our activity of encoding reality into bits as a glorious activity."
20:02:40 <tabemann> okay, gotta head out - coffee shop is closing
20:02:52 <rdrop-exit> Ciao tabemann
20:07:05 --- quit: tabemann (Ping timeout: 245 seconds)
20:08:24 --- quit: kori (Ping timeout: 244 seconds)
20:16:35 --- join: proteus-guy (~proteusgu@cm-58-10-208-84.revip7.asianet.co.th) joined #forth
20:16:35 --- mode: ChanServ set +v proteus-guy
20:18:09 --- quit: proteusguy (Ping timeout: 248 seconds)
20:18:09 --- join: kori (~kori@187.123.3.51) joined #forth
20:22:24 --- quit: dbucklin (*.net *.split)
20:22:25 --- quit: kori (*.net *.split)
20:22:25 --- quit: john_cephalopoda (*.net *.split)
20:22:26 --- quit: X-Scale (*.net *.split)
20:22:26 --- quit: cheater (*.net *.split)
20:22:27 --- quit: dne (*.net *.split)
20:38:24 --- join: dbucklin (~dbucklin@ec2-18-221-180-137.us-east-2.compute.amazonaws.com) joined #forth
20:39:09 --- join: kori (~kori@187.123.3.51) joined #forth
20:39:09 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
20:39:09 --- join: X-Scale (~ARM@167.247.28.37.rev.vodafone.pt) joined #forth
20:39:09 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth
20:39:09 --- join: dne (~dne@jaune.mayonnaise.net) joined #forth
20:41:24 --- join: gravicappa (~gravicapp@h109-187-238-210.dyn.bashtel.ru) joined #forth
20:44:00 --- quit: dddddd (Remote host closed the connection)
20:44:00 --- quit: kori (Changing host)
20:44:00 --- join: kori (~kori@unaffiliated/kori) joined #forth
20:47:13 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b80c:b742:8944:c878) joined #forth
21:03:16 <proteus-guy> I've always done self hosted forth interpreters/compilers. Now I'm looking at a forth-ish interpreter that I can build up my code from and then, once satisfied, I will have it emit final compiled code which will run independently without any of the forth runtime. Presumably I put my main word on the stack and then call a compile-emit word which then just follows the call path of the main word down generating the object code 
21:03:16 <proteus-guy> for each word encountered then fixing up the calls in the final binary. Have any of you built such things before?
21:14:41 <rdrop-exit> If you don't want the generated object code to include a Forth interpreter (even a sealed one) then you're looking at building a target compiler. You need to split out what is host related and what is target related. If you've never done this before take a look at the ANS cross-compilation proposal and articles on target/cross compilation in Forth Dimensions and such.
21:15:16 <rdrop-exit> https://www.mpeforth.com/arena/XCapp5.PDF
21:18:24 <rdrop-exit> https://www.mpeforth.com/arena/XCtext5.PDF
21:22:19 <reepca> proteus-guy: "just follows the call path of the main word down" - that's actually a pretty hard problem to do when you allow things like EXECUTE and >R EXIT. Ends up needing data flow analysis to determine all the possible jump targets.
21:24:09 <tabemann> you also need to not make EVALUATE available
21:32:41 <rdrop-exit> As reepca and tabemann have implied, it's not an automatic conversion, you first have to have a target compiler/assembler on your Forth, then you use it to produce target object code.
21:33:48 <tabemann> one issue that I note is that your ability to use reflection is limited
21:34:13 <tabemann> because reflection can only happen within the interpreter/compiler, and cannot reach into the target except through compiling/assembling code for it
21:35:20 <tabemann> whereas in a forth where the interpreter/compiler's environment is the same as the target environment, immediate words can access the target state
21:37:39 <rdrop-exit> He's not producing a Forth as his target, just some standalone program.
21:38:08 <tabemann> e.g. one can't do : CONSTANT CREATE , DOES> @ ;
21:39:43 <tabemann> you can't code in Forth this way, you can only have a compiler for a Forth-like language which is not Forth that generates an executable
21:40:28 <tabemann> it's like my machine Forth that generated an image for hashforth - it looks a lot like Forth, but it is incapable of reflection
21:45:42 <rdrop-exit> You just have to be mindful of which words track things on the host about the target, and which words lay down target object code.
21:46:37 <rdrop-exit> You can have a combination of vocabularies and special words to help with that.
21:48:38 <tabemann> you need to strongly separate non-immediate and immediate words, with the only cases where they interact being through compilation of code and through controlling the compilation environment
21:49:10 <rdrop-exit> There are different approaches, some applicable to just laying down object code for a target, some applicable if you're talking to a live target.
21:49:49 <tabemann> talking to a live target is different, because you can design things so that immediate words can reach into the target's memory space at runtime
21:51:03 <tabemann> whereas when you're doing pure generation of an executable, the only ways to pass data from immediate to non-immediate is compilation or otherwise writing into a dictionary space that will be incorporated into the target executable
21:51:20 <rdrop-exit> You can achieve interactive incremental cross-compilation, e.g. SwiftX
21:53:36 <rdrop-exit> I'm not sure what you meant with you're last sentence. If you're just laying down object code, you can track whatever you want about it as you're doing it. No major issues there.
21:55:12 <tabemann> what I mean is you can't write code like this:
21:55:19 <tabemann> VARIABLE FOO
21:55:25 <rdrop-exit> Sure you can
21:55:40 <tabemann> : BAR 1 FOO ! ;
21:55:45 <tabemann> BAR
21:55:56 <tabemann> : BAZ FOO @ . ; IMMEDIATE
21:56:05 <tabemann> BAZ
21:57:54 --- quit: jedb (Ping timeout: 245 seconds)
21:58:02 <rdrop-exit> You have words that switch you from a target perspective to a host perspective, you can do anything you like as long as you're not trying to treat the target as live when it's not.
21:58:40 --- join: jedb (~jedb@103.57.72.31) joined #forth
21:59:35 <tabemann> precisely - it can't be normal Forth but rather a Forth-like language that separates host and target
22:01:11 <tabemann> I need to go to bed, though
22:01:16 <rdrop-exit> It's all Forth, I don't know what you mean.
22:02:24 <rdrop-exit> You are interactively and incrementally laying down object code for a target using your host Forth to do it.
22:03:43 <rdrop-exit> Just as your assembler is just an extension of your Forth, so is a target compiler (whether for dead or live targets).
22:04:31 <tabemann> except there are a number of restrictions one must impose, such as no EVALUATE, no EXECUTE for immediate words, no ' or CREATE or DOES> outside IMMEDIATE code, etc.
22:05:54 <tabemann> but anyways, g'night
22:06:01 <rdrop-exit> You can have a word on your host that CREATEs to the target, just put it in the target compilers vocabulary.
22:07:03 <rdrop-exit> What you can't do is run target code, unless 
22:07:35 <rdrop-exit> or rather except in some special cases where the target platform is the same as the host.
22:09:42 <rdrop-exit> You can have a target compiler ' that searches the target object, no problem.
22:16:50 <rdrop-exit> The main thing is that you can't just push a button on a Forth interpreter and expect a standalone stripped down target. What you can do is write a target compiler on your Forth so that you can explicitly target compile.
22:18:27 <rdrop-exit> If one doens't want to explicitly target compile, then use SEAL and words to strip out headers and such, but you won't get a minimal executable.
22:20:26 <rdrop-exit> Most DOS Forths used the latter approach.
22:25:56 <rdrop-exit> Just a clarification on the target compiler ' if your target is headerless you search on the target's headers are actually maintained on the host, but the address returned by the search is a target address.
22:30:49 <proteus-guy> yep there would definitely be no reflection available in the compiled program. it would no longer be forth - it would be an executable generated by forth. of course it would still be dual stack based operations.
22:33:31 <rdrop-exit> You can cross-compile another Forth if that's what you want.
22:36:42 <rdrop-exit> The most fun is to just talk to a monitor so you can interactively and incrementally put whatever you want on it and have all the reflection you want.
22:37:46 <rdrop-exit> (assuming it's not a Harvard target)
22:41:22 <rdrop-exit> That's the basic principle of most commercial Forths for embedded development.
22:42:53 <rdrop-exit> Forth Inc.'s SwiftX works that way, as does the equivalent one from MPE.
22:56:14 --- quit: dys (Ping timeout: 245 seconds)
22:57:53 <proteus-guy> rdrop-exit, yeah what you describe is what I'm anticipating. I've just never personally implemented such a thing. 
22:58:17 <PoppaVic> Come-come.. It's not a Real "project" unless you have to fight with Harvard.
22:58:22 <proteus-guy> As I build the app I want interactivity. But once it's done, I need to generate a binary target that loses those capabilities.
22:59:00 <proteus-guy> Actually the target *is* Harvard but my simulator is in code and I can fake it into giving me an interactive session.
23:02:46 <rdrop-exit> If your simulator is in code then build a small monitor on it that can laydown code into the simulated memory and query the simulator about the state of the simulated chip. Have your Forth dialogue with the monitor. Google "3 instruction Forth" for ideas.
23:04:21 <rdrop-exit> http://pygmy.utoh.org/3ins4th.html
23:08:34 --- join: dys (~dys@tmo-120-24.customers.d1-online.com) joined #forth
23:11:22 <rdrop-exit> Since you're working with a simulator, the monitor can just be an extension of the simulator, and doesn't have to be part of the target image.
23:15:21 <rdrop-exit> Since your simulator is just software you don't even need a serial link.
23:15:50 <PoppaVic> the target likely needs a bootloader anyway, and a monitor isn't much different. Stick the most rudimentary required routines into it
23:16:34 <rdrop-exit> Gotta go, catch you all later, keep on Forthin' :)
23:16:45 --- quit: rdrop-exit (Quit: Lost terminal)
23:59:59 --- log: ended forth/19.06.13