00:00:00 --- log: started forth/19.02.10
01:48:15 --- join: xek (~xek@apn-37-248-138-81.dynamic.gprs.plus.pl) joined #forth
02:04:09 --- quit: ashirase (Ping timeout: 240 seconds)
02:14:09 --- join: ashirase_ (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:54:13 --- join: pagnol (~me@p54BE8660.dip0.t-ipconnect.de) joined #forth
03:03:20 --- quit: proteusguy (Ping timeout: 245 seconds)
03:26:28 --- quit: pagnol (Ping timeout: 244 seconds)
03:31:35 --- join: pagnol (~me@p54BE8660.dip0.t-ipconnect.de) joined #forth
03:40:48 --- quit: pagnol (Ping timeout: 240 seconds)
03:43:04 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:16:15 --- quit: xek (Ping timeout: 245 seconds)
04:39:24 --- quit: pierpal (Ping timeout: 250 seconds)
04:53:54 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
06:02:02 --- join: pagnol (~me@p54BE8660.dip0.t-ipconnect.de) joined #forth
06:17:40 --- quit: Zarutian (Read error: Connection reset by peer)
06:18:36 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
06:39:42 --- quit: Zarutian (Read error: Connection reset by peer)
06:39:48 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
07:07:57 --- join: gravicappa (~gravicapp@h109-187-219-53.dyn.bashtel.ru) joined #forth
07:42:14 --- join: xek (~xek@apn-37-248-138-81.dynamic.gprs.plus.pl) joined #forth
07:44:46 --- quit: dys (Ping timeout: 268 seconds)
07:49:31 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
07:49:31 --- mode: ChanServ set +v proteusguy
07:54:50 --- join: dys (~dys@tmo-101-75.customers.d1-online.com) joined #forth
07:55:16 --- quit: xek (Ping timeout: 250 seconds)
08:08:02 <WilhelmVonWeiner> Morning forth
08:09:35 <PoppaVic> g'day
08:30:27 <proteusguy> john_cephalopoda, impexus is using gforth to bootstrap your new forth?
08:34:51 <proteusguy> corecode, congrats on the forth cpu!!
08:34:54 <john_cephalopoda> proteusguy: I wrote an assembler in gforth/pforth which creates a multiboot executable, which can be booted.
08:35:49 <john_cephalopoda> So gforth/pforth is needed for bootstrapping but it hasn't a dependency on any specifics, most ANS-y forths should do.
08:36:34 <proteusguy> john_cephalopoda, so ultimately your forth will be self-hosting, yes?
08:39:00 --- join: pareidolia (~pareidoli@87.213.124.143) joined #forth
08:41:04 <pareidolia> I read this article and I am intrigued (https://blog.30dor.com/2014/03/11/an-avr8-forth/)
08:41:30 <pareidolia> In particular, how is compilation done on the host machine
08:42:24 <pareidolia> I suppose the : must be redefined to switch from local compilation and add to the vocabulary, to cross compilation and add to the AVR's vocabulary
08:42:42 <pareidolia> Anyone got some more resources on this type of thing?
08:43:14 <PoppaVic> oh, a tethered/umbilical forth?
08:43:34 <pareidolia> Yes
08:45:34 <PoppaVic> It should be noted: if you fully intend to incremental-develop on the MCU, the flash has limited-life and you'll sacrifice them over time. But, no. Riscy Pignys? Swiftforth, for sure. I'm tinkering a VM for such a thing. I did have a testbed mostly working on my Uno, but it got flakey.
08:46:22 <PoppaVic> I think my newer idea may work better. But, I've been outlining it for weeks, and I think today I start code.
08:47:24 <PoppaVic> pareidolia: Except for the frank sergeant stuff, (which I have glanced at only), all the rest seems to be for-pay and not cheap.
08:51:10 <pareidolia> PoppaVic: That article doesn't even mention cross compilation, just using a serial line as a glorified remote control to twiddle peripherals that happen to be memory mapped. Do I understand correctly?
08:52:19 <PoppaVic> pareidolia: I remember that article, yes: he teases and disappears. http://pygmy.utoh.org/3ins4th.html is also worth reading - several times
08:53:48 <pareidolia> That's the one, yes
08:54:04 <pareidolia> It doesn't mention how cross compilation is done at all
08:55:06 <PoppaVic> iirc, that latter link is related to Riscy Pygness and if I further rc, he uses a hosted forth to run a 'metacompiler' sort of thing.
08:56:14 <PoppaVic> So, C or whatever: you write a host program that KNOWS the target and they share a protocol, and you are off to the races.. Any databases are on the host, user is programming on the host, squirting commands or code or "macros" to the target.
08:56:59 <PoppaVic> target is responding to the squirted orders - to include replying with data from stack[s], etc.
09:09:13 <john_cephalopoda> proteusguy: Yes, the ultimate goal is to be self-hosting.
09:19:58 --- quit: proteusguy (Remote host closed the connection)
09:21:20 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
09:21:20 --- mode: ChanServ set +v proteusguy
10:47:51 --- quit: pierpal (Quit: Poof)
10:48:11 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
10:48:40 --- join: tbemann (~androirc@2600:1700:7990:24e0:a92b:faaa:abf6:25ad) joined #forth
10:49:47 * tbemann feels stupid for not using task-local storage in one of his examples
10:55:48 <tbemann> i.e. there is a word THERE analogous to HERE and a word TALLOT analogous to ALLOT except they do not share space with other tasks (unless of course you move the HERE pointer back over the task's own data structures, where then bad things happen unless you've deactivated the task and never activate it again)
11:00:00 --- quit: gravicappa (Ping timeout: 272 seconds)
11:10:44 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
11:17:43 <PoppaVic> OK, so... a 64-bit cell is interesting, but the work necessary for mixed-mode math won't be.
11:18:39 <WilhelmVonWeiner> how does "IMMEDIATE" usually work? 
11:19:02 <PoppaVic> sets a bitfield in a header
11:20:10 <WilhelmVonWeiner> Yeah, but is the way it finds the header usually implementaion dependent or will they usually provide a word for the latest header
11:20:30 <PoppaVic> oh, yes: LAST or LATEST perhaps
11:21:13 <PoppaVic> gforth is ugly & verbose, but:
11:21:15 <PoppaVic> see immediate 
11:21:15 <PoppaVic> : immediate  
11:21:15 <PoppaVic>   immediate-mask lastflags cset ; ok
11:21:15 <PoppaVic> see lastflags 
11:21:15 <PoppaVic> : lastflags  
11:21:16 <PoppaVic>   latest dup 0= 
11:21:18 <PoppaVic>   IF     c" last word was headerless" c(abort") 
11:21:20 <PoppaVic>   THEN 
11:21:22 <PoppaVic>   cell+ ; ok
11:24:42 <WilhelmVonWeiner> gforth is so ugly and so verbose
11:24:51 <WilhelmVonWeiner> but yes, latest, cool
11:30:10 <tbemann> so LATEST is separate from LATESTXT in gforth and points at a given word's header
11:33:18 <zy]x[yz> wtf is latestxt
11:33:30 <zy]x[yz> (i guess it's LATEST >XT
11:33:32 <zy]x[yz> )
11:34:56 <tbemann> LATESTXT gets the execution token of the most recently declared word
11:50:03 --- quit: tbemann (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
12:12:00 <john_cephalopoda> tabemann: "THERE" for "Task HERE" is genious :D
12:12:51 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
12:14:29 <WilhelmVonWeiner> I thought it meant TASK HEADING, EXPLICITLY RESERVED ENTRY
13:03:28 <KipIngram> :-)
13:13:39 <PoppaVic> w00t.. I end up with a spare opcode.. Damn.. wtf to add?
13:14:18 --- quit: xek (Ping timeout: 240 seconds)
13:14:19 <WilhelmVonWeiner> r@
13:14:45 <WilhelmVonWeiner> or over
13:14:54 <PoppaVic> all covered.
13:15:06 <WilhelmVonWeiner> what's your list?
13:15:29 <PoppaVic> just a sec
13:16:48 <WilhelmVonWeiner> `zr` "zero return" is a cool one. TOS 0= consume and return, otherwise leave it and continue execution
13:17:07 <WilhelmVonWeiner> ( n -- |n)
13:17:39 <PoppaVic> https://pastebin.com/AAqJzbBf
13:18:09 <john_cephalopoda> Stack operators... how do I write down stack ops for the return stack and the fp stack?
13:18:36 <PoppaVic> '>R'        (n- R(- n) 
13:18:45 <WilhelmVonWeiner> ( R: --)
13:18:58 <WilhelmVonWeiner> ( F: --)
13:19:21 <PoppaVic> WilhelmVonWeiner: anyway, I got one slot open. Something useful would be appreciated.
13:19:49 <PoppaVic> (I didn't even want to add C@ and C!)
13:19:54 <WilhelmVonWeiner> You *could* split <<>> into two words, so you can avoid negate nonsense 
13:20:07 <PoppaVic> yeah, I been musing over that.
13:20:20 <WilhelmVonWeiner> not "nonsense" but it's a step that needn't be
13:20:27 --- quit: mtsd (Quit: WeeChat 1.6)
13:20:49 <PoppaVic> It's a "maybe", as it's not much of an issue with bytecode.
13:22:58 <WilhelmVonWeiner> is the stack description for 2-rot wrong?
13:23:08 <WilhelmVonWeiner> won't 2rot and 2-rot do the same thing?
13:23:13 <PoppaVic> no
13:23:19 <WilhelmVonWeiner> ignore that last sentence but still
13:23:23 <PoppaVic> it's like rot and -rot
13:23:47 <WilhelmVonWeiner> oh d1 d2 d3 lol
13:23:49 <WilhelmVonWeiner> ignore me
13:33:46 <zy]x[yz> PoppaVic, r@+ - fetches from the address on the return stack and increments it by one cell.  now lit is just  : lit r@+ ;  and it comes in handy for lots of other things, too
13:35:04 <PoppaVic> um.. that presupposes. I don't want to go too far astray from the basics.
13:57:40 <zy]x[yz> presupposes what?
13:58:48 <PoppaVic> that the top of R points at the next cell, etc. 
13:59:18 <PoppaVic> in any event, it won't be a secondary
14:00:51 <zy]x[yz> it takes the top of the return stack as an argument the way @ takes the top of the data stack as an argument
14:01:14 <zy]x[yz> it just happens to conveniently be the next cell of the execution stream in some cases because it's on the return stack
14:01:22 <zy]x[yz> you don't have to use it that way; i often don't
15:13:00 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
15:27:18 --- quit: pagnol (Ping timeout: 240 seconds)
16:02:35 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
16:03:31 <dave0> hi
16:08:50 <crc> hi dave0
16:16:55 <dave0> hi crc
16:20:56 --- join: pagnol (~me@p54BE8660.dip0.t-ipconnect.de) joined #forth
16:32:45 <PoppaVic> zy]x[yz: interestingly, "r@ CELL+" seems the most 'common' idiom - a thousand different phrases use r@ similarly. (see: grep -i " r@ " `locate *.fs`|less)
16:35:49 <rdrop-exit> Good morning Forthwrights
16:36:03 <PoppaVic> hi, rdrop-exit 
16:36:21 <rdrop-exit> Hi PoppaVic
16:39:51 <rdrop-exit> "r@ cell+" is probably common in ITC
16:41:03 <PoppaVic> rdrop-exit: I got one free opcode, zy]x[yz suggested R@+, and I just searched the files I have from gforth and friends. Just was curious if the idiom was common enough for using my last open slot ;-)
16:41:53 <PoppaVic> his op should really be called R@++, but some folks run screaming from c and c'isms
16:42:43 <pagnol> anyone here familiar with https://kittenlang.org/ ?
16:42:44 <rdrop-exit> Using a single plus in Forth, e.g. @+ 
16:43:55 <PoppaVic> pagnol: I already have multiple "concatenative languages". No interest in learning freakish stuff
16:44:04 <rdrop-exit> What your last op should be depends a lot on the rest of your ops and what would work best in combination with them
16:44:26 <PoppaVic> rdrop-exit: yes, you'd think so.
16:45:13 <rdrop-exit> You could save it for some debug related op, have it push a magic number or have it trap until you decide
16:46:12 <PoppaVic> that almost sounds sane. Not sure what I'd do with it.
16:46:24 <rdrop-exit> No interest in "concatenative languages" either
16:47:04 <rdrop-exit> I have 3 or 4 unused slots in my host vm
16:48:19 <PoppaVic> Yeah. I'll leave it for now, then.. I think you might have a "clew" there for me, but I'm not there yet anyway - it'd sorta' be the complete inverse/reverse of a NOP. Not a HALT, but it'd be something like DEBUG
16:48:50 <pagnol> why the hostility?
16:48:59 <pagnol> nobody's forcing you to do anything
16:49:09 <PoppaVic> "When you hit this opcode, it halts the VM and spews the stack and registers to the host" comes to mind
16:49:22 <PoppaVic> pagnol: dude, yer in #forth. Get on the bus.
16:49:36 <pagnol> so?
16:49:48 --- quit: john_cephalopoda (Ping timeout: 240 seconds)
16:49:58 <rdrop-exit> What hostility, I just said I had no interest, that's indifference, not hostility
16:51:38 <rdrop-exit> I have a (relfect) opcode that reflects that copies the internal state of the VM to a reserved area in low memory
16:51:43 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:52:34 <PoppaVic> yeah, but MCU's are usually memory shy - I need to sleep on the idea, but it's a "by golly!" special ;-)
16:52:59 --- quit: amuck (Ping timeout: 268 seconds)
16:53:18 <rdrop-exit> Yes, my VM is just for the host side, I don't use it targets
16:53:28 <rdrop-exit> * it on targets
16:53:35 <PoppaVic> right.
16:54:47 <PoppaVic> I'll be starting there, but I want to shovel it over to my MCU's - compact code that runs from any memory sounds like a win ;-)
16:55:29 <rdrop-exit> Look into the Europay project, they were using a VM on targets IIRC
16:55:55 <rdrop-exit> It was a joint Forth Inc/MPE project
16:56:07 <PoppaVic> ahh
16:57:37 --- join: amuck (~amuck@152.243.185.35.bc.googleusercontent.com) joined #forth
17:03:45 <rdrop-exit> For a small target ip>r ( -- )( r: -- ip ) can be interesting, yield ( -- )( r: a -- ip ) also.
17:08:20 --- quit: pagnol (Ping timeout: 245 seconds)
17:08:47 <rdrop-exit> ip>r allows you to implement all backward branches throught the return stack, yield lets you do coroutines if you don't want the overhead of tasks
17:12:41 <rdrop-exit> Both are would require a lot of overhead to implement above the VM
17:13:01 <rdrop-exit> Sorry about typos, not fully awake
17:17:43 <rdrop-exit> Note that the ip in both cases is the program counter of the VM
17:18:53 <rdrop-exit> (or the real chip if there's no underlying VM).
17:20:01 <PoppaVic> rdrop-exit: interesting. I don't plan to expose any "registers" at all. Just Cuz.
17:21:33 <rdrop-exit> ok :)
17:29:21 <rdrop-exit> In the end it's always simpler to cross-compile something application specific to a target, than come up with a general purpose target that will work well across many different applications.
17:37:15 <yunfan> hope so
17:38:48 <PoppaVic> rdrop-exit: I'm only focused on the VM "opcodes". I don't care how many clocks are used, lines of C, etc. Just that the VM is "portable".
17:40:16 <yunfan> PoppaVic: if that's too slow, i guess portable is not needed
17:40:34 <rdrop-exit> Sounds similar to what tabemann is working on
17:40:48 <yunfan> i think you could always have a comparing target like lua's vm
17:41:01 <PoppaVic> yunfan: yeah, my idea is to target MCU's
17:42:28 <yunfan> PoppaVic: then speed is always need to be considered, for eg, i used to use soft spi from micropython on esp8266, which's slow speed caused my spi display laaaaag
17:42:53 <yunfan> PoppaVic: while someone's cpp code works well using the same soft spi 
17:43:45 <PoppaVic> Yes, don't code shit that should be native-code in bytecode ;-)
17:44:55 <rdrop-exit> Makes sense
17:45:08 <PoppaVic> and soft SPI makes me think "Golly, buy the next chip UP in that series"
17:46:37 <yunfan> anyway , prefer vm design too. 
17:47:01 --- quit: pierpal (Quit: Poof)
17:47:21 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
17:47:54 <rdrop-exit> how many opcodes do you have?
17:48:13 <PoppaVic> me? 64-1
17:48:36 <rdrop-exit> 6 bits
17:48:44 <PoppaVic> yup
17:48:59 <PoppaVic> 2 bits are a control field.
17:49:33 <rdrop-exit> What are the 4 options?
17:52:14 <PoppaVic> instruction, smalllit, jmp vectable, zjmp vectable
17:53:09 <rdrop-exit> thanks
17:53:26 <PoppaVic> yup
17:55:51 <rdrop-exit> brb
17:57:44 <rdrop-exit> I use 8 bits fully encoded (except for small lits) on my host VM
17:58:32 <PoppaVic> I couldn't see 256 damned opcodes.
18:02:47 <rdrop-exit> On a host it can make be worthwhile to have each "VM machine cycle" do more work, on a target less so.
18:03:00 <rdrop-exit> * it can be
18:05:20 <yunfan> why you guys dislike to use byte based bits group?
18:05:40 <rdrop-exit> I use 8 bits, i.e. a byte
18:05:53 <yunfan> rdrop-exit: you were rare :D
18:05:58 <PoppaVic> I don't. I use bytes fine, but packing smaller bitfields sucks.
18:06:59 <rdrop-exit> Many of my host opcodes are actually what are sometimes called super-instructions.
18:07:33 <PoppaVic> yeah, VMGEN voodoo
18:08:27 <rdrop-exit> Merging of more basic instructions, e.g. @@+ ( a -- x ), indirect fetch cell through <a> forward streaming.
18:10:24 <rdrop-exit> i.e. indirectly fetch through <a> then increment the cell at <a>
18:10:55 <crc> I could use just 5 bits, but use 8 as the extra density wouldn't help enough to be worth it in most cases with my current compiler.
18:12:21 <crc> If I had a better inliner this could potentially change, but in my tests, with my current images, the extra unpack/decode time actually makes it a little slower.
18:13:41 <rdrop-exit> If you're designing your own chip (or FPGA based soft chip) then bytes can be irrelevant, depending on the app of course, even odd cell sizes like 19 bits can make sense.
18:14:08 * crc would like to do this someday...
18:15:06 <rdrop-exit> But much of the outide world cares about bytes, and multiples of bytes.
18:16:53 <rdrop-exit> The main reason I use 8 bit opcodes on the host (i.e. desktop) is that it makes life easier in that world, not because I have any special attachment to 256.
18:18:23 <PoppaVic> I got a special attachment to "smallest addressable unit", and streaming in and out with standard tools ;-)
18:18:49 <rdrop-exit> There you go! :) That pesky outside world again.
18:19:13 <PoppaVic> yeah, if yer in a sealed up device/widget - go mad, baby.
18:22:03 <rdrop-exit> ASICs rule
18:56:55 --- quit: dave0 (Quit: dave's not here)
19:24:45 <rdrop-exit> Catch you all later, keep on Forthin'
19:24:54 --- quit: rdrop-exit (Quit: Lost terminal)
19:45:02 --- quit: dys (Ping timeout: 268 seconds)
20:02:38 --- join: gravicappa (~gravicapp@h109-187-219-53.dyn.bashtel.ru) joined #forth
21:10:47 --- quit: proteusguy (Remote host closed the connection)
21:24:40 --- quit: dddddd (Remote host closed the connection)
22:47:46 --- join: proteusguy (~proteusgu@mx-ll-180.183.129-217.dynamic.3bb.co.th) joined #forth
22:47:47 --- mode: ChanServ set +v proteusguy
22:49:38 --- join: dys (~dys@tmo-120-66.customers.d1-online.com) joined #forth
23:18:56 --- quit: dys (Ping timeout: 244 seconds)
23:22:43 --- quit: pierpal (Ping timeout: 268 seconds)
23:41:03 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
23:54:40 --- quit: pierpal (Quit: Poof)
23:55:01 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
23:59:59 --- log: ended forth/19.02.10