00:00:00 --- log: started forth/21.03.04 00:29:18 --- join: hosewiejacke joined #forth 00:30:22 --- join: dnm_ joined #forth 00:30:24 --- join: mjl_ joined #forth 00:34:10 --- join: a3f joined #forth 00:43:53 --- quit: jess (*.net *.split) 00:43:53 --- quit: a3f_ (*.net *.split) 00:43:53 --- quit: mjl (*.net *.split) 00:43:53 --- quit: dnm (*.net *.split) 00:43:53 --- quit: tangentstorm (*.net *.split) 00:43:53 --- quit: krjst (*.net *.split) 00:43:59 --- nick: mjl_ -> mjl 00:44:04 --- nick: dnm_ -> dnm 01:21:16 --- join: jess joined #forth 01:34:40 --- join: xek joined #forth 02:14:07 --- quit: shmorgle (Ping timeout: 264 seconds) 04:12:05 --- join: f-a joined #forth 04:20:00 --- quit: hosewiejacke (Ping timeout: 245 seconds) 04:33:25 --- join: hosewiejacke joined #forth 04:48:20 --- join: f-a_ joined #forth 04:48:27 --- quit: f-a (Ping timeout: 260 seconds) 04:48:43 --- quit: f-a_ (Client Quit) 04:49:01 --- join: f-a joined #forth 04:55:48 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 04:56:06 --- join: Zarutian_HTC joined #forth 05:21:52 --- quit: f-a (Quit: leaving) 05:41:15 --- quit: hosewiejacke (Ping timeout: 245 seconds) 05:50:50 --- join: elioat joined #forth 06:24:17 well foucist came by and added me to the +o list, cm has not responded to my invite so... guess we should put it to a vote. should we redirect #forth to ##forth? 06:24:54 founder status is not important to me 06:25:57 Well, it's only to conform to freenode's silly channel naming convention, right? Is there any other motivation? 06:26:09 newp 06:26:23 and i dont like their convention but... this is THEIR network lol 06:26:37 Sure, but it seems utterly redundant. 06:27:01 redundantly redundant even :) 06:27:08 Quite. 06:27:45 I don't think a channel forward will really effect anyone other than if they have set +Q 06:27:57 what is +Q ? 06:28:06 A user mode to not be forwarded on this net. 06:28:11 oh 06:28:41 I usually set it, because I find forwards to be annoying. Most often because of the silly forward critera some chanops set. 06:29:14 e.g. channel join count, whereas other mechanics for controlling that exist. 06:29:57 But to avoid that, all one has to do is set their autojoin to the new channel rather than the old one. 06:30:03 So, no big deal, I suppose. 06:30:41 its the people who are in here that are important 06:31:12 I'm mostly a passerby, so my opinion doesn't really carry any weight here. 06:43:08 if you are active your opinion carries :) 06:43:14 dont care about the opinion of the bots :) 06:43:24 beep boop 06:45:35 --- quit: dave0 (Quit: dave's not here) 06:47:00 if they aren't going to force you to change the channel name, why bother? 06:54:14 oh no! frys electronics is shutting down its entire operation lol 06:54:17 what ever will we do! 07:17:03 --- join: f-a joined #forth 07:29:29 I am trying to understand what this instruction does: inc dword [ebp - 8] -- nasm 07:29:45 This is used by loop of forth 07:29:50 I understand that [ebp - 8] gets the contents of the location at ebp - 8. 07:29:59 I could not figure out what the dword there does. 07:30:13 does it increment 2 words (32 bits) whose value is at ebp-8? 07:30:14 uhhhh 07:30:32 I suspect this has to do some some kind of stack and/or pointer 07:30:44 but I cannot read nasm, so… 07:31:08 im guessing that EBP is the return stack pointer 07:31:43 im also guessing that the forth you are looking at is 64 bits and that the definition for I adds [ebp] and [ebp+8] 07:32:16 oh im ALSO guessing that opcode is in the (loop) definition :) 07:32:40 ok 07:32:49 so thats incrementing the loop index which will cause an overflow flag set when the loop completes 07:33:00 pure, unadulterated guess work :) 07:33:18 this is the forth definition http://ix.io/2RFp 07:33:33 I cannot figure out why it would be incrementing a double word. 07:33:37 this is i386 07:33:49 and I suspect that the loop counter is 32 bits. 07:34:09 why the dword there? 07:34:19 i dont see the asm 07:34:28 just a bunch of boot up log messages or something 07:34:51 [ 0.000000] Booting Linux on physical CPU 0x0 07:34:51 [ 0.000000] Initializing cgroup subsys cpuset 07:34:51 [ 0.000000] Initializing cgroup subsys cpu 07:34:51 [ 0.000000] Initializing cgroup subsys cpuacct 07:34:57 and pages and pages more like that 07:36:17 mark4, are you sure? I see the forth word there. 07:36:25 maybe, you mixed up the url? 07:36:42 clicked on it 07:36:45 let me cut and paste 07:37:00 yea cut and paste shows the right stuff 07:37:04 I see forth too 07:37:17 this is the arm assembly for the same routine http://ix.io/2RFq 07:37:44 yea its in (loop) but called doloop here 07:37:58 and you are right, that dword might be a bug in the code 07:38:10 look at the following compare operation, thats 32 bits not 64 07:38:18 joe9: dword is 32 bits in that flavour of assembly, so it's treating the value at [ebp - 8] as if it were a 32 bit integer 07:38:22 and the code is also not optimal OR fully functional 07:38:27 It is incrementing the counter RP: ebp 07:39:09 that looks like [ebp - 4] is the end index and [ebp - 8] is the start index 07:39:17 so im guessing [ebp] is the loop exit point 07:39:25 mark4, why do you say that the code is not fully functional? Do you have experiences with it 07:39:29 ? 07:39:54 well the method would NOT work with +loop with negative increments 07:40:22 this forth is putting the loop start and end indicies on the return stack as is 07:40:34 and incrementing one till it equals the other 07:40:50 +loop can be 5 +loop or -5 +loop for example 07:41:23 i think this method would fall over with the negative loop increments 07:41:55 this is the code https://github.com/8l/ff 07:41:57 or maybe not. 07:42:08 I like it as it is simple enough to port/understand. 07:42:32 but it is certainly not as optimal as the way laxen and perry did it in F83 which was coppied by tom zimmer for fpc which was copied by me in x4/x64 }:) 07:42:51 whose forth is this? 07:43:35 is this your forth? https://github.com/chisophugis/x64-Forth 07:43:36 ff is felix forth, by Felix L. Winkelmann 07:43:39 this is felix forth 07:43:42 aha :) 07:43:48 how come he is not in here dammit :) 07:44:11 He has not touched it in 5 years. 07:44:24 mark4, is your x64 hosted somewhere? 07:45:28 yes 07:45:36 github.com/mark4th/x64 07:46:03 i also have /x4 which is the more working 32 bit version (64 bit needs work still) and t4 with is the arm thumb2 variant 07:46:14 x4 is direct threaded, both t4 and x64 are sub threaded 07:46:49 yea ive not touched x4 is donkeys years other than a few fixes here and there 07:47:18 im just now within the last week back doing CODING instead of GAMING lol 07:48:32 oooh he wrote an editor for it lol 07:48:55 im not sure if his meta comiler is actually metacompiling anything, i dont see an assembler anywhere in there 07:50:06 we should invite him in here 07:50:49 if you do not mind me asking, is there a place to read on how loop works in forth? such as what it puts on the return stack, etc? 07:51:20 I am porting ff to a plan9 derivative (9front) and seeing if I can get it to amd64 too. 07:51:21 in my forth? 07:52:02 if you look at the definition for DO it takes 2 parameters. a start and end parameter 07:52:21 start and end index i mean 07:53:43 the first thing (do) does is push the loop exit point onto the return stack 07:54:13 https://github.com/mark4th/x64/blob/436424c47528564e67139745d25c0f4d688b5b8f/src/kernel/loops.s I am trying to read here too. 07:54:15 Thanks. 07:54:25 next it ADDS not subtracts (my bad) 0x8000000 to the loop start index and then subtracts that from the end index 07:54:30 It looks like it puts the start index and then end index to the return stack 07:54:37 that "fudges" the loop indicies 07:54:47 it then pushes both of the fudged loop indicies 07:55:03 what this means is DO works for both loop and +loop and for positive and negative increments 07:55:22 --- join: hosewiejacke joined #forth 07:55:25 oh, sorry. end first then start into the return stack. 07:55:40 why the subtract of 0x8000000? 07:55:49 magic :) 07:55:51 math magic 07:56:15 to remove negative numbers? 07:56:25 absolute values? 07:56:29 what that does is the CURRENT index thats pushed to the top of the return tack will cause a stack overflow when the index reaches the limit 07:56:57 adding 0x800000 makes it negative but then subtracing the end index from it makes it positive again 07:57:31 it will be equal to 0x80000000 MINUS the number of required itterations 07:57:41 understand? :) 07:57:51 --- join: shmorgle joined #forth 07:57:54 so, the reutrn stack would be endindex, startindex, and the address to return from loop to, correct? 07:58:03 it will then be incremented back up to 0x800000 which is an overflow 07:58:16 or it will be decremented back down to 0x800000 and ... underflow :) 07:58:29 I think I get it. I will have to work it out on paper slowly. Thanks so much. 07:58:37 the return stack has the current index not start index. and fundged 07:58:47 to get the actual index value you add both of the fudged indicies 07:58:59 add [ebp] to [ebp +4] 07:59:40 its not my code - i think it was laxen and perry who implemented it origainlly when they implemented the first 83 standard forth 07:59:45 tho... it may pre-date them too 08:00:25 btw, the xchg ebp, esp is so i can access the return stacks with push/pop opcodes 08:00:32 instead of fetches and stores 08:00:42 ebp is the return stack, esp is the parameter stack 08:02:56 yes, thanks. 08:08:20 mark4, It has been a enlightening experience working with forth code. Thanks for sharing your work to guide noobs like me. 08:09:16 i was a noob when i started writing x4 really 08:09:25 i knew how to USE forth just not how to implement it :) 08:10:25 --- quit: hosewiejacke (Ping timeout: 245 seconds) 08:18:05 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 08:19:46 mark4, how long did it take you to get comfortable using forth? 08:20:14 actually not a long time because my brain was not yet poluted with things like C :) 08:20:20 i was a pure asm coder first 08:40:17 --- join: Zarutian_HTC joined #forth 08:49:28 --- quit: f-a (Read error: Connection reset by peer) 08:53:30 --- join: f-a joined #forth 09:01:59 --- join: hosewiejacke joined #forth 09:14:10 --- quit: hosewiejacke (Ping timeout: 245 seconds) 09:25:56 --- quit: boru () 09:26:17 --- join: boru joined #forth 09:33:30 --- join: rixard joined #forth 09:34:30 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 09:43:29 --- join: hosewiejacke joined #forth 09:43:45 been thinking about my kinda dumb tic-80 forth idea and I'm kinda confused about it, because tic-80 is one weird thing 09:44:01 it has memory, like a real computer, that can be addressed and read/written from by the user like a real computer 09:44:37 but also, it's built on a lua VM, so either I build the first bits of forth stuff in lua/fennel using lua/fennel primitives or build them in lua/fennel reading/writing the tic-80's memory directly 09:44:42 I've no idea how I'd do that for the best 09:45:57 nihilazo I think you may have better luck with the PICO-8, from my limited experience it has a cleaner distinction between VM and its own runtime 09:46:20 I'm not such a fan of pico-8, not really sure why tbh 09:46:27 I guess I'm more used to tic-80 09:46:31 --- quit: hosewiejacke (Client Quit) 09:46:32 that is legit 09:46:34 (and having fennel support already) 09:46:54 yeah, if I could have a legit scheme in pico-8 I don't think I'd ever use anything else 09:47:10 fennel is fun but makes my head spin because I'm too addicted to cons and cdr 09:47:14 fennel isn't really a legit scheme but it's nicer than lua 09:47:18 imo 09:48:04 I'm writing a bad solitare game in it right now, just because 09:48:18 oh fun! 09:52:21 it's one of my...three ongoing useless proejcts? 09:52:21 lol 09:52:22 but fun 10:43:34 --- quit: gravicappa (Ping timeout: 246 seconds) 10:47:12 --- join: gravicappa joined #forth 11:03:37 --- quit: lispmacs[work] (Remote host closed the connection) 11:40:02 joe9: When you add 0x80000000 before doing an operation, it's usually because you want a flag/status from unsigned arithmetic to work for signed arithmetic 11:41:23 For example, if I want to compare the size of two numbers, I can add 0x80000000 to each to make the signed range [-0x80000000,0x7FFFFFFF] into the unsigned range [0x00000000,0xFFFFFFFF] 11:42:15 Then if there is a borrow when subtracting one number from the other as unsigned numbers, I know that one is 'larger' than the other on the signed numberline too 11:43:20 Example (but with 16-bit numbers): https://github.com/Veltas/zenv/blob/master/zenv.asm#L976 12:27:40 z80? ! 12:35:42 how the BLEEP do you store a utf8 string in c. char foo[] = "foo"; 12:35:59 thats going to be utf8 ISH because the first 127 are the samne 12:36:01 same 12:36:05 --- quit: f-a (Quit: leaving) 12:36:44 but what if i need to be able to create a "┏━━━━━━━┓" string? 12:37:34 har blah[] = UTF8 data here, NOT ascii data ? 12:39:41 --- join: actuallybatman joined #forth 12:47:35 either wait for __STDC_UTF_8___ / char8_t comming in C2X, or use an unsigned char explicitly specify the characters you want by the utf-8 ordinal value rather than by symbolic appearance of the character? 12:57:33 my life would be much simpler if abominations like c++ simply did not exist lol 12:57:56 actually, it seems there's a u8 prefix for strings too 12:57:59 my entire text user interface with windows and everything! in a console... is less than 30k in size! 12:58:02 tho not actually complete 12:58:06 yet 12:58:16 i dont want to add a 3248756293465293746589283745 gig cpp library to it 12:58:42 char pi[] = u8"π"; 12:58:58 aha 12:59:06 except. how do you TYPE that PI character 13:00:03 that depends on the terminal/os you're using 13:01:49 also. i do not like that because what if i have u8"┏┓┗┛━┃┣┫┳┻╋" 13:01:58 and i want to print the nth char from that string 13:02:21 [3] is going to be 3 BYTS in not 3 utf8 chars in 13:02:24 wrong 13:02:43 --- quit: gravicappa (Ping timeout: 264 seconds) 13:02:44 also. that array, is it an array of codepoints or of the chars themselves? 13:03:22 constituent chars (literal bytes) 13:03:57 do not understand what you mean by constituent chars 13:04:26 the codepoints for those chars are 250f, 2513, 2517.. . etc 13:04:33 all 16 bit codepoints 13:04:41 how many bytes per "char" in that string? 13:04:42 --- quit: xek (Quit: Leaving) 13:05:28 a char is still going to be however mean bits long as CHAR_BIT is defined as, so most likely 8 13:06:14 nope. no good to me 13:06:25 assuming 250f is the first utf-8 ordinal you've thrown into that string, you're likely to get 0x25 back from str[0] and 0x0f back from str[1] 13:06:36 --- join: f-a joined #forth 13:06:39 i need to be able to specify a string of printable chars and have those chars stored in the string as CODEPOINTS not chars 13:06:55 right. and thats not correct for my use case 13:07:13 then you're left with defining your own specialised array type and/or associated accessors 13:07:15 so im NOT storing those codepoints in strings but in uint16_t arrays which is still WRONG 13:08:11 uint16_t string_thing = u8"┏┓┗┛━┃┣┫┳┻╋" <-- this would be more correct but im betting not allowed lol 13:08:53 but again. this assumes that the "string" is stored as a sequence of codepoints 13:09:58 when you printf a codepoint does printf know its a codepoint? or do you need utf8_printf ? 13:09:59 --- quit: actuallybatman (Ping timeout: 276 seconds) 13:10:33 i need to be able to specify strings as sequences of printable chars but STORE them as arrays of codepoints 13:11:06 and i need the display functions to handle conversion from codepoint to what ever byte sequence they devolve into 13:11:12 its a clusterfuck lol 13:18:41 when you printf a char*, the sequence of bytes stored there is emitted until the first NUL. If that happens to be utf-8 and your terminal uses utf-8 encoding, great. otherwise, less great 13:21:10 if you care about codepoints (UCS-2 or UCS-4, depending on implementation), there's also wchar_t with L"your widechar string" which has printf's "%ls" operator for printing those 13:21:13 what if you forget the \0 13:22:24 you get all subsequent bytes printed as an added bonus until it's reached :) 13:24:58 again. does that store the CODEPOINTS in the string? or the chars the codepoints expand into? 13:26:10 lol 13:39:57 --- quit: elioat (Quit: elioat) 13:42:29 --- join: Zarutian_HTC joined #forth 13:44:22 well take a look at sizeof(wchar_t) on your system, it might be 4 or more - which would be enough to hold a utf32 ordinal 13:47:06 --- join: elioat joined #forth 13:59:19 but why not just treat those glyphs as strings unto themselves and store them in an as array as such? 14:04:07 roughly: https://pastebin.com/nLDKXEbV 14:07:07 --- quit: elioat (Quit: elioat) 14:49:25 --- join: lispmacs[work] joined #forth 15:02:17 --- quit: Zarutian_HTC (Remote host closed the connection) 15:30:18 quick question: As a beginning forthwrite, would y'all recommend me to build a FORTH on (a) 8086 (b) 80386/x86_64 (c) z80 (d) a fantasy architecture? 15:31:37 --- join: Zarutian_HTC joined #forth 15:43:16 kiedtl: do you code asm? 15:43:40 i would say do it on 32 bit x86 or on an arm linux like the PI 15:44:14 im not really a fan of 64 bit x86, i think its surplus to 99.99999999% of requirements :) 15:45:04 mark4: I'm not super experienced in asm, but I like to think I'm OK => 15:45:20 I might look into ARM, thanks. But I don't have an available PI for testing. 15:45:31 Would you mind giving a rationale for your recommendations? 15:46:51 64 bit x86 is lind of a marketing gimik really. 64 bit os's are not faster than 32 bit, the code is significantly larger and forth is meant to be small :) 15:47:28 i did a 32 bit x86 and 32 bit thumb2 forth then i ported the 32 bit x86 to x64 (work in progress) 15:48:18 but tbh theres literally no advantage to having a 64 bit forth, the 32 bit forth can already do 64 bit math and until consumer machines have Tbytes of ram i dont see a need for 64 bit really 15:49:00 ya, my cpu is 64 bits but the 32 bit forth works just find :P 15:49:48 well, it helps to be able to address >4gb of mem without long pointer gimmicks 15:50:08 yeah, my nice amd64 box does have >256G, sooooo 15:50:18 I do indeed want long pointers 15:51:27 you can emulate all of these fast enough with QEMU though 15:51:38 incl in userspace 15:54:34 mark4, just curious, how did you do the x86 forth? 15:54:53 i always wondered if you use an x86 simulator on your x86 machine 15:55:34 which one? 15:55:38 the 32 bit or 64 bit 15:55:59 both were written in nasm assembly and debugged with GDB or ALD 15:56:12 ALD would have been cool if it had stayed maintained 15:56:32 gdb is a horrendous abomination, spawn of satan 15:57:01 and you can single step and catch mistakes with those two? 15:57:28 --- join: dave0 joined #forth 15:57:39 with gdb its horrendously painful lol 15:57:49 i now do my asm debugging with IDA Pro 15:58:07 do you have to put anything into your asm to get it to work with gdb or it just works with any binary? 15:58:41 just pass it the binary. the problem is that while the assembled forth kernel can have debug info on it the extended forth does not 15:58:55 also. gdb is a bit BITCHY when you try to execute code it does not know exists 15:59:08 and straight up FLAT REFUSES to show the stack because it cant see a stack frame 15:59:16 because theres no such fucking thing as a stack frame 15:59:17 grrrr 15:59:30 heh so assumes a lot about what youre doing 16:00:42 --- part: f-a left #forth 16:00:58 or just tell it what you want to see 16:01:05 set $pc = arbitrary-address 16:01:07 stepi 16:01:32 x/[CELL-COUNT-HERE]wx $sp 16:01:34 etc. :) 16:01:48 yeah, I ended up writing a bunch of python exts to gdb 16:02:01 so I can do the equiv of .S, SEE, etc from within it 16:19:13 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 16:20:20 --- join: Zarutian_HTC joined #forth 16:29:07 --- quit: lispmacs[work] (Ping timeout: 264 seconds) 16:44:32 gdb does not like it when your code lays down code and you try to debug it 16:44:46 it also wont show you whats on the stack unless it sees a stack frame 16:44:51 and the interface is FUCKING HORRIBLE 16:44:54 lol 16:45:09 btw, did i tell you how much i loathe and despise all gnu development tools? :) 17:12:30 weird 17:12:42 i wonder if anyone uses qemu or similar 17:48:59 --- quit: jimt[m] (Ping timeout: 258 seconds) 17:57:39 --- join: lispmacs[work] joined #forth 18:21:22 --- join: boru` joined #forth 18:21:25 --- quit: boru (Disconnected by services) 18:21:27 --- nick: boru` -> boru 18:37:27 --- join: jimt[m] joined #forth 18:42:32 --- quit: joe9 (Read error: Connection reset by peer) 18:46:08 --- join: joe9 joined #forth 18:47:49 I'm using qemu, yeah 18:48:38 I haven't had those problems with gdb, but I'm working on aarch64, which has enough free registers that I do leave a valid C stack in the stack pointer (though it's only a kilobyte or so) 18:49:29 gdb can connect to qemu easily with `target remote', and since I don't have a JTAG, this is invaluable for debugging 18:51:13 agreed on the interface being horrible though... it's like, emacs-keybind-inspired, and it's not hard to get the TUI to segfault... 19:02:20 lol 20:00:08 --- quit: tabemann (Ping timeout: 276 seconds) 20:03:15 --- join: travisb joined #forth 20:03:18 --- quit: cartwright (Remote host closed the connection) 20:05:39 --- join: cartwright joined #forth 20:08:04 --- nick: travisb -> tabemann 20:37:56 --- quit: mark4 (Ping timeout: 245 seconds) 20:41:39 is there a way to do the stack trace when forth fails with an invalid write to address? 20:41:56 I presume there must be a way to walk up the return stack 20:42:18 but, am not sure if there is a better approach? 20:43:16 --- quit: sts-q (Ping timeout: 260 seconds) 20:45:32 --- join: sts-q joined #forth 21:05:28 --- join: gravicappa joined #forth 21:09:25 --- quit: _whitelogger (Remote host closed the connection) 21:12:23 --- join: _whitelogger joined #forth 21:19:19 --- join: Zarutian_HTC1 joined #forth 21:19:20 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 22:41:41 --- quit: jess (Quit: K-Lined) 23:33:16 joe9: which forth? 23:56:42 --- join: jess joined #forth 23:59:59 --- log: ended forth/21.03.04