00:00:00 --- log: started forth/18.11.07
00:19:31 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
00:24:28 --- quit: dys (Ping timeout: 252 seconds)
01:20:20 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
01:46:56 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
01:57:11 --- quit: ashirase (Ping timeout: 244 seconds)
01:59:07 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:03:39 --- quit: ashirase (Ping timeout: 268 seconds)
02:07:32 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:19:55 --- quit: wa5qjh (Ping timeout: 246 seconds)
02:25:08 --- quit: proteusguy (Ping timeout: 240 seconds)
02:27:12 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
02:48:26 --- join: proteusguy (~proteus-g@cm-134-196-84-236.revip18.asianet.co.th) joined #forth
02:48:26 --- mode: ChanServ set +v proteusguy
02:56:48 --- quit: pierpal (Quit: Poof)
02:57:07 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
03:00:39 <KipIngram> rdrop-exit: It was really SCAN that I was puzzling over.
03:02:34 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
03:06:00 <KipIngram> SKIP accepts a pointer to the next input character and the ASCII byte to skip over.  It moves that pointer to just past the final copy of that character and replaces the character with a count of how many copies it found.
03:07:39 <KipIngram> SCAN receives a pointer to the next input character and an ASCII char to look for - it moves the pointer such that it points to the next instance of that character in the input stream and also returns a count of how many characters it scanned over.
03:07:50 <KipIngram> Previously, it did not scan over the matching termination char.
03:08:17 <KipIngram> What I now have it doing it leaving the address pointing to that char, but the count it returns is one greater, indicating that it scanned PAST that matching char.
03:08:50 <KipIngram> In my usage of these things the pointer addresses that come out of each of those are actually used to identify a parsed word, while the counts are used to update >IN, the input pointer.
03:09:24 <KipIngram> So now I do not consider SCAN's terminal matching char to be part of the content copied to the word buffer, but I do move the input pointer past that char.
03:09:33 <KipIngram> That turns out to be the cleanest approach.
03:10:18 <KipIngram> I definitely don't want SCAN's termination char to be part of scanned out words.  If it was, all of my words would wind up with a trailing space.
03:10:31 <KipIngram> But I do want to move past that char in the input stream.
03:10:54 <KipIngram> It didn't really matter whether I did or not when I was parsing words and the character stopped on was a space - I skip over spaces when parsing the next word anyway.
03:11:24 <KipIngram> But it mattered when trying to define : ( 41 WORD ; - the old way left the ) in the input stream; the new way does not.
03:12:03 <KipIngram> So now that def, : (  41 WORD DROP ; (it needs the DROP because my word returns the address of the word buffer) works correctly.
03:21:38 <KipIngram> So anyway, the right way for me to think about both of those two words is that each has a character it looks for, and each moves the input pointer PAST that character.  SKIP moves past a bunch of them - SCAN moves over non-matches and past the first match.
03:22:01 <KipIngram> But SKIP also moves the pointer PAST last matched charhacter, whereas scan moves the pointer TO the matched char.
03:24:30 --- join: wa5qjh (~quassel@175.158.225.210) joined #forth
03:24:30 --- quit: wa5qjh (Changing host)
03:24:30 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
03:24:58 <john_cephalopoda> The next round of my Mandelbrot set is nearly done.
03:25:07 <john_cephalopoda> Here is round 3: https://thecutecuttlefish.org/tmp/example3.jpg
03:25:45 <KipIngram> Oh, that's really nice looking, John.
03:26:07 <cheater> yea i like it as well
03:26:32 <KipIngram> Do you have an explicit bignum package going there, or are these "rounds" pushing up the number of digits you're carrying?
03:27:05 <rdrop-exit> I've drifted so far from the tradition FIG/Forth-83 input processing that I forget how it was done.
03:27:28 <KipIngram> Right - I'm not really concerned with adhering to the standard.
03:27:39 <KipIngram> I'm just looking for what's clean / terse / concise.
03:27:41 <rdrop-exit> My starting point was originally based on LaForth's input processing.
03:28:02 <KipIngram> I started out with FIG, back in the day, and have drifted my own course from there.
03:28:23 <john_cephalopoda> Next one! https://thecutecuttlefish.org/tmp/example4.jpg
03:28:40 <rdrop-exit> I process each character through a keymap, and process tokens at delimiters rather than waiting for a whole line of input.
03:29:35 <KipIngram> Yeah, I've thought about doing that.  Are you able to do any line editing at all, or is each character irrevocable once you've keyed it?
03:29:41 <rdrop-exit> As soon as you hit space or enter, the word is interpreted (or compiled as the case may be).
03:30:05 <KipIngram> Yes, I think I got the impression that the path Chuck took.
03:30:22 <KipIngram> Though I often have to read Chuck's stuff several times to really get it.
03:30:35 <rdrop-exit> No line editing, but editing the current token before the delimiter is entered is still possible.
03:30:37 <KipIngram> He's a genius, I think, but his prose isn't always the most "immediately clear."
03:30:56 <KipIngram> Ok, so backspace can work within each word?
03:31:03 <rdrop-exit> yes
03:31:24 <KipIngram> I bet that winds up being more compact code that what I have.
03:31:38 <KipIngram> I invested a fair bit of effort in line editing, command history, etc.
03:31:57 <KipIngram> Though I think it's not "unnecessarily" complex.  Just a certain amount of work has to be done to support that.
03:32:05 <rdrop-exit> I have command history in a circular buffer.
03:32:17 <KipIngram> History of words or lines?
03:32:28 --- quit: mtsd (Ping timeout: 240 seconds)
03:32:34 <rdrop-exit> History of input.
03:32:48 <KipIngram> Mine's circular buffer based as well.
03:33:09 <KipIngram> Originally that was a heap page, but then I wanted to make the heap pages smaller, so I made it (for now) a separate buffer allocated at start-up.
03:33:17 <KipIngram> Ultimately I think I'm going to make it disk-resident.
03:33:34 <KipIngram> That'll make the command history persistent across sessions.
03:33:48 <rdrop-exit> My whole Forth is persistent.
03:34:22 <rdrop-exit> At least the Host Forth on the PC.
03:34:28 <KipIngram> Oh, that's interesting.
03:34:35 <KipIngram> How do you do a full reset?
03:35:12 <rdrop-exit> Even the source blocks are part of the image.
03:35:18 <KipIngram> Aka COLD?
03:36:17 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03:36:33 <rdrop-exit> I have a warm reset that puts you back to where you were when you last shut down, and also a cold boot.
03:36:47 <KipIngram> Mine consists of a startup code image that is in read-only-protected RAM.  COLD initializes a heap, allocates a couple of pages from that, and "sets up" those pages as an initial process structure.  All the initial system variables and process variables get set then.
03:37:38 <rdrop-exit> My warm boot brings you back to where you where, even if you were in the middle of a block editing session.
03:37:58 <KipIngram> Interesting.  My WARM just clears both stacks and restarts the interpreter.
03:38:20 <KipIngram> COLD just jumps to the startup code so the heap gets reinitialized and the one starting process re-created.
03:38:36 <KipIngram> QUIT just clears the return stack but leaves the data stack alone.
03:38:42 <KipIngram> And restarts the interpreter.
03:39:00 <rdrop-exit> My stacks are circular.
03:39:10 <KipIngram> Yeah, I remember you mentioning that.
03:39:28 <rdrop-exit> Although I don't restore the stack content when I bring up the image.
03:39:58 <KipIngram> My COLD/WARM/QUIT approach still is quite close to FIG.
03:40:32 <KipIngram> My main departure from FIG right now, other than small details, is that I don't store name strings in the dictionary.
03:40:47 <KipIngram> I have a system-wide symbol table that also will eventually be disk resident.
03:41:03 <KipIngram> The right way to think of it is as a one-to-one mapping between symbol strings and integers.
03:41:15 <KipIngram> Then I store those integers in the dictionaries.
03:41:35 <KipIngram> The motivation for all that is to eventually support a compressed source representation.
03:41:50 <rdrop-exit> My dictionary is combined.
03:41:56 <KipIngram> Commonly used words will go in the first 127 entries of the symbol table, and I'll be able to represent those words in the source with a single byte.
03:42:07 <KipIngram> Then up to 8k words in two bytes, etc.
03:42:25 <KipIngram> I'm expecting an effective compression of around 5-6.
03:43:00 <rdrop-exit> Right, I don't have a pressing need for compression since my Forth setup is umbilical.
03:43:11 <KipIngram> I think that colorForth did some things like that, and I'm more sure that Jeff Fox's "Aha" implementation did a similar thing.
03:43:41 <rdrop-exit> If I want to save space on a target, I can just store the source and headers for it on the host.
03:43:41 <KipIngram> I'm wanting to be able to run fully on things like this little Cortex M4 board I have - it has 512k of flash.
03:43:59 <KipIngram> With 5-6 compression that'll get me 2.5M to 3M of "effective source space."
03:44:43 <rdrop-exit> I don't plan on storing headers on targets.
03:44:58 <KipIngram> I initially also hoped to capture the colorForth / Aha "super fast compilation" ideas, but after dancing around that area for quite a while I decided it would be pretty hard to pull off while still supporting vocabularies and multiple processes.
03:45:05 <rdrop-exit> or source for that matter, they both stay on the host Forth.
03:45:08 <KipIngram> Anything that let the same symbol have different meanings in different places.
03:45:31 <KipIngram> Right - I have an acquaintance who's heavily interested in tethered type systems, so I've thought around that area a good bit.
03:46:34 <KipIngram> I'm guessing a driving design priority for you is winding up with the most compact possible "target systems."
03:46:58 <KipIngram> When you're compiling, how do you toggle between "host words" and "target words"?
03:47:32 <rdrop-exit> Exactly, for most targets, I wouldn't even put a Forth, I'd just use my host Forth as a cross-assembly IDE.
03:48:00 <KipIngram> Oh, I see.  So you'd go straight to machine code on the target?
03:48:50 <rdrop-exit> Interactive cross-assembly, yes, I would only put a Forth on the target if the target was large and the Forth was necessary for some reason.
03:49:36 <KipIngram> Ok.  My friend wants a Forth on the target too, to capture Forth's space-saving features.  But not a full interpreter.
03:49:42 <rdrop-exit> I'd just have the serial monitor program, similar to the Sargeant's 3-instruction Forth.
03:49:58 <KipIngram> Yeah, I've read that paper.
03:50:10 <KipIngram> It really did look like a super-simple way to approach "bring-up."
03:51:23 <rdrop-exit> If I need a very compact full Forth on the target, I'd cross-compile a TTC Forth. If I need speed then a SRT/NC Forth. If I don't need a Forth on the target then just the monitor and machine code.
03:51:42 <KipIngram> I've been 100% happy with the "cleanliness" of my system.  Just recently, though, when I decided I wanted to reduce the size of my heap pages, making my error recovery system work in that context injected a bit of complexity that I'm not terribly happy with.
03:52:07 <KipIngram> Now as processes compile code they can expand beyond a single heap page, so I made them able to allocate new pages when necessary for continued growth.
03:52:25 <KipIngram> And the gist of my error recovery is that I save a copy of the process image before interpreting each line.
03:52:34 <KipIngram> So that caused me to need those heap pages to be in a linked list.
03:52:49 <rdrop-exit> Sounds complicated.
03:53:01 <KipIngram> It's not THAT bad, but yes, it did complicate things to some extent.
03:53:14 <KipIngram> So I may work on that part of things some at some point.
03:53:43 <KipIngram> The heap itself is very simple - it's not a "real" heap such as you usually read about.
03:53:57 <KipIngram> It allocates fixed-size pages, so needs no garbage collection or anything like that.
03:54:22 <KipIngram> Just has a base address, a "highest unused" address, and a free list pointer.
03:54:27 <KipIngram> Very fast.
03:55:12 <KipIngram> The linked list requriement added a layer on top of that, though - the raw stuff allocates a page, and the additional layer uses the first two cells of the page to make the linked list.
03:55:21 <KipIngram> Returns the address just after those to the user.
03:55:33 <KipIngram> So this annoying bit of complexity is nicely "hidden away" at least.
03:56:02 <KipIngram> Having the procoesse grow into new pages went quite well - that part doesn't bother me.
03:56:10 <rdrop-exit> My host image is fixed sized, and I just work within that.
03:56:27 <KipIngram> That's how I was initially thinking of each process.
03:56:50 <KipIngram> I have tons of RAM on this Mac; I was using 64k heap pages and just figuring no one process would ever outgrow its page.
03:57:17 <KipIngram> It was wasteful, but consciously so.  Then the desire to work on that Cortex target made that not completely acceptable.
03:58:11 <rdrop-exit> On the PC I use a VM approach. The VM is a separately compiled executable that contains the memory, stacks, and VM registers.
03:58:39 <rdrop-exit> When it starts up it loads a dictionary+blocks image from disk.
03:59:14 <rdrop-exit> ... into the VM memory.
03:59:33 <KipIngram> Right.
04:00:32 <rdrop-exit> The VM memory size is baked into the VM executable. If for some reason I need a larger memory, I would compile another VM.
04:01:55 <KipIngram> Yes.  I do a similar thing to give my system "working memory."  There's just a big "reserve bytes" directive at the end.
04:02:14 <KipIngram> There's nothing in here that gets more RAM from the OS while operating.
04:02:53 <KipIngram> To me that seems equivalent to having an embedded system with a fixed amount of RAM.
04:03:21 <rdrop-exit> Exactly, except my blocks are also in memory.
04:04:03 <rdrop-exit> I have a metacompiler constant, STORAGE, that sets the starting address for the blocks.
04:04:51 <rdrop-exit> When I SAVE, a snapshot of the entire dictionary image is saved to disk.
04:05:00 <KipIngram> Yes, makes sense.  
04:05:26 <KipIngram> The very first Forth I ever wrote was on a TRS-80 Color Computer.  I'd expanded it to 64k; I treated the top 32k as 32 1k blocks.
04:05:30 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:1ec6:932f:1b02:d27e) joined #forth
04:05:30 --- quit: ncv (Changing host)
04:05:30 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
04:05:41 <rdrop-exit> The source code is part of the dictionary image.
04:05:42 <KipIngram> Loaded the whole thing from tape - could save a copy whenever I wanted to.
04:06:04 <rdrop-exit> : block ( blk# -- a ) k STORAGE + ;inline
04:06:35 <rdrop-exit> That's my BLOCK word it multiplies blk# by 1024 and adds STORAGE to it.
04:07:51 <KipIngram> Right - that was readable; I grokked.
04:08:14 <rdrop-exit> STORAGE is all uppercase, that's my convention for metacompilation constants.
04:09:28 <rdrop-exit> The OS will take care of paging in blocks anyway, so no need for a true block subsystem.
04:11:34 <rdrop-exit> The above is only applicable to the host Forth.
04:11:39 <KipIngram> Right.  I do want to work on bare metal targets, so I have to handle those things myself.
04:11:43 <KipIngram> Yes.
04:11:47 <KipIngram> Makes total sense.
04:12:28 <rdrop-exit> Right, different story on targets.
04:13:00 <rdrop-exit> For me the host and target are two very different worlds.
04:13:42 <rdrop-exit> Things I do on the host I would never do on a target.
04:14:20 <rdrop-exit> I should have prefaced that last sentence with "There are..."
04:16:15 <KipIngram> :-)
04:16:59 <rdrop-exit> In a sense the host Forth is really an IDE for cross-assembly/cross-compilation to targets.
04:17:17 <rdrop-exit> It isn't a general purpose Forth.
04:17:41 <KipIngram> Right.  Considerations like that can drive designs in really different directions.
04:17:54 <KipIngram> I want mine to be able to function as a full OS on small targets.
04:18:04 <KipIngram> Fully self-contained.
04:19:06 <rdrop-exit> Sure, but if you have an umbilical setup you can always use it to produce a full self-contained Forth for a target.
04:20:13 <rdrop-exit> That's what I like about umbilicals, it can be used for producing all types of target systems.
04:20:49 <rdrop-exit> From a few bytes of machine code to a full fat target Forth.
04:22:06 <john_cephalopoda> I'm benchmarking gforth vs. pforth with my mandelbrot set thingie right now.
04:22:30 <rdrop-exit> cool
04:22:33 <rdrop-exit> brb
04:23:56 <KipIngram> Ah, which one's winning?
04:24:35 <KipIngram> If I had to guess I'd guess GForth - I'd at least hope that given the amount of energy the GForth guys have put into performance optimization.
04:26:30 <john_cephalopoda> pforth took 3m22.107s | gforth took 1m26.572s
04:26:42 <rdrop-exit> SWMBO is home, gotta go, chat again soon. Take care guys.
04:27:11 --- quit: rdrop-exit (Quit: Lost terminal)
04:27:42 <john_cephalopoda> https://thecutecuttlefish.org/tmp/pforth.jpg | https://thecutecuttlefish.org/tmp/gforth.jpg
04:27:45 <john_cephalopoda> The images are identical
04:28:07 <john_cephalopoda> md5 checks out.
04:29:01 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.)
04:47:49 <siraben> Looks stretched though.
04:48:17 <siraben> Ah he left the room, I should try again later.
04:54:38 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
04:54:55 <john_cephalopoda> Back
04:56:04 <siraben> Was gonna say
04:56:04 <siraben> It looks stretched
05:16:56 --- quit: pierpal (Quit: Poof)
05:17:12 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
05:29:49 <KipIngram> John: that Gforth vs. pforth outcome seems just right to me - it's what I would have expected.
05:30:01 <KipIngram> Does pforth really get any real maintenance and updates these days?
05:30:06 <KipIngram> GForth definitely does.
05:30:20 <john_cephalopoda> I wonder where exactly the overhead comes from in pforth.
05:31:09 <john_cephalopoda> The pforth I used was updated May 3, 2018
05:31:13 <KipIngram> Well, it's fully written in C, right?
05:31:45 <john_cephalopoda> Yeah, I think so. Although some stuff is written in Forth.
05:31:47 <KipIngram> Also GForth has done some interesting things on the register usage front, the decisions about when to inline and when not to, etc.
05:31:53 <john_cephalopoda> The gforth I used is from 2014-07-09
06:13:03 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
06:27:31 --- quit: dddddd (Remote host closed the connection)
07:01:20 --- quit: ncv (Remote host closed the connection)
07:01:42 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
07:01:42 --- quit: ncv (Changing host)
07:01:42 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
07:05:32 --- quit: dave0 (Quit: dave's not here)
07:21:36 --- quit: ncv (Remote host closed the connection)
07:23:08 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
07:32:12 --- quit: tabemann (Ping timeout: 260 seconds)
08:26:58 <john_cephalopoda> Hmm, "register usage" gives me an idea.
08:27:15 <john_cephalopoda> In theory, the registers could be used as part of the stack.
08:28:42 <john_cephalopoda> DUP would take longer since several values have to be copied around, but doing an operation like +, -, *, /, SWAP, ROT and so on would be WAY faster.
08:32:52 <KipIngram> Yes, that's exactly the idea.
08:33:06 <KipIngram> It's pretty much standard practice to cache at least one stack element in a register.
08:33:20 <KipIngram> I read a paper once, though, that the GForth guys wrote, where they studied caching more.
08:33:51 <KipIngram> It doesn't provide nearly as much payoff (if any) unless the compiler becomes smart enough to allow "variable association" of registers to stack elements.
08:34:18 <KipIngram> For example, if element 1 is in R1 and element 2 is in R2, and you execute SWAP, the compiler can just flip that assignment and compile NOTHING.
08:34:30 <KipIngram> So SWAP becomes a run-time zero cost operation.
08:34:51 <john_cephalopoda> Woah, nice optimisations.
08:34:55 <KipIngram> But to make that work you usually need multiple copies of a lot of primitives (one for each register assignment) and the compiler selects the right one.
08:35:02 <KipIngram> It's probably easier to do if you are actually generating code.
08:35:14 <KipIngram> Yeah, clever.  A good bit of work, though.
08:35:25 <KipIngram> I cache the top element like everyone else, and just left the rest of that stuff on the table.
08:35:41 <KipIngram> I figure 99% of my code won't be that performance critical, and the bits that are I can optimize in assembly if necessary.
08:35:52 <KipIngram> It's "intellectually" very interesting, though.
08:39:51 <john_cephalopoda> Interesting: http://www.ultratechnology.com/ModernForthCompilerBenchmarks.htm
08:40:11 <john_cephalopoda> KipIngram: Is your Forth available somewhere?
08:42:07 <john_cephalopoda> Oh, right, I asked before.
08:42:22 <john_cephalopoda> Back then you said you'd maybe open source it eventually.
08:49:42 <KipIngram> Right - I want to get it further along.
08:49:49 <KipIngram> Otherwise other people will be finishing it before I do.  8-D
08:50:09 * KipIngram isn't the most "high output" programmer around, by a long shot.
09:02:37 --- quit: proteus-guy (Ping timeout: 260 seconds)
09:14:16 --- join: proteus-guy (~proteusgu@2403:6200:88a6:329f:35c5:477:37dc:73c2) joined #forth
10:56:10 <pointfree> Anyone here want to do an SV-FIG Forth Day talk?
11:09:04 --- join: lchvdlch (~nestr0@pdpc/supporter/active/lchvdlch) joined #forth
11:11:00 <lchvdlch> hi there, I found at least three versions of 328eForth, but all of them will not work on my arduino-clone
11:11:55 <lchvdlch> I just get resets when trying to save any word
11:13:14 <lchvdlch> I cannot find too much information about this Forth version, but maybe someone has a link (besides reading AVR asm programming books)
11:19:08 --- quit: pierpal (Ping timeout: 240 seconds)
11:21:15 --- join: dys (~dys@tmo-103-117.customers.d1-online.com) joined #forth
11:28:55 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
11:35:33 --- quit: pierpal (Ping timeout: 252 seconds)
11:47:50 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
11:51:51 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
12:03:48 --- quit: pierpal (Ping timeout: 240 seconds)
12:40:33 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
12:43:32 --- quit: MrMobius (Ping timeout: 244 seconds)
12:43:32 --- nick: [1]MrMobius -> MrMobius
13:07:01 <john_cephalopoda> Heh, my Mandelbrot set viewer runs on my phone (termux terminal, slightly modified code to work with pforth).
13:44:27 <pointfree> lchvdlch: You could try comparing 328eForth flash write words with those from amforth or asforth for atmega328.
13:54:02 <lchvdlch> right
13:54:09 <lchvdlch> will check that
14:22:29 <pointfree> lchvdlch: There's not much one could get wrong with a simple C! word.
14:22:38 <pointfree> With mecrisp-stellaris on arm, it sometimes doesn't work when the dictionary pointer is not aligned because the size of the core dictionary is sometimes not round to an aligned address.
14:22:57 <pointfree> So maybe check your memory map.
14:23:45 <lchvdlch> oh, you are right, I recall now several nightmares about unaligned addresses...
14:29:33 <pointfree> Interesting: https://stackoverflow.com/a/44201396/44016
14:29:33 <pointfree> lchvdlch: What is the output of HERE HEX.
14:32:40 <pointfree> lchvdlch: I also remember that Ting's eforths' words are always capital letters only, so you would need : HELLO 2 2 + . ; not : hello 2 2 + . ;
14:34:41 <lchvdlch> the value of HERE HEX . is 140
14:35:26 <lchvdlch> but HEX does not seem to be working...
14:35:31 <lchvdlch> so it is decimal 140
14:37:47 <WilhelmVonWeiner> pointfree: does mecrisp not have an align word
14:38:28 <pointfree> lchvdlch: does it work to comma compile 255 C,
14:38:56 <pointfree> if so what is HERE . after that?
14:40:38 <pointfree> WilhelmVonWeiner: yeah it has ALIGN and ALIGNED
14:41:09 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
14:45:58 <WilhelmVonWeiner> should look up how align is usually implemented
14:46:10 <WilhelmVonWeiner> never bothered to implement a forht myself because they all work well enough
14:50:54 <pointfree> WilhelmVonWeiner: Just clear some of the least significant bits of the address in question ( such as the value of DP )
15:01:45 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
15:03:22 --- quit: pierpal (Ping timeout: 252 seconds)
15:14:56 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
15:19:03 --- quit: pierpal (Ping timeout: 244 seconds)
15:28:59 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
15:42:56 --- quit: john_cephalopoda (Quit: Trees can see into your soul.)
15:46:40 --- quit: nighty- (Quit: Disappears in a puff of smoke)
15:48:06 --- quit: pierpal (Read error: Connection reset by peer)
16:05:29 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
16:08:06 --- quit: pierpal (Read error: Connection reset by peer)
16:08:16 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
16:18:38 --- quit: dddddd (Remote host closed the connection)
16:29:14 <KipIngram> No, you have to do more than just clear bits.
16:29:20 <KipIngram> Say you want to align to 16 bytes.
16:29:28 <KipIngram> Add 15 and then clear the bottom four bits.
16:29:50 <KipIngram> Without the add you might back up.  In fact, you would, if you made any change at all.
16:30:34 <KipIngram> : ALIGN  1- DUP NOT -ROT + AND ;
16:31:01 <KipIngram> That's : ALIGN  ( a n -- a')
17:00:23 --- join: dave0 (~dave@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
17:00:46 <dave0> hi
17:03:23 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
17:47:55 --- quit: jedb (Remote host closed the connection)
17:48:06 --- join: jedb (~jedb@199.66.90.113) joined #forth
17:53:10 --- quit: jedb (Remote host closed the connection)
17:53:21 --- join: jedb (~jedb@199.66.90.113) joined #forth
17:55:41 <crc> hi dave0
17:55:56 <dave0> hi crc 
17:58:01 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth
17:59:36 <KipIngram> Evening guys.
18:00:56 <dave0> hi KipIngram 
18:16:53 <tabemann> hey guys
18:16:57 <dave0> hi tabemann 
18:18:53 <tabemann> I should figure out a way to print the smallest possible integer
18:19:00 <dave0> KipIngram: i got "asl" compiled and running on netbsd   http://john.ccac.rwth-aachen.de:8000/as/
18:19:25 <tabemann> because my current code doesn't probably print the smallest possible integer cell
18:19:27 <KipIngram> Ah, cool.
18:19:45 <KipIngram> tabemann: You mean the most negative integer?
18:20:06 <tabemann> yes
18:20:20 <tabemann> the problem is that I negate negative integers before print them
18:20:29 <KipIngram> That's just 1 in the most significant bit and 0's everywhere else, right?
18:20:50 <KipIngram> What's your cell size?
18:20:54 <tabemann> 64 bit
18:21:06 <tabemann> and yes, it's that
18:21:38 <KipIngram> -1 1 << 1 >> not might work, if >> shifts in 0's.
18:21:49 <KipIngram> And that would be cell-size independent.
18:22:20 <KipIngram> >> seems to sign extend on what it shifts in on my system.
18:22:23 <KipIngram> Trying GForth.
18:22:33 <tabemann> my rshift doesn't sign extend
18:22:44 <KipIngram> Oh, -1 1 >> not
18:22:46 <tabemann> I'm thinking of writing an arshift that does sign extend
18:22:49 <KipIngram> doesn't need 1 <<
18:23:52 <KipIngram> This works on gforth:
18:23:53 <tabemann> I need to figure out a way of printing negative numbers without negating the whole thing
18:24:01 <KipIngram> -1 dup 1 rshift xor .
18:24:13 <KipIngram> Gives -9223372036854775808
18:24:36 <dave0> tabemann: negate should work
18:24:52 <KipIngram> Hmmm.  I need to fix my >>
18:25:25 <KipIngram> Probably just using the wrong assembly instruction.
18:25:29 <tabemann> dave0: I'm negating the smallest number - there is no matching positive number
18:25:55 <dave0> tabemann: i think the easiest way to print numbers is to have a word that prints an unsigned number, and a different word for signed numbers
18:26:07 <tabemann> and what I'm currently doing is first testing and negating, then generating characters like a positive integer, and then adding the minus sign
18:26:44 <dave0> i'll try and write it in forth
18:28:05 <KipIngram> tabemann: That's what I do too, and I think it's what dave0 just said as well.
18:28:33 <KipIngram> Yes, I was using a "signed shift" macro in >>.
18:28:48 <KipIngram> But I had an unsigned shift macro - switched to it and now that code snip works in mine as well.
18:28:59 <KipIngram> tabemann: Are you familiar with the book "Hacker's Delight"?
18:29:06 <tabemann> I have it!
18:29:12 <KipIngram> EXCELLENT.
18:29:19 <KipIngram> Lots and lots of nice little tricky dicky maneuvers in there./
18:29:51 <KipIngram> tabeman: for maxint, you just need -1 1 >> .
18:29:55 <dave0> tabemann:    : printsigned dup 0< IF negate printunsigned ELSE printunsigned THEN ;
18:30:11 <dave0> oh shit i forgot the - sign heh
18:30:20 <tabemann> no that won't work
18:30:43 <KipIngram> tabemann: Are you planning to support floating point in any way?
18:30:51 <dave0> : printsigned dup 0< IF [char] - emit negate printunsigned ELSE printunsigned THEN ;
18:31:06 <tabemann> because $8000000000000000 negate doesn't work properly on a 64-bit system
18:31:27 <KipIngram> it worked on mine.
18:31:29 <KipIngram> The string I gave.
18:31:44 <dave0> tabemann: it does work, because, say the most negative number is    -0x8000    it will print a -, then negate to   -0x8000   but this is 0x8000 unsigned, so it will print  -0x8000
18:32:13 <tabemann> KipIngram: I have floating point support, but currently f. and fs. are implemented as primitives using snprintf
18:32:34 <KipIngram> Yes, but you'll want your number converter to handle inputting them, right?
18:33:18 <tabemann> you're right dave0
18:33:21 <KipIngram> I let the presence of a decimal point cause floating point conversion.
18:33:24 <tabemann> i need to use unsigned math
18:33:29 <KipIngram> exponent is optional.
18:33:47 <tabemann> I use "e" to trigger floating point conversion if something isn't a valid hex number (if the base is 16)
18:33:58 <tabemann> and a "." by itself without "e" triggers double-cell
18:33:58 <KipIngram> It computes an exponent in either case; if no exponent is given it gets it by counting digits to the right of the .
18:34:10 <KipIngram> If there is an exponent it still counts and uses the provided exponent to offset that.
18:34:17 <KipIngram> Ah, ok.
18:34:19 <crc> dave0: You could remove the ELSE branch from that:  : printsigned dup 0< IF [char] - emit negate THEN printunsigned ;
18:34:27 <KipIngram> Since I'm 64 bits I decided against supporting doubles.
18:35:35 <KipIngram> I do think that's the best approach to having all three (single, double, float).
18:35:55 <KipIngram> My number converter allows specification of a radix in the number as well.
18:36:02 <KipIngram> I set it off from the actual number with :
18:36:08 <KipIngram> 16:cef7
18:36:20 <KipIngram> But floating point numbers must be decimal.
18:36:25 <KipIngram> No radix spec for those.
18:36:29 <tabemann> I'm using gcc's support for 128-bit integers
18:36:32 <KipIngram> And I don't have BASE.
18:36:38 <tabemann> so I'm supporting double-cells
18:36:57 <KipIngram> I may eventually have doubles too.
18:37:01 <tabemann> the reason why is I want to support 32-bit archs in the future, and on those double-cells will be 64-bit
18:37:07 <KipIngram> Because I'm going to port to a 32-bit target, and I expect I'll want doubles there.
18:37:12 <KipIngram> Once I've designed them in, then why not?
18:37:29 <KipIngram> ^ we're on the same wavelength.
18:37:57 <tabemann> I don't anticipate double-cells will get much use on 64-bit archs of course
18:38:09 <KipIngram> I'm not sure it's fair to say that 0x8000000000000000 negate "doesn't work right."
18:38:19 <KipIngram> That number actually doesn't exist.
18:38:30 <tabemann> exactly
18:39:24 <tabemann> but what I mean is one expects negate applied to a negative number to yield a positive number
18:39:54 <tabemann> rather negate applied to $8000000000000000 yields a negative number, not a positive number
18:40:01 <KipIngram> Right, I see that.
18:40:07 <KipIngram> But... it's a corner case.
18:40:18 <KipIngram> I guess you could demand that it yield a positive DOUBLE.
18:40:25 <KipIngram> But wow.  :-)
18:40:34 <tabemann> the damned nasal demons at work
18:40:36 <KipIngram> Because a double is required to represent that number.
18:46:01 <tabemann> okay, fixed my damned number conversion
18:46:47 <KipIngram> So I am able to enter "minint" and have it output correctly with .
18:47:05 <KipIngram> So even though I'm seeing that it's negatve, negating it, processing it, and outputting a -, it still works.
18:47:07 <tabemann> my solution was to use umod and u/
18:47:18 <KipIngram> Yes, that's actually what I do.
18:47:27 <KipIngram> So I guess it works because I'm treating it as an unsigned.
18:47:56 <KipIngram> I have u/mod that gives me the quotient and the remainder in one go - that's the only one I need, I believe.
18:48:47 <tabemann> I decided to go with two separate functions because I usually don't need both at once
18:50:20 <KipIngram> Right.
18:50:27 <KipIngram> I'll probably wind up with all three.
18:50:33 <tabemann> so will I
18:50:35 <KipIngram> My Forth is sort of "primitive heavy."
18:50:51 <KipIngram> there are a lot of words I could write in Forth but don't.
18:51:01 <KipIngram> I want to know I'm going to get full performance regardless of which one I pick.
18:51:31 <tabemann> my Forth also has a lot of primitives, but usually for things that'd be unnecessarily slow written in Forth, like basic math functions
18:51:50 <tabemann> and even then there are exceptions, like how I implemented ** and d** in Forth
18:52:20 <tabemann> largely because C doesn't by default have any good integer exponentiation primitives
18:52:59 <KipIngram> That makes sense.
18:54:52 <tabemann> whereas for f** I opted to use the libm pow function because someone'd already written double-precision exponentiation and it'd almost certainly be faster than whatever I'd write in Forth
18:55:25 <tabemann> when I get around to adding fsin/fcos/ftan/etc. I will do the same
18:55:36 <KipIngram> I wrote f** in assembly - it required several FPU instructions.
18:59:14 <zy]x[yz> i also sometimes write swear words in assembly
19:14:11 <tabemann> I'll let you know when I need to create a word F*CK
19:14:19 <KipIngram> :-)
19:15:00 <tabemann> I'm reading about the AS guy's adventures with Apple
19:15:51 <tabemann> it sure has offput me from wanting to develop for Apple machines
19:16:26 <tabemann> I don't want to have to become an "Apple Developer"!
19:33:29 --- quit: dave0 (Quit: dave's not here)
19:36:26 <johnnymacs> I am considering replacing the os on a microsd card with forth and trying to turn it into a sort of jupiter ace.
19:37:10 <johnnymacs> I want it to be a wrist computer, and I will use paper with conductive ink on it that use very low voltages to detect when my finger completes the circuit on the buttons.
19:37:12 <crc> It's possible to get the command line toolchain w/o Xcode, but an Apple development ID is needed. (No App Store stuff needed though): https://developer.apple.com/download/more/
19:41:06 <crc> johnnymacs: that sounds like an interesting project
19:43:46 <johnnymacs> These scientific calculators for $1 a tthe dollar store are just an lcd in a plastic housing with a battery and conductive ink on paper with rubber buttons on top. so I figure why have buttons when a finger can complete the circuit on very low voltage.
19:45:23 <johnnymacs> I am also considering putting it in a bluetooth earbud instead because text to speach requires very little power if it's a "cheap voice".
19:46:49 <johnnymacs> I was considering using tonal input with my singing or a small metal harp for a music box but anyone with a speaker could come up and hack my computer
19:47:04 <johnnymacs> I have also considered uv light from a remote control
19:51:41 <MrMobius> you would have a watch on your wrist and point a remote control at it with your other hand?
19:53:37 <johnnymacs> Well I would use the remote if it was in my earbud. but ideally no hands required. Less ideally one hand required.
20:08:37 --- quit: tabemann (Ping timeout: 252 seconds)
20:12:54 --- quit: wa5qjh (Remote host closed the connection)
20:16:49 --- quit: ncv (Ping timeout: 252 seconds)
20:24:05 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:1ec6:932f:1b02:d27e) joined #forth
20:24:05 --- quit: ncv (Changing host)
20:24:05 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
20:35:53 --- quit: proteusguy (Remote host closed the connection)
20:52:52 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:1870:3255:3792:ba89) joined #forth
22:04:43 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
22:04:58 <rdrop-exit> Good afternoon Forthwrights! :)
22:23:33 --- quit: Keshl (Remote host closed the connection)
22:24:09 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
23:59:59 --- log: ended forth/18.11.07