00:00:00 --- log: started forth/18.10.02 00:51:19 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 01:02:00 --- quit: wa5qjh (Remote host closed the connection) 01:03:53 --- join: wa5qjh (~quassel@175.158.225.198) joined #forth 01:03:54 --- quit: wa5qjh (Changing host) 01:03:54 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 01:26:39 --- join: siraben (~user@unaffiliated/siraben) joined #forth 02:04:19 --- quit: ashirase (Ping timeout: 252 seconds) 02:07:04 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:24:31 --- quit: dave9 (Quit: dave's not here) 02:35:30 --- quit: wa5qjh (Remote host closed the connection) 02:42:50 I actually think I may have been helped, when it came to getting my head around Forth, that I had no inclination to try to "make it fit" some pre-existing knowledge structure in my head. 02:43:13 The way it worked didn't have to be some particular concept I'd learned. 02:43:36 I just took it for exactly what it was - the stuff I read said it did this, so that's what it did. 02:43:52 Immediate words actually run at compile time. Ok, fine. That's perfectly clear. 02:44:55 You guys talk about "closures" - I'm not even really sure what a closure is. But the notion that this words runs the minute it's encountered in the source, whereas that one runs later when I execute the compiled word - that's simple enough that I don't need any "framework" to house it in. 02:45:46 One of you even told me a couple of weeks ago what a closure it, and I'm still not sure, because it was expressed in terms of other abstract concepts. 02:45:59 It's like there's a circularity in all that and I haven't "picked into it" yet. 02:47:05 I run into the same thing when I try to study abstract algebra and stuff. There are rings and fields and a whole bunch of other concepts, and they're all defined in terms of one another. I haven't yet found the right spot to start taking apart the Gordion's knot. 02:47:17 closure is a function with a hidden state (it closes over variables) which is preserved between function calls 02:47:48 But Forth is SIMPLE. It doesn't need a framework. To me it's just about what machine instructions are running when. 02:48:09 So it's code with some data. 02:48:12 The data persists. 02:48:27 yes, it's a code with some data, exactly 02:48:43 So I don't really feel a huge need for that to have a name. :-) 02:49:12 if you were the only programmer in the world it surely wouldn't 02:49:34 I'm not trying to be critical - I'm actually a huge fan of "well-organized" knowledge. I watch a lot of physics videos, and I'm always trying for that next level of "fundamentalism." 02:49:46 So it's great - seriously. I just never learned it that way. 02:50:09 KipIngram: For closures it depends on the language. 02:50:15 Probably because I'm not really a programmer by education - I've just picked up programming along the way. 02:50:19 I'm a hardware guy by training. 02:50:40 most abstractions may be refuted that way. function is a code with a call stack. why name it? 02:51:22 classes on theoretical level are a bunch of functions closed over the object data 02:51:35 KipIngram: How would I add local variables to words? 02:51:54 Say I wanted a constant value but not pollute the word list, just HIDE it afterwords? 02:52:03 Well, that's been done in a number of ways. First off, every word has local variable space - it's called the stack. 02:52:12 I take it what you're going for is to be able to name stack slots. 02:52:17 Yes. 02:52:17 Refer to them by name. 02:52:27 Which implies you have words that can access particular stack slots. 02:52:34 I've added a "frame" concept to my Forth. 02:52:38 Like PICK? 02:52:47 A word can define a stack frame, which basically just sets a "frame pointer." 02:52:53 And I have words to access offsets from that pointer. 02:53:01 Words deeper in the call stack can use those words. 02:53:22 The stack pointer may be different, but the frame pointer isn't, so the whole slew of words can reference the same data using the same words. 02:53:30 Hm. 02:53:33 I just called them 0@ 1@ 2@ 0! 1! 2! etc. 02:53:47 Now, I've thought about a system that will allow me to use names to reference those words. 02:53:51 Based on stack comments. 02:53:52 But these pointers are relative to where the top of the stack was when that word was invoked, yes? 02:54:01 ( a b c -- d e) 02:54:19 That naming system would be an editor level thing. 02:54:21 So if A called B and A referred to stack position 2, it means relative to ITS "top of stack"? 02:54:30 No, that's how I first wrote it. 02:54:32 And B's position 2 could be different 02:54:39 And the stack comment connection really works better with that. 02:54:45 Later I introduced the frame pointer. 02:54:52 Sorry I mean A and B are words, not stack elements 02:54:56 I have words {{ and }} - they open and close a frame. 02:55:00 Ah. 02:55:08 Inside, those 0@ and so on words will always refer to the SAME DATA. 02:55:15 By the way, I've just implemented DOES>, how should I test it? 02:55:23 I just realized that occasionally I have tasks that can't get by with just 1 or 2 stack elements. 02:55:42 I've tried the classic : CONSTANT WORD CREATE DOCOL_H , DOES> @ ; and it works, but what other examples are there? 02:55:46 I really prefer "the Forth way," where you factor factor factor so that you don't need to go deep into the stack. 02:55:51 Right. 02:55:54 But ONCE IN A WHILE I think you just can't do that. 02:56:05 Maybe I'm just not a good enough Forth programmer yet. 02:56:11 There's always an offset relative to the current stack pointer 02:56:23 I've only had to use this 2-3 times in my system, but man, when I do use it it sort of saves the day. 02:56:31 Naming stack elements? 02:56:39 No, just having a frame. 02:56:55 That's a very similar concept to how closures are done in most languages 02:56:58 I just write a little note down to the side telling me what piece of data is where in the frame, and then I used the numeric-based words. 02:57:05 3@ 2+! etc. 02:57:22 Can you give an example of how you use {{ ? 02:57:33 Uh, yeah, let me find one. 02:57:40 Ok thanks. 02:58:05 DOES> was a little complicated to trace through initially but it worked out. 02:58:15 : EXPECT OVER 0 SWAP C! 1 0 {{ (EXPECT) }} 4 DROPS 02:58:16 Not sure how to use it though. 02:58:24 So it first sets up some important data on the stack. 02:58:25 What does enclosing in parens mean? 02:58:27 (EXPECT) 02:58:31 Then runs {{ 02:58:34 It's just a name. 02:58:54 Usually just a way to say "I had some set up to do, but most of this is a loop." 02:59:05 The "meat" of EXPECT is in (EXPECT). 02:59:09 Two separate words. 02:59:17 So now, inside (EXPECT), I've got a LOT of factoring. 02:59:27 Lots of definitions that wind up having no names. 02:59:31 Hmm. Is there a smaller example? 02:59:33 But just exist to keep the code short and simple. 02:59:41 Say I wanted to compute b e + but I had the stack like this: a b c d e 02:59:42 Well, when the code is small you generally don't need a frame. 02:59:55 An offset would do? 02:59:59 Well, ok, sure. 03:00:24 a b c d e {{ 3@ + }} 03:00:39 Inside the frame, e is at 0, d is at 1, c is at 2, b is at 3. 03:00:44 Ah I see 03:00:44 a is at 4. 03:00:56 So you have bound variables. 03:00:59 Can you nest them? 03:01:10 I supported up to 6, and instead of writing f@ which took a depth parameter I hard-coded depths into the words, for efficiency. 03:01:17 Yes, they can be nested. 03:01:27 Outer ones reside on the return stack. 03:01:31 So you can't use them interactively. 03:01:43 Because {{ bombs your return stack. 03:02:01 Execute it interactively and your system will crash. 03:02:04 4 3 2 1 0 {{ 3@ {{ 3@ }} }} . . would print out 3 then 2? 03:02:20 Uh, yes, that looks right. 03:02:26 I haven't had to nest them. 03:02:27 I mean a stack with 4 3 2 1 0, not added in that 03:02:35 Yes. 03:02:35 I see. 03:02:53 This is really like a closure 03:02:59 Ok. 03:03:34 So see, how you could provide some source-level mechanism that let you alias those 3@ 2@ words, with "names" if you wanted to, but all you're doing is affecting the readability of your code. 03:03:38 To give an example ((lambda (x y) (+ x y)) 2 3) reduces to (+ 2 3) then 5 as x is bound to 2 and y is bound to 3 03:03:44 It would still COMPILE to the number-based words. 03:03:47 Similar to your nesting 03:04:09 So does 3@ depend on the stack at compile time or run time? 03:04:24 Run time. 03:04:33 Whatever the frame pointer has in it at run time. 03:04:43 It just offsets 3 cells from the frame pointer and fetches that. 03:04:47 How do I implement concurrency/coroutines in Forth? 03:05:19 Well, exactly what do you mean? Sorry - terminology again. Multiple tasks? 03:05:36 --- join: john_metcalf (~digital_w@host109-149-153-210.range109-149.btcentralplus.com) joined #forth 03:05:44 Yeah. For instance, say I'm running one of your frames and I want to pause execution on that to a different frame 03:05:44 I have task blocks and process blocks. 03:05:55 Naming things are hard 03:06:01 At any time the address of the base of the currently executing task is held in a register. 03:06:13 And that task's owning process is pointed to by the first cell of the task block. 03:06:22 So I get at task variables by offsetting from the register. 03:06:30 And get at process variables by offsetting from [register] 03:06:47 I have three classes of variables in my Forth: system, process, task. 03:06:59 The only difference is what gets added to the variable "address." 03:07:03 They're all stored as offsets. 03:07:06 From "something." 03:07:09 Hm. I see. 03:07:15 system vars are offset from the base of the whole system in RAM. 03:07:24 Process vars offset from base of process block. 03:07:32 Task vars from base of task block. 03:07:50 Your Forth system is an entire OS? 03:07:58 I have task vars to serve as register save locations - to switch tasks, I save the registers, reload the task register, load the registers, continue. 03:08:16 I mean for it to be, yes. 03:08:21 Ah I see, so you save registers and can restore state. 03:08:30 It currently runs only under MacOS, but I'm "doing things" that are os level functionality. 03:08:34 And intend to port it to bare metal. 03:08:55 Yes, ultimately a few register values are the important state. 03:09:12 targets me at the correct memory blocks, points at the right code to execute, points to the right stacks, etc. 03:09:19 Change the registers correctly, you change the context. 03:09:28 So what can I use DOES> for now that I have it? 03:09:42 :-) 03:09:43 ^ I'll take a further look at multiple threads sometime 03:09:45 Anything you like. 03:09:54 Can you give some examples? 03:10:00 Maybe from your system 03:10:36 Well, I don't actually use it much. And haven't implemented it in this sytem yet. But gosh, let's see. 03:10:45 Trying to think of something interesting. 03:11:03 Say you have a piece of hardware out there. 03:11:32 And there are a series of things it can do, and you make it do those things by writing a string of bytes to a register. 03:11:51 So you could define a word CONTROL 03:11:55 No - COMMAND 03:12:02 So that you could say this: 03:12:12 COMMAND ALPHA 03:12:31 That creates the word ALPHA, and when ALPHA is executed it will stream to the hardware. 03:12:57 Ah, so making new words based on the current stack context? 03:12:57 : COMMAND , , , , DOES> ...code... ; 03:13:14 When ALPHA gets run, there will be the address where you ,'d those bytes on the stack. 03:13:29 So ...code... would fetch those four cells and write them to the hardware. 03:13:38 Probably in reverse order, so that you could WRITE THEM in the right order. 03:13:50 Sorry - 03:13:52 Right. 03:14:01 : COMMAND CREATE , , , , DOES> ...code... ; 03:14:06 Gotta have the CREATE 03:14:30 Hmm. In my Forth create takes a string pointer and a length to create the word, so I write WORD CREATE DOCOL_H 03:14:56 where DOCOL_H makes the docolon header like "call docol", and the address following the "call" instruction is overriden when DOES> runs 03:14:57 So if you make a whole bunch of those commands, they all "do" the same thing, but they have different data stored in their parameter fields. 03:15:04 Right. Sharing code. 03:15:38 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:16:07 KipIngram: Ok. I think I get DOES>. How about something like POSTPONE? 03:16:21 POSTPONE just delays execution one level. 03:16:28 Is that not the same as [COMPILE] ? 03:16:40 If you POSTPONE an immediate word, you basically just remove its immediacy. 03:16:46 You compile it - not run it. 03:16:58 Ah, so you append "if" to the definition but not compile it to zbranch ... 03:17:01 And if you postpone a non-immediate word, instead of running when you run that definition, it compiles it. 03:17:21 Hm? The non-immediate word doesn't run anymore? 03:17:32 Or is it just compiled like normal? 03:17:36 : ALPHA POSTPONE + ; 03:17:45 Now when you run alpha it will COMPILE +. 03:17:50 To whatever the end of the dictionary is then. 03:17:55 SEE ALPHA -> : ALPHA + ; right? 03:17:59 This used to be called COMPILE 03:18:05 : ALPHA COMPILE + ; 03:18:09 I think that's more readable. 03:18:24 So when I run alpha it will do something like ' + , ? 03:18:25 But they also had [COMPILE] to cover immediate words. 03:18:36 So they unified those into one word POSTPONE, which the two behaviors. 03:18:50 Yes, exactly. 03:18:52 Something like that. 03:19:06 Ok. What other things should I implement? 03:19:14 Useful standard structures? 03:19:36 :-) Well, I'm not sure what you've implemented and what you haven't. Those are two of the most important "fringe things," I think. 03:19:51 I've added some things not in usual Forths. 03:19:57 Do you have any kind of output formatting? 03:20:06 I supported something similar to C format strings. 03:20:36 Forth is traditionally weak in handling strings, arrays, and othe rsuch structures. 03:20:43 You might like something to help out in that area. 03:21:01 But that winds up involving some sort of memory management - you need a dynamic place to keep that stuff. 03:21:01 KipIngram: Here's my current word list https://github.com/siraben/ti84-forth/blob/master/DOCUMENTATION.md 03:21:08 So you're stepping pretty far from "real Forth." 03:21:17 Yeah I'm trying to implement ." but it's crashing when I run it in a compiled word 03:21:22 Ok. Let me get some coffee and I'll take a look. 03:21:33 Well, ." should be immediate. 03:21:49 If you run it interpreteting, it takes what follows in the input stream and prints it. 03:21:55 Right, I have that part. 03:22:11 But if you run it compiling, it needs to compile (.") and then put the string in compiled code memory after (.") 03:22:19 (.") prints it from there and steps the IP over it. 03:22:32 Be right back. 03:22:41 Alright. I'll take another stab at it. 03:22:46 Does your (.") move the IP? 03:23:00 Because when (.") runs it's pointing to the string, and you'll crash if you don't reposition it. 03:23:21 So there's a word called LITSTRING which can be used to add string literals to words: 03:23:43 ... | LITSTRING | 5 | h | e | l | l | o | NULL | ... 03:24:27 It should leave the address of the start of "hello" onto the stack, so I might follow it up with PUTLN, which prints a NULL-terminated string followed by a new line. 03:25:38 Ah I must be compiling it wrong... I need to keep track of the string length and then back-fill the length count. 03:25:53 Or maybe just omit the length entirely. 03:27:06 Yeah, there's really no more to it than what I wrote above - you probably just fubared the implementation. You'll make it work. 03:27:11 Ok, finding your word list now. 03:27:12 KipIngram: Re: formatting things, this reminds me of one of the features the Haskell language where it excels in which you can create your own data types and tell the compiler how to format them when printing 03:27:41 KipIngram: It's this one: https://github.com/siraben/ti84-forth/blob/master/bootstrap.fs#L28 03:27:46 Yes. 03:27:57 The indentation is like that because I pasted it into an asm file so I needed to reduce whitespace 03:28:02 Is there a pretty printer for Forth? 03:28:10 Sorry - that yes was for your question about compiling (.") 03:28:15 Right 03:28:25 You compile (.") then copy the string after that. 03:28:45 Yeah it'll be fixed soon 03:28:45 So when execution reaches (.") it not only prints the string, but also pushes the instruction pointer past the end of the string. 03:29:16 Ah, I just remembered that a good feature to have is 32 bit numbers. 03:29:19 Just like how (lit) puts the number on the stack and nudges IP past it. 03:29:24 It's just a long literal. 03:30:02 KipIngram: Right. lit does that 03:30:25 What's ASK do? 03:30:45 Oh I should have removed that, it just printed out a string "Press a key..." 03:30:49 Used it during testing 03:30:56 Ok. 03:31:19 It's hard to look at a list like that and click to "what might be missing." Looks like a pretty reasonable list. 03:31:20 So how would I implement 32 bit numbers? With 2 stack elements? 03:31:27 Yes. 03:31:33 And it's kind of tedious and annoying. 03:31:52 Traditional Forth makes a double entry like that if you include a decimal point in the number. 03:31:59 Location of the decimal point is irrelevant. 03:32:21 So 12345. 1.2345 and 123.45 all give you exactly the same thing. 03:32:21 Since it's a Forth on the calculator it would be a crime to not be able to add numbers > 65535 03:32:28 I see. 03:32:46 I'll need to look into the TI 84 ROM calls, there's quite a bit for floating point and so on 03:32:48 So once those two cells are on the stack, you have no idea how they cot there. 03:32:51 Displaying them as well 03:32:54 12345. 03:32:58 and 0 12345 03:33:00 give you the same thing. 03:33:07 Ok. 03:33:09 So + can't just "know you entered a double." 03:33:15 You have to have D+ or something. 03:33:20 Of course, yes. 03:33:23 And then the whole suite 03:33:28 Yeah. 03:33:34 My system is 64-bit - I passed on doubles. 03:33:34 D* D/ DMOD etc 03:33:42 Instead I'm letting decimal point designate "flaot." 03:33:47 Ah, jealous. 03:33:51 64 bits is a lot 03:33:55 Converts the number to floating point and leaves it on the FPU stack. 03:34:01 Yes, it's nice. 03:34:39 So in my case decimal location does matter. 03:34:51 12.3 and 1.23 are different by a factor of 10. 03:35:05 What's sorely missing is a screen editor 03:35:14 Yes, but you can write one. 03:35:16 I plan to. 03:35:26 It'll just use ANSI controls. 03:35:38 Oh, I have a command history in mine. 03:35:45 Apparently the calculator limits program sizes to 8K + a bit, so I'll need to read more on how the calculator stores that 03:35:57 I can navigate back through previous command lines and re-issue them, edit them and re-issue, etc. 03:36:03 And I DID nest frames. 03:36:07 Ah, Having that would be nice 03:36:12 Like a shell. 03:36:13 EXPECT has a frame in it, and QUERY also has one. 03:36:16 Yes. 03:36:27 It behaves largely like bash history, but not quite. 03:36:34 bash history has a weirdness I wasn't willing to tolerate. 03:36:54 If you navigate back in bash, edit a line and hit enter, you get that as your new line, and the old line is still back there unchanged. 03:37:14 Would BoyerâMoore be too much or am I just fine with a naive string searching algorithm? 03:37:15 But if you navigate back, change a line, and NAVIGATE AWAY FROM IT (not enter), it CHANGES THE HISTORICAL LINE. 03:37:17 I hate that. 03:37:26 Once you hit enter on a line it should never change as a history item. 03:37:33 Oh, you can change the history? 03:37:39 In bash you can, yes. 03:37:43 I consider it a bug. 03:37:53 I plan to support some regular expression capabilities. 03:37:54 I thought it reissues the command as a new one, no? 03:38:06 If you hit enter without leaving the editied line, yes. 03:38:08 But try it. 03:38:08 Or maybe I'm just too used to Zsh 03:38:09 03:38:22 Navigate back, diddle a line, then navigate forward again and do something. 03:38:28 Navigate back and see what tha tline looks like now. 03:38:31 The one you diddled. 03:38:46 Oh wow 03:38:52 YEAH. 03:38:59 Mine doesn't do that. 03:39:18 The history should be WHAT WAS EXECUTED. 03:39:24 In Zsh it just creates a new entry 03:39:29 Right. 03:39:47 That's the thing, you can do as you please in Forth. 03:39:57 I suspect there are some similarities between command history and a screen editor. 03:40:10 With a screen editor you just have more than one line visible, right? 03:40:16 But it's otherwise a similar structure. 03:40:19 Right. 03:40:28 Why did you choose to write it in nasm, macOS? 03:40:29 So I expect some code sharing there. 03:40:53 My IBM-issued computer is a Mac; nasm was just the first thing I got my hands on that seemed to be willing to work for me. 03:41:04 I think I'm going to have to switch to gas for this Cortex M4 port. 03:41:42 What's the last Forth standardization? 03:42:03 I heard something the other day about a 2012? 03:42:06 But I don't really know. 03:42:23 Seems to be more of an issue with Forth, people want different things all the time. 03:42:31 I think these things that are "missing" from Forth (string handling, commmand history, etc.) are all things that involve some complexity and require some kind of dynamic memory management. 03:42:41 Forth traditionalists just don't want to go there - too much complexity. 03:43:09 That command history involves a big buffer (obviously) and some fairly involved linked data structures. 03:43:25 Still looking for Forth Fundamentals, hm. 03:46:06 So my primary impetus for the stack frame thing was that command history. 03:46:13 I see. 03:46:16 Here I am, accepting a string from the keyboard. 03:46:26 Already a bit of an involved task, if you want to support cursor control and so on. 03:46:34 And now I want to add a whole other dimension to that. 03:46:40 Complicated data structure to navigate, etc. 03:46:51 So I would need to "pause" execution of reading the string 03:47:01 I just wound up with five or six or seven things on the stack, all of which I needed somewhat smooth access to. 03:47:13 That would require some restructuring because when a string is being read, nothing else can run. 03:47:13 Doing it with standard stack operations was a NIGHTMARE. 03:47:26 ^in my implementation 03:47:52 Right - when I first started this my quick and dirty "get it going" thing was to just do a MacOS "get string" syscall. 03:47:58 So obviously I had no control over that. 03:48:01 I took what MacOS gave me. 03:48:12 To take control I had to switch to getting individual keystrokes. 03:48:21 Implemented the "structure" myself. 03:48:31 Ah, that's how mine works. One key at a time. 03:48:47 It's the only way to really have things the way you want them. 03:49:01 And QUERY provides access to the command history, but EXPECT does not. 03:49:01 Especially because there weren't keys for characters like ! @ / \ etc. 03:49:08 Those keys just do nothing in EXPECT. 03:49:41 So I have a lower level word _READ. 03:49:47 KipIngram: Do you have a TI-84 calculator by any chance? 03:49:49 It handles reading a string and can be "resumed." 03:49:57 If it sees a key it doesn't know how to handle, it returns. 03:50:07 Since you're on a Mac you would be able to flash my program to your calculator, if you wanted. 03:50:09 Its caller can supply the handling and resume _READ. 03:50:24 I don't have a calculator these days. 03:50:33 Use an HP 42S emulator on my phone. 03:50:47 Ah hm. My string reader just asks for characters until a newline is hit. 03:50:57 Ignoring unprintable keys etc. 03:51:05 Right. 03:51:30 My _READ handles horizontal cursor controls. But if it sees vertical cursor controls it returns, with the terminating keystroke on the stack. 03:51:37 Caller can do something with that if it wants to. 03:51:47 QUERY does - navigates the command history. 03:51:55 EXPECT just ignores them and resumes _READ. 03:52:17 KipIngram: Here is the key code -> character conversion table 03:52:23 https://github.com/siraben/ti84-forth/blob/master/forth.asm#L1113 03:52:54 I use termios calls to dick my keyboard around so that it's fairly raw. 03:52:58 There's a $00 byte which corresponds to key code 5, the ENTER key. The GETS routine detects that and NULL-terminates the buffer. 03:53:16 I still get ASCII values, but for example all of ctrl-A through ctrl-Z will return a byte to me, 1-26. 03:53:41 I suppose I could add special byte values like $01 $02 $03 $04 for the arrow keys and dispatch on those 03:53:48 I defeated all of the "special handling" that systems typically give some of those. 03:54:24 Chasing down the right system calls on the Mac for that was a bit of an ordeal. 03:54:33 What documentation did you use? 03:54:34 Apparently Apple doesn't want people making system calls. 03:54:42 Wants them to use some thing called IOKit. 03:54:50 I just found a list online. 03:54:55 I have it bookmarked, probably. 03:55:03 There's not a lot of good stuff out there on that. 03:55:19 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 03:55:20 TI provides a equates file for ROM calls 03:55:21 https://github.com/alberthdev/spasm-ng/blob/master/inc/ti83plus.inc 03:55:32 There's quite a bit of a community around TI-84 asm 03:55:39 I don't understand why Apple would be so snobby about it. 03:55:45 I'd imagine most people on macOS would use a compiler anyway 03:55:50 Why are the system calls THERE if they're not meant to be used? 03:56:12 Modern software industry - obsessed with abstraction. 03:56:21 Why do undocumented instructions exist in the Z80? 03:56:24 Or other chips for that matter? 03:56:38 I assume they're "inadvertent." 03:56:45 Just by-products of the hardware design. 03:56:55 Or in the case of Intel chips, they contain backdoors! 03:57:05 Yeah, no kidding. 03:57:10 That's kind of ridiculous. 03:57:28 It's evil. 03:57:48 Any other handheld microcomputers? 03:58:28 Is that a question for me? 03:58:34 In general, but sure. 03:58:52 I'm trying to think of interesting targets to port to later 03:59:09 Hey... how about a washing machine? 03:59:31 Forth would be great for running appliances. 03:59:36 Robotics in general, I think. 03:59:43 Classic Forth example. : WASHER WASH SPIN RINSE SPIN ; 03:59:55 Ah, I should investigate the robot cortex at my school 04:00:03