00:00:00 --- log: started forth/18.12.31 00:30:43 --- join: nighty- (~nighty@119-173-207-244.rev.home.ne.jp) joined #forth 00:50:15 --- quit: nighty- (Ping timeout: 250 seconds) 00:50:37 --- quit: sigjuice (Quit: ZNC - http://znc.in) 00:54:35 --- join: sigjuice (~sigjuice@2604:a880:1:20::83:6001) joined #forth 01:16:47 well, that "arduino-fvm" is almost edumacational. Sadly, using c++ and templates as well. Looks like arm was considered, but mostly targets the Uno. 01:20:24 --- quit: pierpal (Read error: Connection reset by peer) 01:21:15 Anyone running a Forth program over new years? 01:21:30 "running"? 01:22:04 I'm poking around code.. Existing code, foreign code the VM idea is solid. 01:22:18 Hm, how old is Forth now? 01:23:27 well, he came up with the concept in... the 60's? 01:23:42 so, it's at least as old as I am 01:25:03 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:25:14 aamof, I think his video 'interview' said it predated C 01:25:59 although, I think he mentioned fortran use during the time he implemented it. 01:27:13 --- quit: pierpal (Read error: Connection reset by peer) 01:28:31 So Forth is about Forthy-eight years old? 01:29:31 fifthy-nine short ly 01:30:53 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:33:45 It's around 48 years old according to Wikipedia 01:33:52 But probably predates that because of CM 01:34:12 well, yeah.. I was speaking of the origins. 01:34:19 --- quit: pierpal (Read error: Connection reset by peer) 01:34:48 whatever the hell he was doing was NOT "forth" when he started - that plainly evolved. 01:36:51 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:38:43 --- quit: pierpal (Read error: Connection reset by peer) 01:40:02 It got me to love low level programming at the assembly level again 01:40:11 Such a good abstraction 01:40:40 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:41:54 I have no love for assembly under "modern" systems.. I hate linker-nonsense, piled atop every variation on asm out there. 01:43:29 Yeah, for modern systems 01:43:39 The only assembly I know right now is Z80, so :) 01:44:21 It got much better after writing my own assembler, because you can control exactly how things are done 01:44:35 Macros were a huge hassle with other ones 01:44:49 I used to like "assemblers" because the code went where you wanted, and did what you want. That's just not happening anymore 01:45:17 PoppaVic: would you consider writing your own? 01:45:31 I can recall that Macros on the asm for the cp/m z80 I had were just plain magic. Loved it. 01:45:36 --- quit: pierpal (Ping timeout: 268 seconds) 01:45:56 siraben: not really.. The bitcodes for the mnemonics are a bear, anymore. 01:46:27 I see. Gets worse for larger instruction sets no doubt 01:46:29 I watch folks banging them together in forth, but my eyes cross. 01:46:42 Isn't there a consistent standard for indicating opcodes? 01:46:50 hahahahaha - no 01:46:55 So one could write a generic assembler and it would work for a new instruction set 01:47:08 Oh... that sucks. 01:47:10 Never heard of one. 01:47:48 I might work on one later this summer 01:47:57 My one is too tied to the Z80 in its pattern matching stage 02:03:29 --- quit: ashirase (Ping timeout: 250 seconds) 02:05:38 --- join: tabemann_ (~tabemann@2602:30a:c0d3:1890:7d04:1e92:6395:7db) joined #forth 02:06:07 --- quit: tabemann (Ping timeout: 250 seconds) 02:06:39 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:07:53 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:10:41 --- quit: pierpal (Ping timeout: 246 seconds) 02:44:56 siraben, nothing in CPU ISAs is standard even for processors of the same "type" like CISC vs RISC. 02:46:11 The RISC-V has about as simple an ISA as possible given the complexity/capabilities of it. It's still a more of a medium rather than reduced instruction set. Nice thing is the whole thing is open source and you can extend it yourself. 02:47:23 But to build a complete assembler for x86-64 is as big a project as most development efforts. 02:57:39 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:58:25 Ah because that instruction set fills a 1000 page book or so 03:09:52 http://ref.x86asm.net/geek.html 03:10:53 Even worse, you can use MOV to move register to register, register to memory, memory to register or immediate to register. And more. 05:01:37 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:39:41 age of forth - in the wikipedia article it states "Forth evolved from Charles H. Moore's personal programming system, which had been in continuous development since 1968" and it goes on to say it was first released in 1970 05:40:33 i always take 1968 as when it first begam - coincidentally, it's the year i was born in :) 05:46:06 --- quit: pierpal (Quit: Poof) 05:46:28 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 06:26:49 yeah, 68 is Forth year 06:33:49 * the_cuckoo ponders what to do next with rpany... needs do/loop, various comparators, if/else/then, other loops, dictionary interrogation, proper parsing and a general cleanup 06:34:08 wife will probably kill me if i try to do any of that stuff today though :) 06:47:16 --- join: dys (~dys@tmo-103-124.customers.d1-online.com) joined #forth 06:56:53 Started to write a small description for the architecture for my Forth OS: https://thecutecuttlefish.org/tmp/arch.html 07:15:53 --- quit: Zarutian (Read error: Connection reset by peer) 07:15:59 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 07:16:16 --- nick: Zarutian_2 -> Zarutian 07:17:03 --- quit: pierpal (Quit: Poof) 07:17:23 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 07:24:53 Ahhh it feels so good to fix +! after much debugging 07:25:06 Turns out the issue was with a bad flag byte 07:25:30 I couldn't find out from testing it with explicit calls, or the interpreter, thought it was in my head 07:28:49 siraben: ??? isnt : +! DUP >R @ + R> ! ; \ enough? 07:29:11 Zarutian: I was defining it in assembler but messed up the flag 07:29:29 Of course it would be enough, this is Forth :) 07:29:52 what flag? +! has the stack effects of ( addend address -- ), no? 07:30:36 Flag byte for checking if the word is immediate, hidden etc. 07:31:05 you mean you had accidentally flagged +! to be immediate 07:31:11 My layout is this: [link pointer][length + flags][word characters][call enter][data/code] 07:31:16 No, worse 07:31:25 I accidentially flagged +! to have a flag of "2" 07:31:34 Which meant nothing but still screwed up the interpreter 07:31:37 Oh well it's fixed now 07:31:50 Zarutian (and also I) was confused because we thought you were doing something with the a flag in the code for +! 07:32:00 Ah I see. 07:32:37 Because by adding "2" the interpreter would have jumped incorrectly because it wouldn't match the length of the word (2) 07:32:50 So no wonder 07:32:56 whoops 07:33:07 siraben: you didnt mask the bits? no wonder 07:33:09 Thankfully none of my other words have this bug 07:33:19 Zarutian: I do mask higher bits 07:33:37 if it's wrong, it's just wrong no matter how you mask it 07:33:45 Right 07:34:44 zy]x[yz: I am going to quote that out of context ;-Ã 07:35:41 i want $5 every time you use it 07:36:39 zy]x[yz: hokay, 5 zimbabwean dollars for each use, got it ;-Ã 07:37:35 zy]x[yz: or, seriously, do you want it in some cybercoin? (what is often called cryptographic currency) 07:38:12 i have a good feeling about the zimbabwean dollar. it's going to come back in 2019 07:38:40 i don't have any of those fad currencies 07:42:32 "(*2) If killed during creation of a file, delete that partial build product. Otherwise we leave behind corrupt data which will cause the next build to fail" 07:43:11 That reminds me of a software I wrote for embedded software. 07:43:27 --- join: Kumool (~Khwerz@adsl-64-237-234-164.prtc.net) joined #forth 07:43:42 Oh, wrong channel :Ã¾ 07:44:35 Zarutian: I give you 5 freshly generated, possibly unique md5sums for each use. Cryptocoin! 07:45:03 0xffffffffffffffff 07:45:17 there's one 07:45:29 0xfffffffffffffffe and so on... 07:45:30 john_cephalopoda: hmm.. you get three 'fulls' (credit card data) for those 07:51:39 zy]x[yz: Nooo! Don't post your crypto money in IRC channels! 07:52:02 Now everybody could take those md5sums from here and buy things with them. 07:52:24 i want to spread the wealth 07:52:54 merry christmas! 07:59:36 It's halloween, not christmas, duh. 08:28:01 --- quit: libertas (Remote host closed the connection) 08:42:33 --- quit: pierpal (Quit: Poof) 08:42:53 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 08:58:45 Maybe in 2019 I will try and implement pattern matching (or the concept) in Forth. 08:59:22 I have a bunch of functions in a jump table and want to pattern match an input to an index for that table. 09:00:15 `DUP = IF n FUNCTIONS @ EXECUTE THEN` in a list is tedious to write, lol. 09:38:07 back 09:38:32 hey guys 09:38:46 how you doin man 09:39:08 working on a very basic proof of concept for some of the ideas behind #forth 09:40:36 I'm not doing anything like JIT though, as this is not meant to be fast or anything 09:41:23 also, to make the code more accessible to people wanting to see what it does, I wrote it in C, even though I could probably have taught myself, say, x86-64 assembly and coded it in that 10:14:31 WilhelmVonWeiner: you could write code to automate the generation of boilerplate like that. Or some macros 10:16:00 * crc has a work related thing with around 1500 words generated automatically when new data fields are added or changed in a database 10:35:00 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 10:35:18 --- quit: tabemann_ (Ping timeout: 250 seconds) 10:59:10 I think it could be done with macros to unroll templates into code blocks 11:18:10 --- quit: gravicappa (Ping timeout: 244 seconds) 11:54:45 --- part: PoppaVic left #forth 11:54:51 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 12:17:39 * PoppaVic sighs 12:27:01 back 12:27:05 wb 12:27:12 hey 12:27:36 hello PoppaVic and tabemann 12:28:35 I'm implementing a proof of concept minimal Forth VM (well, it isn't that minimal, but it's far more minimal than attoforth) 12:29:01 tabemann: link? 12:29:16 I've got it hosted on github, but the code's not up yet 12:29:23 ok 12:29:31 --- join: pierpa (5fefdf55@gateway/web/freenode/ip.95.239.223.85) joined #forth 12:29:48 I've been perusing my old tether code, and the arduino-fvm code 12:30:07 it doesn't do anything at the moment, because I need to hardcode in code in VM instructions to build a Forth on top of it 12:30:17 well, of course 12:30:19 it's basically just the inner interpreter at the moment 12:30:56 I made some, well, interesting design decisions, like that I don't have : or CREATE implemented, but rather what I call NEW-COLON and NEW-CREATE 12:31:14 the reason being that I'm not implementing code parsing into the core VM 12:31:40 so NEW-COLON and NEW-CREATE create anonymous words, where then a word NAME>WORD assigns a name to the resulting word 12:31:44 None of the core should handle parsing, words, heads, etc 12:33:01 the only reason why I'm going to implement IO primitives is just so that I can talk to it so it will do something 12:33:09 btw, are we all seeing "ANS forth" as DPANS94? 12:33:22 and even then it'll basically be just TYPE, KEY, and KEY? 12:33:43 tabemann: well, that's fine for testing - I'm more concerned with the minimal wordset the VM has. 12:34:27 about ANS forth, I'd san DPANS94, and Forth 2012 while not being ANS proper is still in the same vein 12:34:27 https://lobste.rs/s/4ukzaa/be_moore_like_chuck 12:35:19 OK, I was just curious as we used to just mutter "DPANS" 12:37:21 WilhelmVonWeiner: the issue still is: CM literally thinks different than other folks, and forths were almost always their own OS.. The whole hosted-forth rage seems to have entirely swept around CM - and he didn't even care. 12:37:46 I mentioned that in my comment. 12:38:29 Hosted forth isn't true to the spirit, but is the only route for survival in this day and age. 12:39:18 I am not fully agreeable, but until I am gifted a virgin, homemade "system" that uses such a standalone-forth, I plan to stick with linux, yes. 12:39:33 We're running 40 year old OSes designed for PDP-11s and DEC Alphas 12:39:38 Or IBM PC I suppose 12:39:42 back 12:39:53 I do think the standalone will still be dead-useful for almost all embedded use. 12:40:01 I agree 12:40:32 I am trying to construct a nice Forth OS right now, which is safe and offers separation between user space and kernel space. 12:40:38 But it's really hard. 12:40:44 I mean, ok.. the tiny R-PI with linux is a nifty "engine", but I suspect it'd be vastly more powerful running a standalone forth 12:41:07 linux is my device driver 12:41:09 * crc would like to build a hardware implementation of his misc vm someday 12:41:11 Vastly more powerful, but you can't turn it into a NES emulator box with a couple clicks 12:41:15 john_cephalopoda: no one ever needed it. You just cursed and rebooted. 12:41:23 and then leave it on a shelf for the rest of your life 12:41:31 PoppaVic: When I connect my box to the internet, I really need that. 12:41:44 PoppaVic: Funny you say that, that was also the driver behind UNIX vs MULTICS 12:42:00 I want to have some kind of sandboxing, making sure that I can't break the whole system with one program. 12:42:07 Multics guys spent all their time writing error recovery code, UNIX guys hollered down the hall "REBOOT IT!" 12:42:09 UNIX back in the day was the little OS without much in the way of safety 12:42:22 WilhelmVonWeiner: well, sure - the linux base makes it more "friendly" to assorted jobs; the idea of the forthOS on a PI would end up being: "programmed this widget, it runs forever. Next project?" 12:42:54 You could have an old-school "multiprogrammed" Forth on a raspi. 12:43:05 Running natively multiprogrammed forths make sense 12:45:37 stupid question 12:45:49 do you think the user will ever, ever need more than 65536 words 12:46:03 Are they working for Microsoft? 12:46:06 Depends on the user, the project, etc 12:46:17 Decomposition can get there. 12:46:42 BUT, you are still thinking of tokens-as-all-words ;-) 12:46:43 WilhelmVonWeiner will need more than that ;Ã¾ 12:46:48 okay, because what I'm working on at the moment (a #forth proof of concept named hashforth) is a 64-bit TTC forth with 16-bit half-tokens and 32-bit full tokens 12:46:48 tabemann: not in normal circumstances 12:47:33 PoppaVic: How'd you make sure that nobody can just call a random token which has theoretically been overwritten already? 12:47:39 actually s/65536/32768 12:48:00 still an absolutely inane amount of words 12:48:05 john_cephalopoda: why would I? I can't save the world. 12:48:08 not even gforth has 32k words, yet 12:48:16 My largest real applications are less than that 12:48:26 because one bit is dedicated to making an extra half-token 12:48:33 PoppaVic: I can't save the world OR write a good program, so you're one up from I 12:48:37 how big is the smallest word? how much memory is 32768 of those? 12:49:01 the reason why I ask, is that if we never need more than 65536 tokens, I can say screw it with the 32-bit full tokens, and simplify my decoding logic greatly, and thus speed things up 12:49:23 totally eliminate a branch in the decode logic 12:49:33 and an and 12:50:04 tabemann: I see no reason why the token-size/type can't be a macro and you just choose the smallest, medium or largest as required. 12:50:12 the only reason why I am hesitant to not make this change is my experience with Android 12:50:30 where Google seriously decided on an upper limit to the number of methods in an Android application 12:50:34 and I actually ran into this limit 12:51:15 it was fucking hard getting the code to work, because I had to do all kinds of binary-stripping and minimization and shit 12:52:06 Does this limit include nameless words, or just named ones? 12:52:14 crc: all words 12:52:52 That might be limiting then with my preferred style of coding and a long running system 12:53:11 PoppaVic: I just want to have a secure Forth system, but it seems near-impossible to do so with a regular Forth system. 12:53:27 john_cephalopoda: not really surprising to me. 12:53:46 I could make this a compile-time option 12:54:14 where the user can do do make CFLAGS="-DTOKEN16" or make CFLAGS="-DTOKEN32" 12:54:54 tabemann: that's why we gots macros ;-) 12:55:09 yep 12:55:41 john_cephalopoda: you will have to build your own forth 12:55:50 probably with an actual kernel kernel 12:55:51 john_cephalopoda: obviously, you need to ROM it ;-) 12:55:55 WilhelmVonWeiner: That's what I'm doing. 12:56:10 and have that system deviate from many Forth norms 12:56:28 at one level this does feel like premature optimization, but at the same time this goes into the most inner loop of the forth interpreter 12:56:35 you will lose simplicity and elegance 12:56:46 so any extra slowdown will make a major impact 12:56:49 Why design a multi-user OS for a single-user system? 12:58:31 the #1 question you should be asking is why why why why why 12:58:46 yup 12:59:05 :1: Undefined word 12:59:07 >>>why<<< 12:59:14 "Don't anticipate, solve the problem you've got." - CM 12:59:32 Is "users overwriting kernel space memory" a problem you actually have? 13:00:09 "There is no problem with our robots murdering people yet" doesn't seem like a good excuse to think about things beforehand. 13:00:39 if the worst they can do is trash their own program, though, he might have a point 13:00:56 why are you protecting the user from themselves? 13:01:36 zy]x[yz: The worst that can happen is that the program could take over the computer because it got some broken input from a malicious internet server. 13:02:26 validate your input. if they make it past that, you'll never be able to close off everything they could ever do 13:02:57 or to say it differently, if they make it past input validation you've already lost 13:03:05 I have the all-powerful solution. It's called "the on/off switch". 13:04:45 zy]x[yz: When somebody makes it past input validation, they can do stupid things with the program - but they should not be able to just take over the whole system and read out your private keys and stuff. 13:05:22 fair enough 13:05:51 And if it is ever used as a multi-user system, I don't want a user to take over the whole syste,m. 13:22:02 back 13:22:31 okay, I added preprocessor directives so the user can select 8/16-bit, 16-bit, 16/32-bit, or 32-bit tokens 13:25:33 and I made 16-bit, 32-bit, and 64-bit cell sizes selectable as well 14:01:40 john_cephalopoda> And if it is ever used as a multi-user system 14:01:53 but now you're anticipating again 14:02:45 I am designing an operating system. I want to have a specific set of features that makes it possible to do useful things with it. 14:03:19 When everything runs well, I want to use it as a web server one day. 14:03:56 And when I want to do that, multi-user is necessary and it has to be done _now_ because you can't just change the whole OS architecture in the middle of things. 14:05:38 I see both sides of things, like with attoforth I anticipated a lot of architecture that is probably unnecessary for most things (and with my hashforth proof-of-concept I'm making things much simpler), but at the same time, if john_cephalopoda wants to run a web server on this, he needs to make it amenable to that use case from the beginning 14:06:17 I could run everything in Ring 0, but that would be kinda ugly. 14:06:55 a web server kinda is the kinda application where everything needs to be locked down 14:07:37 because the Russians/NSA/Chinese are trying to get into everything 14:07:42 Traditional Forth has quite some parts where one can poke inside of it easily. 14:08:36 I am trying to think of new concepts that allow me to do fun things without sacrificing security. 14:09:43 the simplest approach would be to have the kernel and each process execute its own forth image, and use memory protection to lock them away from one another 14:10:21 of course that makes each process no safer 14:10:36 it just means that a process can't bring down the system or spy on other processes 14:11:04 even though there are ways of doing that (umm timing attacks, rowhammer, etc.) 14:11:56 so that's not exactly true 14:12:36 for rowhammer the best you can really do is memory layout randomization combined with ECC 14:13:02 hmm - yeah - it seems to me that each process would have its own 'stack' (by which i mean stack, rstack, dictionary, etc) - i'm not sure how one 'stack' could ever be tenable 14:13:03 ECC has been broken with rowhammer under controlled conditions, but as I say, those were controlled conditions 14:13:51 memory layout randomization helps because it makes it so that while the attacker can crash your application, they don't know the memory layout, so they can't mount an effective attack 14:13:54 * Code areas can only be written to with special commands 14:13:56 * There are only some specified entry points into code areas 14:13:58 * The return stack must be secured somehow. 14:14:00 * Memory must be protected somehow - Even without an MCU 14:14:42 RDROP, >R and R> are not good. 14:14:58 Only the kernel itself can be allowed to use those. 14:15:20 here's one idea - no-execute 14:15:46 make it so that only code in your code space can be executed, and nowhere else 14:16:31 while at the same time your code space is read-only, so no one can write into it without going through the kernel, which can verify code when it is JITed from the user space to the code space 14:17:08 this makes RDROP, >R, and R> safer, because they cannot be used to execute code outside of the code space 14:17:19 john_cephalopoda: i don't think that would work 14:18:29 relying upon the MMU, no-execute, read-only code, and code verification by the kernel at ; before it is written to the code space seems like the best approach 14:18:56 tabemann: It would make it a little safer, but it is still important where in code space you can jump. When you got something like : LOGIN GET_PASSWORD VERIFY_PASSWORD IF SET_COOKIE THEN ; and you can just jump into SET_COOKIE, you got an issue. 14:19:30 that's where memory layout randomization comes into play 14:20:08 if Alice doesn't know where that code is, there's no way she can jump into the right code to attack it 14:20:20 the best Alice can do is attempt to crash the application 14:20:49 Yeah. 14:20:57 likewise memory layout randomization prevents rowhammer attacks because there is no way for Alice to know what is in the adjacent memory rows 14:22:52 Let's start by just making up some code, think about how it would be implemented and then try to find flaws. 14:23:39 You proposed using a token system and a compiler, which JIT-compiles things somehow. 14:24:02 the JIT compiler can be damn simple for most purposes 14:24:28 ' WORD would put the token onto the stack? 14:24:35 it can literally be just looking up the native code address stored in the dictionary for each word, and stringing a CALL to that code to the code currently being JITed 14:24:46 yes 14:26:01 If you do that, you'll have to make sure that the return addresses work correctly. 14:26:15 To me, returning properly seems like one of the biggest problems. 14:26:58 here's a (highly nonstandard) idea! 14:27:02 you have three stacks 14:27:06 two data stacks and one return stack 14:27:15 Heh, I just thought about that a minute ago. 14:27:32 the return stack is not user-accessible 14:27:37 The complete branching could be done in kernel-code. 14:27:52 the second data stack takes the role that the return stack takes in traditional forths outside of pure returning 14:29:39 Ok, so the system would be SRT _AND_ TTC at the same time? 14:31:32 I'll write down a bit of architecture design... In 2019! 14:31:37 the representation of the code that the user sees would be TTC, but this is not what would actuallly be executed 14:31:42 (So in about an hour, when the ffirework is over :D ) 14:32:19 the code that is actually executed would be SRT/NCI, or just SRT for most purposes when one is just writing a proof-of-concept 14:33:16 dammit I will have to update all the copyright dates in my code 14:33:58 Oh damn... 15:08:18 --- quit: tabemann (Ping timeout: 272 seconds) 15:25:49 hm, do i need to use UNLOOP with BEGIN/WHILE/REPEAT? 15:26:45 i think you only need to use unloop if you exit in the middle of the loop, or break out of it in some other irregular way 15:27:24 oh sorry, i don't think i'm answering the right question 15:27:45 no, i don't think so. maybe i should just stop talking about let someone else answer 15:27:59 sounded right to me :) 15:28:27 only with DO? 15:29:27 I think so, yes. it's there to clean up the stuff on the address stack where do-loop tracks its count and limit values. begin-while-repeat doesn't have those implicit stuffs 15:29:52 yea 15:29:55 thanks 15:30:22 how would i metacompile statements, like variable stores? 15:30:55 ah - ok - thanks :) 15:58:04 Ok, now which stack to use for what? 15:58:58 When I want to use CALL, I'll have to use the regular stack for that pointer... 16:05:01 what is CALL 16:06:19 corecode: The x86 opcode for CALLing a function. 16:06:36 ah, call 16:06:47 Pushes the current addr to the stack, jumps to the function, returns when RET is called. 16:06:51 yes 16:06:57 so what's the issue? 16:07:42 Well, when using CALL, the call stack pointer ESP is used. 16:07:54 ESP can also be used for the parameter stack though. 16:07:56 yes 16:08:28 All in all using CALL instead of JMP after pushing stuff to the stack manually is probably more efficient. 16:10:18 do you need to use esp as data stack pointer? 16:11:00 Nope. 16:11:12 But if I did, PUSH and POP would be only one command. 16:11:24 Otoh it doesn't matter. 16:11:30 I'll get coding. 16:11:40 --- quit: jedb (Remote host closed the connection) 16:11:53 --- join: jedb (~jedb@199.66.90.113) joined #forth 16:16:19 --- quit: john_cephalopoda (Ping timeout: 250 seconds) 16:17:12 i'm using DTC and NEXT is lodsl;call (%eax) 16:18:13 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:31:04 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:7d04:1e92:6395:7db) joined #forth 17:00:18 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 17:02:08 Hello from 2019 17:08:58 what's it like in the future? 17:09:33 It's got that new year smell 17:24:09 smells like shit 17:24:26 ..which is still better than a rotting corpse 17:37:56 PoppaVic: It's the year of the Linux Desktop! Come over, it's incredible! 17:38:07 Uh, zy]x[yz ^^ 17:40:43 but i've long since moved past the linux desktop to the linux laptop. you're saying it's going backwards?? 17:43:35 hey guys 17:43:49 I'm on a linux laptop right now 17:46:11 * tabemann never got the whole not-the-linux-desktop thing, since he got by for years on linux towers, before he gave in and bought a laptop and installed linux on it - sure, there isn't photoshop or quark xpress, but unless you need those... 17:47:00 and I doubt the vast majority of people using windows machines really wouldn't be served just fine with firefox, libreoffice, skype, and spotify 17:48:34 and if they need to do image editing, the gimp or inkscape 17:49:45 it's not like most people are using pricy proprietary CAD tools that only come for windows or actually need adobe photoshop, illustrator, or quark 17:50:21 sure, there's businesses that mandate the use of outlook and like 17:50:25 most people are not even as smart as a chimp - or a dolphin, let alone a cat - or dog. 17:50:38 but I doubt most people use outlook for their own personal purposes at home 17:51:39 I haven't owned a laptop in years 17:52:20 Hah, making progress \o/ 17:53:56 tabemann: People would probably use outlook if google wouldn't invest millions into advertising their gmail stuff, which runs in the browser. 17:56:17 My mobile provider usually gives me a macbook at renewal time, I hand it off to the kids 17:58:29 I think people are all about _comfort_. 17:58:51 When Windows comes pre-installed, people will use it because it is just convenient. 17:58:57 It's there, it runs, whatever. 17:59:34 The only reason to choose e.g. Linux is when Linux is more convenient, e.g. because you know that it will work out better for you or because you know that you'll need it for your work. 18:04:33 hm how do i implement VARIABLE? 18:05:40 : variable create 0 , ; 18:08:01 but how does that work then? 18:09:10 won't that try to execute 0 ? 18:11:40 The 0 gets comma'ed into the parameter field of the just created definition 18:12:37 yes, but how does that not get executed? 18:12:43 corecode: CREATE reads the next word and creates a header then 0 gets put in thr parameter field 18:12:52 yes 18:12:52 But that definition is missing a LIT too 18:13:03 ? 18:13:05 aha 18:13:10 no 18:13:16 0 is just stored there 18:13:29 the number 0 is on the stack and straight up placed as the VARIABLE value 18:13:42 How does the address get pushed at runtime? 18:13:48 CREATE handles all that 18:13:50 VARIABLE FOO makes a word definition FOO which does what? place its address on the stack? 18:13:57 Oh must be something with CREATE 18:14:14 so what's create then? 18:14:17 No; FOO when run places its address on tbe stack 18:14:35 Well the address of the placed 0 18:14:36 siraben: that is what I meant and said 18:14:37 That's the default action of CREATE 18:14:38 back 18:15:01 Corecode: It's explained in the book Starting Forth 18:15:06 Looks like I need to make my CREATE standard 18:15:14 CREATE x makes a token x that, when run, places it's address on the stack 18:15:25 unless you have DOES> then it might do anything 18:15:42 WilhelmVonWeiner: in the case of DOES> then what happens then? 18:15:48 so how do you do :? 18:15:58 What's :? 18:16:16 Is that "act like : if the next word is not defined otherwise ignore?" 18:16:21 I'm fine thank you 18:16:25 Zarutian: DOES> DOES> what DOES> DOES> 18:16:34 hehehhehe 18:16:51 corecode: space deliminate your words like this : otherwise there will be no end of confusion 18:17:31 Oh he meant : 18:17:40 ;-) 18:18:15 WilhelmVonWeiner: lets say it is encountered in reading a definition of a creating word (like that variable word above) 18:18:38 DOES> is easiest to understand in the contenxt of ITC, where DOES> replaces the code pointer of the last word with doDOES and sets the word's secondary pointer to the pointer of the next unit of code, then EXITs 18:18:44 Variable pretty much has the same definition in any Forth, create varies depending on the particular Forth 18:19:19 Zarutian: CONSTANT is : CONSTANT CREATE , DOES> @ ; if that helps 18:19:23 well, for other threading types DOES> has to at compile-time insert a bit of code that implements what doDOES would do in ITC 18:19:29 idk how to explain it 18:20:01 WilhelmVonWeiner, that's pretty transparent 18:20:24 tabemann: transparent? 18:20:28 tabemann: so doDOES or (DOES) pushes the address after the next cell onto the stack and then jumps to the code pointed by the cell after doDOES or (DOES) 18:20:43 My DOES> changes the destination of a JP instruction, since I'm DTC 18:21:03 there is no secondary pointer in my forth, and i never heard of that 18:22:45 corecode: I don't know what to call it otherwise; I just heard that term somewhere 18:23:27 Zarutian: doDOES or (DOES) pushes the data pointer of the word onto the stack and the current IP onto the return stack, then sets the IP to the body of the word 18:24:09 tabemann: pretty much the same effect just in ITC instead of DTC or STC 18:24:49 The implementation details depend on the threading sceme, and the header layout or your particular Forth 18:25:06 *scheme 18:25:22 *of your particular Forth 18:25:32 (I need more coffee) 18:25:43 in attoforth I did a hack where there was no data pointer because word headers were interleaved with data and code, and data would directly follow the header at a fixed offset 18:25:50 --- join: proteus-guy (~proteus-g@49.229.37.186) joined #forth 18:25:54 hey 18:26:11 My CONSTANT is: 18:26:24 whereas in my hashforth proof-of-concept there is a data pointer because word headers are not stored in the user space 18:26:25 : constant ( x -- )( -- x ) entry, & literal inline ; 18:27:13 entry, lays down the header, then I postpone literal and make the constant inline. 18:27:35 This works for either TTC or SRT 18:29:10 I'm implementing in hashforth : CONSTANT CREATE , DOES> @ ; but CREATE is not a primitive but rather a word that invokes the parser, creates an anonymous CREATEd word, then assigns the parsed name to it 18:29:35 Sounds complicated 18:29:36 the reason for CREATE not being a primitive is so I can avoid baking the parser into the core 18:29:37 so a word that counts how many times it is invoked and pushes that would be : COUNTER create , DOES> DUP @ SWAP OVER 1+ SWAP ! ; \ no? 18:29:43 --- quit: proteusguy (Ping timeout: 272 seconds) 18:30:27 CREATE is not usually a primitive 18:30:28 Zarutian: You're not using +! ? 18:31:09 siraben: habbit I suppose as 1+ is often much faster 18:34:53 Corecode: See my explanation of VARIABLE is this comment: 18:34:56 https://www.reddit.com/r/Forth/comments/9u0h7u/idea_for_making_forth_compiler_more_pluggable/e91ne3l 18:43:50 bbiab 18:49:35 Too many shufflers in that `counter` for my liking :) 18:51:29