00:00:00 --- log: started forth/19.03.26
00:49:59 --- quit: proteusguy (Ping timeout: 245 seconds)
01:02:40 --- join: proteusguy (~proteusgu@mx-ll-180.183.100-61.dynamic.3bb.co.th) joined #forth
01:02:40 --- mode: ChanServ set +v proteusguy
01:23:41 --- join: xek (~xek@public-gprs411387.centertel.pl) joined #forth
01:24:53 --- quit: reepca (Ping timeout: 246 seconds)
02:04:05 --- quit: ashirase (Ping timeout: 246 seconds)
02:06:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:17:49 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
03:37:24 --- join: xek_ (~xek@user-94-254-233-114.play-internet.pl) joined #forth
03:40:05 --- quit: xek (Ping timeout: 250 seconds)
03:51:52 --- quit: proteusguy (Remote host closed the connection)
04:03:22 <WilhelmVonWeiner> shalom forth
04:26:33 --- quit: mtsd (Quit: leaving)
04:31:48 --- join: CORDIC (~user@91-150-102-155.dynamic.isp.telekom.rs) joined #forth
04:34:05 --- quit: DKordic (Ping timeout: 272 seconds)
05:26:22 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:40:26 --- quit: dave9 (Ping timeout: 255 seconds)
05:42:22 --- quit: dave0 (Ping timeout: 246 seconds)
05:48:05 <rdrop-exit> Good evening Forthwrights :)
05:55:23 --- join: dave9 (~dave@223.072.dsl.syd.iprimus.net.au) joined #forth
06:08:55 --- quit: dave9 (Quit: dave's not here)
06:09:31 --- join: dave9 (~dave@223.072.dsl.syd.iprimus.net.au) joined #forth
06:10:41 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:18:09 --- quit: mark4 (Remote host closed the connection)
06:19:04 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:23:09 --- quit: mark4 (Remote host closed the connection)
06:23:48 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:24:40 --- quit: mark4 (Remote host closed the connection)
06:32:12 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:52:39 --- quit: mark4 (Remote host closed the connection)
06:53:02 --- quit: tabemann (Ping timeout: 250 seconds)
06:53:14 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:58:03 <WilhelmVonWeiner> what's up
06:58:40 <zy]x[yz> chicken butt
06:59:27 <rdrop-exit> Napped most of the afternoon, still jet-lagged
06:59:57 <presiden> WilhelmVonWeiner, pixar movie
07:24:38 --- quit: xek_ (Read error: Connection reset by peer)
07:24:54 --- join: xek_ (~xek@user-94-254-233-114.play-internet.pl) joined #forth
07:48:45 --- quit: rdrop-exit (Quit: Lost terminal)
07:54:13 --- quit: xek_ (Ping timeout: 272 seconds)
08:10:22 <crc> I've completed my experiments in reducing retro's memory footprint. There are now functional configurations for 96kB, 128kB, 192kB, 256kB, 512kB, and 1024kB models.
08:11:36 <crc> No luck on getting this to work on a 64kB w/o losing parts of the standard image
08:11:38 <crc> http://forth.works/5435b9737e4a79de6a566d6a2e5101cd
08:19:40 --- quit: mark4 (Remote host closed the connection)
08:20:09 --- join: mark4 (~mark4@148.80.255.161) joined #forth
08:48:56 <WilhelmVonWeiner> interesting statss
08:49:28 <WilhelmVonWeiner> especially since the stdlib includes a lot that most mcu programmers could leave out
08:50:13 <WilhelmVonWeiner> though iirc retroforth isn't structured well to handle removing parts of the stdlib as it builds itself up using other bits doesn't it?
08:58:48 <crc> that is correct 
09:00:05 <crc> retro isn't really targetted at smaller mcu's :)
09:05:19 <mark4> crc when was the last time you heared from tcn
09:05:20 <mark4> ?
09:05:32 <mark4> i think he has retired from the computer industry 
09:05:46 <mark4> cant find anything about him except the old tunes page 
09:11:23 <WilhelmVonWeiner> I think for retro on mcu a fork from rx would be required
09:15:09 --- quit: mark4 (Remote host closed the connection)
09:15:44 --- join: mark4 (~mark4@148.80.255.161) joined #forth
09:17:27 <crc> mark4: ~2 years
09:17:43 <mark4> yea
09:17:54 <mark4> dropped off the face of the earth
09:19:46 <crc> it's been 3 years since he last read mail on the tunes server
09:24:09 --- quit: mark4 (Remote host closed the connection)
09:25:07 --- join: mark4 (~mark4@148.80.255.161) joined #forth
09:25:39 --- quit: mark4 (Read error: Connection reset by peer)
09:26:21 --- join: mark4 (~mark4@148.80.255.161) joined #forth
09:26:32 <crc> WilhelmVonWeiner: that would be best I think
09:27:09 --- quit: mark4 (Remote host closed the connection)
09:28:07 <crc> it might make sense to have a core extensions (the basic combinators, conditionals, etc) and move the data structure related words to a separate third stage extension file
09:46:41 <WilhelmVonWeiner> are prefixes handled by string words?
09:58:47 --- join: mark4 (~mark4@148.80.255.161) joined #forth
10:07:14 <crc> prefix:' uses a couple (for allowing the temporal string buffer), most of the string words could be moved out
10:10:04 --- quit: mark4 (Remote host closed the connection)
10:10:29 --- join: mark4 (~mark4@148.80.255.161) joined #forth
10:12:34 --- quit: mark4 (Remote host closed the connection)
10:24:13 <crc> WilhelmVonWeiner: a quick attempt at splitting things up yields a core image w/5409 cells (down from 9182) and 190 words (down from 302)
10:26:00 <crc> http://forth.works/53cdca49b2ab85d17aba2045e8cbd968
10:26:00 <crc>  for the word list
10:27:48 --- quit: nighty- (Quit: Disappears in a puff of smoke)
10:28:58 <crc> this could be reduced further; I could remove more of the `n:` words, some of the `v:` words, the assembler, some debug aids, and a loop combinator (`times<with-index>`).
10:38:10 <crc> But this is enough to make it usable on a 64kB machine, at the expense of the `array:` vocabulary, most of the string words, and a handful of others.
10:40:30 <crc> http://forth.works/7231a52ccac6e970cf41793173b9610c
10:40:30 <crc>  for the cut down stdlib if you want to see exactly what I cut for this quick test
10:44:49 <PoppaVic> https://pastebin.com/87HMMVhq
11:02:49 <PoppaVic> Yep. I think I can live with that.
11:05:09 <PoppaVic> https://pastebin.com/Edshmb7j
12:11:22 <crc> what is tinyu, ?
12:12:11 <PoppaVic> tiny literal: 4 comtrol codes in the uper few bits. it uses the space an opcode would occupy for small relative zgoto
12:12:35 <PoppaVic> sorry, zgoto uses the same data-bits - tinyu is literally a small literal
12:13:04 <PoppaVic> so, you can push the usual literals for a byte for 0..63
12:14:47 <crc> ok
12:14:50 --- quit: gravicappa (Ping timeout: 246 seconds)
12:15:01 <PoppaVic> crc: I got sorta' pissed that we wasted so much space for silly ass zero, one, two - and plus/minus variants
12:18:37 <crc> heh, literals are a full cell, plus an instruction slot on my system
12:18:53 <PoppaVic> yeah, I have those as well, but I avoid using them
12:34:29 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
12:34:30 --- join: reepca (~user@208.89.170.37) joined #forth
12:35:31 <dave0> hi
12:38:10 <crc> hi dave0 
12:39:55 <dave0> hi crc 
12:51:45 --- quit: chunkypuffs (Remote host closed the connection)
12:54:06 <KipIngram> Hi dave0.
12:54:29 <dave0> hi KipIngram 
12:54:52 <dave0> got coffee? C4[_]~ C8[_]~ C3[_]~ C2[_]~
12:55:05 <KipIngram> :-)
12:55:12 <KipIngram> I had some this morning.
13:32:36 --- join: chunkypuffs (~chunkypuf@znc.gamecu.be) joined #forth
14:17:40 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
14:20:50 --- quit: MrMobius (Ping timeout: 246 seconds)
14:20:50 --- nick: [1]MrMobius -> MrMobius
15:54:51 <presiden> crc, the forth.works frontpage linked the latest snapshot to http://forthworks.com/r/latest.tar.gz which has no content in it
16:07:51 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
16:22:10 --- quit: dave0 (Quit: dave's not here)
16:33:23 <crc> I'll fix that
16:34:16 <zy]x[yz> it's not a bug, it's just highly optimized
16:36:06 <crc> done :)
16:37:18 <presiden> crc, also, I can't seems to compile the latest version, it complained about undefined reference to round, floor, ceil, etc.
16:46:11 <tabemann> I'm amused that the leading Brexiteers call themselves the "Grand Wizards"
16:56:09 <presiden> the Makefile.linux helps I guess
17:21:11 <crc> gnu ld has some odd requirements far the order of libraries and object fules in some versions
17:27:39 --- quit: john_cephalopoda (Ping timeout: 268 seconds)
17:29:28 <zy]x[yz> yeah
17:40:49 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:48:16 --- quit: tabemann (Ping timeout: 246 seconds)
17:58:40 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
17:59:17 <rdrop-exit> Greetings Forthlings c[_]
18:13:40 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
18:23:37 <Croran_> : exit? ( bool -- ) if exit then ;
18:23:41 <Croran_> what do you think of my word?
18:24:37 <rdrop-exit> I call that ?;
18:25:07 <Croran_> ah interesting
18:25:18 <rdrop-exit> I expect a FOO? word to return a flag
18:26:08 <PoppaVic> Croran_:   : ?exit ...
18:26:32 <PoppaVic> and, btw - BOOL isn't very likely ;-P
18:27:24 <Croran_> not very likely? I'm still a beginner, so not sure I understand.
18:28:11 <PoppaVic> it's a cell (even if a char) - and the normal use would be 0 is false, anything else is true.
18:28:32 <PoppaVic> don't get tangled up in BOOL from elsewhere
18:29:14 <rdrop-exit> or if the word returns a well-formed flag then -1|0 e.g.
18:29:43 <PoppaVic> yeah, after you type that a few times you decide ( ? --) flies well ;-)
18:30:03 <rdrop-exit> immediate? ( la -- -1|0 )
18:30:16 <Croran_> ah ok
18:30:46 <Croran_> I still get my stack effect comment abbreviations mixed up
18:31:07 <rdrop-exit> Everyone one has their own style
18:31:21 <Croran_> seems like people do a lot of different things. 'n' makes sense, but i like to say more what it is sometimes
18:31:38 <Croran_> like 'nmultiplicand' or whatever
18:32:08 <Croran_> and 'f' for flag vs 'r' for float seems dumb
18:32:25 <rdrop-exit> pi ( -- numerator denominator )
18:33:09 <Croran_> where the umerator is a signed integer and the enominator is a signed double-cell int?
18:34:35 <rdrop-exit> In my case it's their both single cells, either unsigned or signed will work
18:35:22 <rdrop-exit> I usually use u for unsigned, n for signed, x for arbitrary cell
18:35:34 <Croran_> makes sense
18:35:44 <rdrop-exit> I also use # for counts
18:36:58 <rdrop-exit> +n for positive signed, and -n for negative signed is also common
18:37:54 <rdrop-exit> Whatever works
18:38:13 <rdrop-exit>  : cancel ( {x1 x2}|{x1 x1} -- x1|0 ) over <> and ;inline
18:39:16 <rdrop-exit> abs ( n -- +n|mnn )
18:39:50 <Croran_> what's the |mnn ? or something?
18:40:05 <rdrop-exit> mnn for most negative integer, mpn for most positive integer
18:40:30 <rdrop-exit> most negative number
18:40:58 <Croran_> hmm. something to do with edge cases for the single precision limit?
18:41:16 <rdrop-exit> In 2's complement the absolute value of the most negative number is itself
18:42:19 <Croran_> ...so if you make a simple abs word, you can potentially still output a negative number
18:42:40 <rdrop-exit> Yes
18:43:55 <rdrop-exit> That's why it's often more useful to use the negative absolute value which doesn't overflow
18:44:15 <rdrop-exit> nabs ( -n|+n -- -n )
18:46:13 <rdrop-exit> https://en.wikipedia.org/wiki/Two's_complement
18:47:01 <rdrop-exit> : abs ( n -- +n|mnn ) nabs negate ;inline
18:47:11 <rdrop-exit> : abso ( n -- +n ) abs  dup 0>= averts xovf ;
18:47:26 <rdrop-exit> abso Positive absolute value, raise |xovf| on overflow.
18:49:14 <Croran_> ah ok. or you could add an exception to your abs word to throw an error instead of a negative value, right?
18:50:13 <rdrop-exit> That's what I just posted, I call it ABSO
18:50:33 <Croran_> oh got it
18:50:43 <rdrop-exit> i.e. absolute value with overflow check
18:51:09 <rdrop-exit> But in most cases I prefer to use the negative absolute value
18:54:24 <rdrop-exit> You have the same phenomenon when you negate the most negative number, the result is itself
18:55:22 <Croran_> "r@ exit" would exit both the current word and the word that called the current word?
18:56:15 <Croran_> rather "r> exit"
18:56:43 <rdrop-exit> Yes
18:57:28 <rdrop-exit> although you'd have the address on the data stack if you did it that way
18:57:58 <rdrop-exit> "rdrop exit"
18:58:17 <Croran_> great
18:58:33 <rdrop-exit> I call that BAIL;
18:58:59 <rdrop-exit> bail; ( -- )( r: a x -- )
18:59:23 <Croran_> updated my word.
18:59:25 <Croran_> : ?; ( f -- ) IF RDROP EXIT THEN ;
18:59:55 <rdrop-exit> Not the same thing
19:00:18 <rdrop-exit> In my case ?; would be equivalent to "if  exit  then"
19:00:44 <Croran_> but that only exits the current word, so... isn't your ?; ineffective?
19:00:46 <rdrop-exit> Your's exits its caller, one extra level
19:01:19 <Croran_> like, it exits itself
19:01:43 <rdrop-exit> Yes
19:01:56 <Croran_> regardless of whether the condition is met
19:02:15 --- join: tabemann (~tabemann@2600:1700:7990:24e0:35d8:344b:3716:9530) joined #forth
19:02:26 <rdrop-exit>  : sustain ( -- ) #pending ?;  await  retain ; compiled
19:02:53 <rdrop-exit> Early exit
19:02:58 <rdrop-exit> on condition
19:03:11 <Croran_> huh. well it didn't work that way for me.
19:04:25 <rdrop-exit> Because mine is equivalent to "if exit then" from the word it's called from
19:04:47 <Croran_> https://pastebin.com/aZn6jAmk
19:04:51 <rdrop-exit> It's a primitive, your ?; is a secondary
19:05:00 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
19:05:03 <rdrop-exit> so you need the extra rdrop
19:05:34 <Croran_> oh ok
19:06:05 <rdrop-exit> I should have explained more clearly, sorry
19:06:22 <dave0> re
19:06:31 <Croran_> it's good. i'm learning :)
19:07:11 <rdrop-exit> Yours is correct as a secondary
19:07:55 <Croran_> thanks
19:07:56 <rdrop-exit> Mine is ?; ( x|0 -- )( r: a -- |a ) 
19:08:42 <rdrop-exit> as a primitive
19:09:22 <rdrop-exit> brb
19:10:59 * tabemann remember being told that he had a lot of primitives - yet he included nothing of this sort in hashforth's VM
19:13:07 <rdrop-exit> To be more precise in my host Forth it's a VM instruction rather than a primitive, all my words are primitives in a way since I use subroutine threading above the VM
19:13:53 <rdrop-exit> (and inlining also)
19:15:27 <rdrop-exit> There are really 3 levels in a Forth, the instructions of the underlying cpu, primitives, and secondaries
19:16:17 <rdrop-exit> It gets confusing in a VM Forth since there's an extra level:
19:16:43 <rdrop-exit> instructions of the real machine, instructions of the virutal machine, primitives, secondaries
19:17:34 <rdrop-exit> not to mention the choice of threading machanism
19:17:56 <rdrop-exit> * mechanism
19:20:19 <tabemann> so in your forth you implement ?; with multiple VM instructions
19:20:50 <tabemann> even though it's a primitive
19:21:30 <rdrop-exit> No (in my host Forth) it's an opcode of the VM, so it's a VM instruction to be precise
19:21:40 <tabemann> got it
19:22:00 <rdrop-exit>  $ 6f bytecode ?; ( x|0 -- )( r: a -- |a ) compiled
19:22:22 <tabemann> see I don't have VM instructions/primitives that are that specialized
19:22:23 <rdrop-exit> Currently it's instruction 6f (in hex)
19:22:53 <tabemann> e.g. I don't even have rdrop as a VM instruction/primitive
19:23:53 <rdrop-exit> This particular VM uses bytecodes so I have up to 256 instruction slots
19:25:39 <rdrop-exit> It's CISC-ish in a way, since on a VM I want each instruction to do a lot of "work"
19:27:21 <rdrop-exit> And bytes are a natural addressable unit on a VM
19:27:39 <tabemann> yeah, I've got a total of 56 primitives at the present
19:28:32 <rdrop-exit> I wouldn't necessarily design a real chip this way, but it simplifies things for a virtual chip
19:30:51 <rdrop-exit> tabemann: when you say 56 primitives, do you actually mean 56 VM instructions?
19:31:25 <tabemann> yes
19:31:34 <rdrop-exit> Got it, thanks
19:32:10 <tabemann> the thing is that I remember some people mentioning that their forths had even fewer VM instructions than hashforth
19:32:32 <tabemann> mine is a bit inflated because I have separate = and <>, < and >, and so on
19:33:13 <tabemann> because it felt like little would be gained in reducing it further than it already has been
19:33:31 <rdrop-exit> If their VM is a virtual version of a real stack machine (such as one of Chuck's) it's not surprising that they'd have few instructions
19:34:15 <rdrop-exit> The tradeoffs are different on a virtual machine compared to a real machine
19:34:44 <tabemann> aside from having PICK and ROLL, the hashforth VM is a stack machine
19:36:01 <rdrop-exit> In my VM the stacks are not in addressable memory, their part of the register space of the VM "chip"
19:36:11 <rdrop-exit> * they're
19:38:00 <tabemann> in hashforth stacks are deliberately part of addressable memory, because stacks can be directly manipulated by code so as to enable multitasking without putting multitasking in the VM
19:38:33 <tabemann> the hashforth VM knows nothing about the multitasking engine, which it would have to if there was not SP@, RP@, SP!, and RP!
19:39:21 <rdrop-exit> Right, I remember you mentioning this, your stacks are in VM "RAM"
19:40:48 <tabemann> there are compromise implementations that are possible - e.g. stacks normally exist in register space, but SP@ and RP@ write them out to RAM, and SP! and RP! read them in from RAM - but these have their own costs design-wise
19:41:53 <rdrop-exit> I went completely non-standard with my stacks, they're in the VM's register space as opposed to it's "RAM", and they're circular.
19:42:36 <rdrop-exit> As they say when you've seen one Forth, well you've seen one Forth
19:44:19 <tabemann> with hashforth I made my data stack be the next thing above my user space, so if you allocate 16 MB for hashforth, in theory the data stack could take up 16 MB - minus the space needed for loading code and minus the space for the return stack
19:44:50 <tabemann> well, that's just the main thread
19:44:51 * PoppaVic chuckles
19:44:56 <PoppaVic> still true, decades later
19:45:02 <rdrop-exit> I still don't get what your "user space" thing is
19:45:16 <tabemann> the space that ALLOT points to the top of
19:45:22 <tabemann> *HERE
19:45:36 <tabemann> and ALLOT changes the pointer to HERE for
19:45:38 <rdrop-exit> Ah, the dictionary
19:45:59 <tabemann> well, I use it for far more than just the dictionary
19:46:16 <rdrop-exit> DP is the dictionary pointer
19:46:33 <tabemann> e.g. when tasks are created, their stacks and user spaces are allocated within this space in memory
19:46:38 <rdrop-exit> HERE is DP @
19:47:29 <rdrop-exit> Ok, I think you just use different terminology
19:47:48 <rdrop-exit> brb
19:53:01 <rdrop-exit> Normally there no allocation involved in a Forth (at least at a low level) just allot-ment
19:54:50 <tabemann> I implemented a service for ALLOCATE (and one for RESIZE and one for FREE) largely so I could get my resizable buffer code from attoforth working, but other than that I've relied solely on ALLOT
19:54:59 <rdrop-exit> Even in "standard" Forth allocate is an optional extension
19:55:13 <tabemann> yes
20:00:43 <rdrop-exit> My host VM's memory is the dictionary then storage.
20:01:19 <rdrop-exit> i.e. block storage
20:01:35 <rdrop-exit> 0 preamble  Host VM RAM  2|2
20:01:36 <rdrop-exit> 1
20:01:36 <rdrop-exit> 2                     VM Memory Map
20:01:36 <rdrop-exit> 3         0 ->+----------------------------+
20:01:36 <rdrop-exit> 4             |        Dictionary          |^
20:01:38 <rdrop-exit> 5             |                            || #reserved
20:01:40 <rdrop-exit> 6             |                            |v
20:01:43 <rdrop-exit> 7             |                            |
20:01:45 <rdrop-exit> 8             |                            |
20:01:48 <rdrop-exit> 9             |                            |
20:01:50 <rdrop-exit> a   STORAGE ->+----------------------------+
20:01:53 <rdrop-exit> b             |      Storage Blocks        |
20:01:55 <rdrop-exit> c             |                            |
20:01:58 <rdrop-exit> d             |                            |
20:02:00 <rdrop-exit> e     limit ->+----------------------------+
20:02:03 <rdrop-exit> f
20:02:50 <rdrop-exit> The reserved area at the beginning of the dictionary has boot and trap vectors and such.
20:03:56 <rdrop-exit> Not drawn to scale of course :)
20:06:16 <rdrop-exit> Need more cofee, brb
20:08:59 <rdrop-exit> c[_]~~ back
20:11:37 <rdrop-exit> The approach I've taken in my host Forth is only suitable to host machines, wouldn't use it on target.
20:11:54 <rdrop-exit> * on a target.
20:12:39 <rdrop-exit> STORAGE is a metacompilation constant (that's why it's in uppercase).
20:35:48 <rdrop-exit> Have to walk the dogs, catch you all later. Keep on Forthin' :)
20:35:56 --- quit: rdrop-exit (Quit: Lost terminal)
21:06:46 --- join: gravicappa (~gravicapp@h37-122-117-136.dyn.bashtel.ru) joined #forth
21:23:13 --- quit: dddddd (Remote host closed the connection)
21:24:42 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
23:00:02 --- join: proteusguy (~proteusgu@mx-ll-180.183.100-61.dynamic.3bb.co.th) joined #forth
23:00:02 --- mode: ChanServ set +v proteusguy
23:31:15 --- quit: jedb (Remote host closed the connection)
23:37:34 --- quit: proteusguy (Remote host closed the connection)
23:38:48 --- join: proteusguy (~proteusgu@mx-ll-180.183.100-61.dynamic.3bb.co.th) joined #forth
23:38:48 --- mode: ChanServ set +v proteusguy
23:39:09 --- join: jedb (~jedb@185.128.24.51) joined #forth
23:57:00 --- quit: rdrop-exit (Ping timeout: 250 seconds)
23:59:59 --- log: ended forth/19.03.26