00:00:00 --- log: started forth/21.05.21 00:36:21 --- quit: xek (Remote host closed the connection) 00:44:08 --- quit: proteus-guy (Ping timeout: 240 seconds) 00:56:59 --- join: proteus-guy joined #forth 00:59:45 --- join: xek joined #forth 01:58:09 --- join: mtsd joined #forth 02:43:43 in any case, please announce a move in the /topic, if it's decided 03:39:03 --- quit: Vedran (Ping timeout: 260 seconds) 03:39:54 --- join: Vedran joined #forth 03:51:17 --- join: proteanthread joined #forth 03:51:17 --- join: rtdos joined #forth 03:56:33 --- quit: Vedran (Ping timeout: 260 seconds) 03:57:09 --- join: Vedran joined #forth 04:05:54 --- part: rtdos left #forth 04:05:55 --- part: proteanthread left #forth 04:06:03 --- quit: Vedran (Ping timeout: 260 seconds) 04:06:26 --- join: Vedran joined #forth 04:18:33 Morning, folks. 04:32:57 --- quit: Vedran (Ping timeout: 246 seconds) 04:33:34 --- join: Vedran joined #forth 04:39:54 --- join: AlyssaXY joined #forth 04:54:41 --- quit: Vedran (Read error: Connection reset by peer) 04:55:31 --- join: Vedran joined #forth 05:21:08 --- quit: mtsd (Ping timeout: 240 seconds) 05:37:24 --- quit: AlyssaXY (Remote host closed the connection) 05:40:49 been thinking about doing some experimenting this weekend, but on the other hand i also would like to know what the sun looks like again... 05:48:33 :-) 05:48:49 I'll be trying to move my Forth over to the new Linux box this weekend. 05:49:06 All I should need to do is change the syscall and iocotl stuff. 05:50:40 moving from 32-bit to 64? 05:52:00 No - it's 64 on both. 05:52:29 why do you have to change syscalls then? 05:52:47 you bought something that isn't amd64? 05:52:57 MacOS adds an offset to the syscall numbers, and has a slight difference in the registers used to pass parameters. 05:53:11 Different "secret numbers" need to go to the ioctl syscall to get the termios right. 05:53:19 oh it's a different os 05:53:41 Right. MacOS --> Fedora. 05:54:30 MacOS also forced me to use an "offset" based system - all of my definitions are stored as offsets from the origin of the system, and I point a register to the origin and then do register relative accesses. 05:54:39 Linux doesn't require that, but will still allow it. 05:55:06 It causes my NEXT to have one or two extra assembly language instructions that it would optimally need. 05:55:31 I'll retain that feature for now, to minimize the porting work. 05:55:46 In any case when my system can rebuild itself I'll be able to rebuild using absolute addresses. 05:56:08 That relative thing is just a requirement of the MACHO executable format that MacOS uses. 05:59:05 I point r15 at the base of my "body region" and r14 at the base of my "header region." 05:59:44 A definition is a list of pointers into the header region. So I have to do those relative to r14. Then the CFA and PFA pointers (in the header region) point back to stuff in the body region, so those get r14 added. 06:00:00 As a convenience, my NEXT code is the very first thing in the image, so r15 points directly to it. 06:00:12 So I can implement NEXT as jmp r15. 06:01:29 The headers consist of a two byte link field, just telling me how far back the previous header is, the counted name string, and then a CFA pointer and a PFA pointer. 06:01:57 In my system an "xt" is an offset, of a CFA pointer in the header space. 06:02:44 So if I take an xt, add r15 to it, fetch the 32-bit cell at that location, and add r14 to THAT, I have the address of machine code to execute. 06:02:59 I'm sorry - I flipped r15 and r14 there. 06:03:18 i knew that but i was waiting to see if you'd catch it 06:03:43 ( xt --) r14 + h@ r15 + gives a code address. 06:03:46 :-) 06:04:19 --- join: andrei-n joined #forth 06:04:28 and ( xt --) r14 + 4 + h@ r15 + gives a pointer to the definition list of a word. 06:05:42 All of the bytes of the counted name string are guaranteed to have MSB=0, except for the count byte, which is guaranteed to have MSB=1. So I can scan from the CFA location back and recognize the count byte. That's the nfa. Then subtract 2 from that is the lfa. 06:07:04 r13 is my IP. r12 is my data stack pointer, r11 is my return stack pointer. 06:07:14 r10 is a "frame pointer" that I use to implement stack frames. 06:07:30 r8 and r9 are scratch register pair that the virtual machine needs. 06:07:33 i was wondering whether you burned a register for that or did you put them in the return stack 06:07:33 rcx is the TOS. 06:07:46 And rsi and rdi are "address registers" 06:08:05 Well, I have a lot of registers - I tried to use them to gain performance. 06:08:21 A lot of primitives need scratch regs anyway, and they can use r8 and r9 without having to save them. 06:08:46 yeah now that i think of it, s0..s4 would take an indirection penalty if they had to go to the return stack for their frame address 06:08:52 I've also allocated rbp for my "exception handling" system. 06:08:59 No official use yet for rax, rbx, rdx. 06:09:51 I think it's a pretty effective arrangement. 06:11:27 i think it would be really interesting to profile forth on x86 06:12:29 i think some of the speed killers on other platforms lile arm might not apply so you could come to some counter intuitive conclusions that would be interesting 06:12:29 --- join: AlyssaXY joined #forth 06:12:34 I've planned a profiling system. 06:12:45 I see an easy way to get pretty rich data there. 06:13:03 like appatently thrashing the stack may not have a speed penalty 06:14:19 I can modify NEXT to use the IP to increment cells of a heat map array. Execution heat map. 06:14:39 Set up all zeroes, flip NEXT to that modified version, and execute my app for a while. 06:14:48 Then flip it back, and go see what the data looks like. 06:15:05 that wouldnt really tell you anything about performance though 06:15:58 Well, it would tell me about where my code was spending the most time. 06:16:08 you might compare two versions and the one with more instructions and a noticeably different heat map might take much less time to run 06:16:15 I could see which bits would benefit most from optimizing. 06:16:31 But you're right - it's not a TIMING. 06:17:38 ya thats true. it would be useful for that even if it didnt reveal anything abiut the underlying x86 magic. the thing is, improving the hot regions is tough if you cant test the performance 06:18:03 But my definition of "profiling" is exactly that: where is the code spending its effort. 06:18:44 I have a mechanism for reading the tsc, so I'll probably want some timing utilities as well. 06:24:37 --- quit: AlyssaXY (Quit: Leaving) 06:30:55 --- join: AlyssaXY joined #forth 07:33:48 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 07:50:11 --- join: Zarutian_HTC joined #forth 07:54:33 --- quit: Zarutian_HTC (Ping timeout: 246 seconds) 08:14:01 --- join: Kumool joined #forth 08:51:13 --- quit: AlyssaXY (Remote host closed the connection) 09:24:39 --- join: AlyssaXY joined #forth 09:56:47 --- join: kiedtl joined #forth 09:58:00 --- quit: kiedtl (Client Quit) 09:58:44 --- quit: AlyssaXY (Remote host closed the connection) 10:05:13 --- quit: proteus-guy (Ping timeout: 260 seconds) 10:16:54 --- join: proteus-guy joined #forth 11:04:15 Happy Friday guys. Just got my second covid jab - bracing myself for the effects to roll in over the next few hours. 11:04:48 Got my Forth assembly source moved to the new computer, and also chased down the include file and build script I used last time for Linux support. 11:05:21 It was quite a bit of research and experimentation to chase down all of those magic numbers - especially the ones associated with the ioctl syscalls. 11:05:39 But the results of that work are in that include file, so I shouldn't have any of that work to do again. 11:05:56 All that stuff is NOT documented very well anywhere. 11:06:24 For parts of it I had to figure out how to do whatever I was wanting to do in C, and then printing out the C #define values that it used. 11:06:46 linux ioctl ids are generated with a series of macros... it take a bit of effort to decode them 11:07:08 i want to say i've seen a decoder before, but i don't remember where. i'm pretty sure i've also used gcc -E to do it before 11:07:52 Yep. 11:08:03 That yields them up fairly readily. 11:08:42 There's also a difference in one of the registers used to send in parameters to syscalls. I forget which is which right offhand, but I think it's r10 on one platform and rcx on the other one. 11:08:49 The rest of the registers are the same. 11:09:01 we used to have the same problem where i work in our ipc libraries. every module got a unique id and a range it could use for its message ids, and the macros that assembled there were scattered all over the place, which made it really irritating to debug when you were looking at a core dump and only had the hex value available to you 11:09:04 And then Mac has you add 0x2000000 to all the syscall #'s. 11:09:25 Yeah. 11:09:55 But all the pieces are onhand now, and nasm is installed and it builds without error. 11:10:06 kewl 11:10:13 Of course it wouldn't run right now, but at least I know that much is in place. 11:33:15 --- join: wineroots joined #forth 12:08:46 --- mode: ChanServ set +v mark4 12:34:37 --- quit: mark4 (Read error: Connection reset by peer) 12:34:54 --- join: mark4 joined #forth 12:54:47 --- quit: gravicappa (Ping timeout: 260 seconds) 13:34:18 --- quit: spoofer (Quit: Lost terminal) 13:56:52 --- join: spoofer joined #forth 14:00:01 --- quit: andrei-n (Quit: Leaving) 14:47:19 --- join: rtdos joined #forth 14:47:19 --- join: proteanthread joined #forth 14:54:41 --- quit: ovf (Ping timeout: 260 seconds) 14:55:41 --- quit: rann (Read error: Connection reset by peer) 14:59:55 --- join: rann joined #forth 15:01:17 --- join: ovf joined #forth 16:34:19 --- join: Zarutian_HTC joined #forth 17:07:16 --- quit: Kumool (Quit: EXIT) 18:31:02 --- join: boru` joined #forth 18:31:05 --- quit: boru (Disconnected by services) 18:31:07 --- nick: boru` -> boru 19:17:08 --- quit: sts-q (Ping timeout: 240 seconds) 19:19:35 --- quit: rtdos (Ping timeout: 258 seconds) 19:19:35 --- quit: proteanthread (Ping timeout: 258 seconds) 19:30:28 --- join: sts-q joined #forth 21:04:58 --- join: gravicappa joined #forth 22:34:23 --- join: mtsd joined #forth 22:38:07 --- quit: gravicappa (Ping timeout: 260 seconds) 22:38:28 --- join: gravicappa joined #forth 22:40:55 --- join: andrei-n joined #forth 23:59:59 --- log: ended forth/21.05.21