00:54 <siraben> mark4: you should see the isomorphic keyboard layouts for piano

00:54 <siraben> but indeed, you have to practice and get familiar with all 12 keys and they have different finger patterns

00:55 <siraben> KipIngram: what computer did you buy?

00:56 <siraben> yet another channel I participate in regularly has moved to libera

00:58 <KipIngram> It's a Lenovo ThinkPad Carbon X1 Gen 8.

00:59 <KipIngram> 16 GB RAM, 512 GB SSD.

01:06 <KipIngram> Seems to be drawing about 515 mA right now.

01:08 <KipIngram> If the capacity listed over there is right, that's 22 hours of time.

01:08 <KipIngram> I need to write my current monitoring utility - I keep a little tiny window in the bottom left of my console screen that reports that stuff to me.

01:08 <KipIngram> Updates every 30 seconds.

01:11 <KipIngram> the key command is

01:11 <KipIngram> upower -i /org/freedesktop/UPower/devices/battery_BAT0

01:12 <KipIngram> I catch that in a bash variable and then pick apart and do a little arithmetic.

05:11 <siraben> f-a_: yeah, a lot of programming language channels have moved

09:43 <jn__> in any case, please announce a move in the /topic, if it's decided

11:18 <KipIngram> Morning, folks.

12:40 <cmtptr> 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...

12:48 <KipIngram> :-)

12:48 <KipIngram> I'll be trying to move my Forth over to the new Linux box this weekend.

12:48 <KipIngram> All I should need to do is change the syscall and iocotl stuff.

12:50 <cmtptr> moving from 32-bit to 64?

12:51 <KipIngram> No - it's 64 on both.

12:52 <cmtptr> why do you have to change syscalls then?

12:52 <cmtptr> you bought something that isn't amd64?

12:52 <KipIngram> MacOS adds an offset to the syscall numbers, and has a slight difference in the registers used to pass parameters.

12:52 <KipIngram> Different "secret numbers" need to go to the ioctl syscall to get the termios right.

12:52 <cmtptr> oh it's a different os

12:53 <KipIngram> Right. MacOS --> Fedora.

12:54 <KipIngram> 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.

12:54 <KipIngram> Linux doesn't require that, but will still allow it.

12:54 <KipIngram> It causes my NEXT to have one or two extra assembly language instructions that it would optimally need.

12:55 <KipIngram> I'll retain that feature for now, to minimize the porting work.

12:55 <KipIngram> In any case when my system can rebuild itself I'll be able to rebuild using absolute addresses.

12:55 <KipIngram> That relative thing is just a requirement of the MACHO executable format that MacOS uses.

12:58 <KipIngram> I point r15 at the base of my "body region" and r14 at the base of my "header region."

12:59 <KipIngram> 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.

12:59 <KipIngram> As a convenience, my NEXT code is the very first thing in the image, so r15 points directly to it.

12:59 <KipIngram> So I can implement NEXT as jmp r15.

13:01 <KipIngram> 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.

13:01 <KipIngram> In my system an "xt" is an offset, of a CFA pointer in the header space.

13:02 <KipIngram> 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.

13:02 <KipIngram> I'm sorry - I flipped r15 and r14 there.

13:02 <cmtptr> i knew that but i was waiting to see if you'd catch it

13:03 <KipIngram> ( xt --) r14 + h@ r15 + gives a code address.

13:03 <KipIngram> :-)

13:04 <KipIngram> and ( xt --) r14 + 4 + h@ r15 + gives a pointer to the definition list of a word.

13:05 <KipIngram> 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.

13:06 <KipIngram> r13 is my IP. r12 is my data stack pointer, r11 is my return stack pointer.

13:06 <KipIngram> r10 is a "frame pointer" that I use to implement stack frames.

13:07 <KipIngram> r8 and r9 are scratch register pair that the virtual machine needs.

13:07 <cmtptr> i was wondering whether you burned a register for that or did you put them in the return stack

13:07 <KipIngram> rcx is the TOS.

13:07 <KipIngram> And rsi and rdi are "address registers"

13:07 <KipIngram> Well, I have a lot of registers - I tried to use them to gain performance.

13:08 <KipIngram> A lot of primitives need scratch regs anyway, and they can use r8 and r9 without having to save them.

13:08 <cmtptr> 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

13:08 <KipIngram> I've also allocated rbp for my "exception handling" system.

13:08 <KipIngram> No official use yet for rax, rbx, rdx.

13:09 <KipIngram> I think it's a pretty effective arrangement.

13:11 <MrMobius> i think it would be really interesting to profile forth on x86

13:12 <MrMobius> 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

13:12 <KipIngram> I've planned a profiling system.

13:12 <KipIngram> I see an easy way to get pretty rich data there.

13:12 <MrMobius> like appatently thrashing the stack may not have a speed penalty

13:13 <KipIngram> I can modify NEXT to use the IP to increment cells of a heat map array. Execution heat map.

13:14 <KipIngram> Set up all zeroes, flip NEXT to that modified version, and execute my app for a while.

13:14 <KipIngram> Then flip it back, and go see what the data looks like.

13:14 <MrMobius> that wouldnt really tell you anything about performance though

13:15 <KipIngram> Well, it would tell me about where my code was spending the most time.

13:15 <MrMobius> you might compare two versions and the one with more instructions and a noticeably different heat map might take much less time to run

13:15 <KipIngram> I could see which bits would benefit most from optimizing.

13:16 <KipIngram> But you're right - it's not a TIMING.

13:17 <MrMobius> 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

13:17 <KipIngram> But my definition of "profiling" is exactly that: where is the code spending its effort.

13:18 <KipIngram> I have a mechanism for reading the tsc, so I'll probably want some timing utilities as well.

18:03 <KipIngram> Happy Friday guys. Just got my second covid jab - bracing myself for the effects to roll in over the next few hours.

18:04 <KipIngram> 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.

18:04 <KipIngram> 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.

18:05 <KipIngram> But the results of that work are in that include file, so I shouldn't have any of that work to do again.

18:05 <KipIngram> All that stuff is NOT documented very well anywhere.

18:06 <KipIngram> 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.

18:06 <cmtptr> linux ioctl ids are generated with a series of macros... it take a bit of effort to decode them

18:06 <cmtptr> 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

18:07 <KipIngram> Yep.

18:07 <KipIngram> That yields them up fairly readily.

18:08 <KipIngram> 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.

18:08 <KipIngram> The rest of the registers are the same.

18:08 <cmtptr> 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

18:08 <KipIngram> And then Mac has you add 0x2000000 to all the syscall #'s.

18:09 <KipIngram> Yeah.

18:09 <KipIngram> But all the pieces are onhand now, and nasm is installed and it builds without error.

18:09 <cmtptr> kewl

18:09 <KipIngram> Of course it wouldn't run right now, but at least I know that much is in place.