00:00:00 --- log: started forth/17.08.03
00:09:53 --- quit: dys (Ping timeout: 260 seconds)
00:50:29 --- join: dys (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) joined #forth
02:45:41 --- quit: leaverite (Remote host closed the connection)
02:46:06 --- quit: nighty-- (Quit: Disappears in a puff of smoke)
02:46:26 --- join: leaverite (~Thunderbi@175.158.225.196) joined #forth
02:48:48 --- quit: leaverite (Remote host closed the connection)
02:48:48 --- quit: wa5qjh (Remote host closed the connection)
03:01:25 --- join: GeDaMo (~GeDaMo@212.225.125.110) joined #forth
03:11:31 --- join: wa5qjh (~quassel@175.158.225.196) joined #forth
03:11:58 --- join: leaverite (~Thunderbi@175.158.225.196) joined #forth
03:20:34 --- quit: proteusguy (Remote host closed the connection)
04:08:08 --- quit: rtmanpages (Read error: Connection reset by peer)
04:08:24 --- join: rtmanpages (~rtmanpage@129.sub-174-204-5.myvzw.com) joined #forth
04:13:14 --- quit: rtmanpages (Ping timeout: 276 seconds)
04:43:40 --- join: GITIB (~GiL@2a01:e0a:2a:f760:c1e3:555b:459:3ac7) joined #forth
04:46:33 --- quit: leaverite (Remote host closed the connection)
04:46:33 --- quit: wa5qjh (Remote host closed the connection)
04:47:15 --- quit: Zarutian_PI (Read error: Connection reset by peer)
04:47:45 --- join: Zarutian_PI (~3.1415@89.17.133.173) joined #forth
04:54:21 <zy]x[yz> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/386-Assembler.html
04:54:42 <zy]x[yz> not a very good sign when your example has a bug in it
05:37:34 --- join: proteusguy (~proteus-g@2405:9800:b408:bc31:5dde:f8d6:cf77:ede6) joined #forth
05:37:34 --- mode: ChanServ set +v proteusguy
08:18:38 --- quit: Zarutian_PI (Read error: Connection reset by peer)
08:18:46 --- join: Zarutian_PI (~3.1415@89.17.133.173) joined #forth
09:44:42 --- quit: zignig (Ping timeout: 268 seconds)
09:45:06 --- join: zignig (~zignig@bl3dr.com) joined #forth
10:17:42 --- join: mark4 (~mark4@99.30.241.51) joined #forth
10:18:21 <mark4> well my arm64 forth is coming along nicely, still NOT working fully but its getting closer to a github push :)
10:51:26 <C-Keen> I am still struggling with that mostly because the amd64 calling conventions are so weird
10:54:54 <zy]x[yz> amd64 doesn't have calling conventions though
10:55:28 <mark4> im not using "C"rippled languages to build my forth kernel
10:55:33 <zy]x[yz> that's determined by the OS, not the ISA
10:55:51 <zy]x[yz> also he said arm64 and not amd64
10:58:36 <zy]x[yz> looking at source for something written for gforth - does , in gforth write only a byte??
10:59:42 --- quit: dys (Ping timeout: 258 seconds)
11:01:22 <mark4> yea amd64 is on the todo list
11:01:25 <mark4> for "some day"
11:01:25 <mark4> lol
11:02:55 <mark4> ok i have a problem
11:03:01 <zy]x[yz> good luck with that
11:03:17 <mark4> in this arm64 forth execution tokens are all 32 bits but a cell is 64 bits
11:03:29 <mark4> so i called a 64 bit comman x, and a 32 bit comma ,
11:03:41 <mark4> also i have x! ! etc
11:03:59 <mark4> well for 16 bit i am obviously using h, h@ h! right?
11:04:18 <mark4> problem is h, is "compile 64 bit item into head space" so its not consistent
11:04:32 <mark4> just call it head, ?
11:04:33 <zy]x[yz> in mine I use b, w, d, q, and ,
11:04:54 <mark4> q is 128 bits, im not doing 128 bit compiles
11:05:09 <zy]x[yz> similarly, b@ w@ d@ q@, and +b@ etc for fetches without sign extention
11:05:10 <mark4> addresses are 64 bits but xt's (opcodes) are 32 bits
11:05:21 <zy]x[yz> right
11:05:39 <mark4> i think ill rename h, to head, to allow me to use h, to compile a 16 bit item
11:05:42 <mark4> and be more consistent
11:05:50 <zy]x[yz> I guess you lost me when you said "obviously 16-bit is h,"
11:05:58 <zy]x[yz> I don't see how h is obviously 16-bit
11:06:24 <mark4> because thats the arm convention
11:06:28 <zy]x[yz> oh
11:06:29 <GeDaMo> I think you're better off specifying the size with a number in some way
11:06:33 <mark4> ldrh = load 16 bit
11:06:42 <zy]x[yz> gross
11:07:00 <mark4> ldr w0 = 32 bit
11:07:04 <mark4> ldr x0 = 64 bit
11:07:08 <zy]x[yz> but yeah I'm fine with head,
11:07:18 <zy]x[yz> stuff like I that I prefer to be spelled out with a short word
11:07:19 <mark4> ldrh w0 is load 16 bits into the 32 bit reg with zero extend
11:07:30 <zy]x[yz> you don't use it often enough for it to be obvious when you come across it
11:08:06 <mark4> ans forth people dont like words like @ ! etc because they need things spelled out in full ": fetch-the-32-bit-item-at-the-given-address ..... ;
11:08:09 <mark4> i hate ans forth
11:08:21 <mark4> lshift and rshift etc.  i use << >> u>>
11:08:57 <mark4> i had considered at one time renaming and or xor to & | ^
11:09:21 <mark4> i actually had that built into isforth for a while, i STILl think they are preferable to "and" "or" "xor"
11:11:46 <zy]x[yz> << >> +>>
11:12:53 <mark4> + meaning what?
11:13:38 <mark4> << and >> are usually signed and u>> suggest unsigned like m/mod and um/mod
11:13:43 <zy]x[yz> >> is arithmetic shift, +>> isn't
11:13:54 <mark4> so + is unsigned
11:13:57 <zy]x[yz> yeah
11:14:26 <mark4> forth tradition would use a 'u' there but im not going to nay say using + instead
11:14:46 <zy]x[yz> the is ugly
11:15:07 <mark4> this is kind of weird. 64 bit forth where , is a 32 bit compile lol
11:15:11 <zy]x[yz> and like I said earlier, I have sign-extend-less fetches and ud@ is gross
11:15:15 <mark4> not my fault, arm's fault
11:16:29 <mark4> i have []@ to fetch a 32 bit indexed item from an array, [x]@ to fetech 64 bit indexed item [h]@ 16 b its and [c]@ 8 bits. and the associated ! operations
11:17:12 <mark4> addr index [size]@ where size is x blank h and c (blank = 32 bits)  
11:17:34 <mark4> err blank meaning nothing, not space lol
11:17:41 <mark4> []@ 
11:18:03 <zy]x[yz> right
11:18:04 <zy]x[yz> cool
11:18:27 <mark4> i think i can probably do an arm64 assembler for this forth eventually, thmub2 asm is a clusterfuck opcode encoding
11:18:29 <zy]x[yz> why not just have [] [x] [h] [c] though
11:18:32 <mark4> arm64 is much simpler
11:18:45 <mark4> because i need to specify if its a @ or a !
11:18:55 <zy]x[yz> [x] x@
11:19:00 <zy]x[yz> I guess that's sort of noisy
11:19:02 <mark4> i have those actually
11:19:13 <mark4> calculate address given indedx but dont fetch
11:19:34 <zy]x[yz> yeah I imagine [x]@ is implemented : [x]@ [x] x@ ;
11:19:35 <mark4> i didnt understand what you meant
11:19:49 <mark4> well it could be, i coded both not colon
11:19:55 <zy]x[yz> oh
11:20:17 <zy]x[yz> the point of my question is: doesn't that make [x]@ needlessly redundant?
11:20:54 <mark4> maybe
11:21:06 <mark4> but its like : 1+ 1 + ;
11:21:17 <mark4> its a common operation
11:21:17 <zy]x[yz> yeah, I thought 1+ was stupid too
11:21:34 <mark4> nope. common operations can be optimized that way
11:21:39 <GeDaMo> 1+ is because some CPUs have an increment instruction
11:21:47 <zy]x[yz> this is the part of forth I never got.  it seems like it's encouraged to build a lot of very similar special-purpose words rather than to use a small number of orthogonal primitives
11:22:09 <mark4> its a negligable speed hit and makes the source code more compact
11:22:44 <zy]x[yz> well like GeDaMo mentioned it might even be a speed improvement, but still that's always bothered me
11:22:45 <mark4> 1+ in my aarch64 forh is add x0, x0, #1
11:23:01 <mark4> its not always much of a speed improvement
11:23:07 <mark4> its more of a space improvement
11:23:18 <GeDaMo> A lot of traditional Forth words are from the 70s when they might have made more sense
11:23:48 <mark4> if you uhave a lot of "1 +" or even anytyhing else... define : 1+ 1 + ; is a space optization thats worth it
11:24:00 <mark4> they still make sense NOW
11:24:21 <mark4> just because you have 2845629873648923 terabytes of ram doesnt mean you need to write 284659286439 terabyte hell worlds
11:24:40 <mark4> space efficiency for me is always better than speed efficiency
11:24:43 <zy]x[yz> yes it does!  otherwise all that ram goes to waste
11:25:21 <mark4> thats the problem with sw engineers today. hardware builds a hole and software keeps filling it up
11:25:33 <Zarutian_PI> sram L1 caches are not as big. If you can fit your code and data into those while processing then you gain considerable speed.
11:25:49 <mark4> oh people have 32 gigs of ram now? meh my gizmo app can be 83475698243 times larger than it needs to be and like who cares
11:25:54 <GeDaMo> Threaded code is data
11:26:10 <mark4> threaded code is data.  this forth is sub threaded tho
11:26:24 <GeDaMo> Does it do code inlining
11:26:25 <GeDaMo> ?
11:26:27 <mark4> both my arm forths are. x4 (x86 forth) is direct threaded
11:26:38 <mark4> i do NOT do code optimizations of any kind
11:26:40 <mark4> ever
11:26:46 <zy]x[yz> but guys, how will you ever know if a sector of memory goes bad if you're not exercising all of it??
11:27:00 <mark4> well.  my literal compiles a movz or multiple movk's to load the literal
11:27:53 <mark4> push x0  movz x0, 0xnnnn  <-- 16 bit is lowest granularity
11:28:44 <mark4> movk x0, #0xLLLL followed by movk x0, #0xHHHH lsl #16 and lsl #32/#48 
11:29:00 <mark4> i dont consider that an optimization though
11:29:19 <mark4> and i will NEVER support inlining of code
11:29:21 <mark4> ever
11:29:48 <mark4> if code is inlined behind your back by the compiler that removes information from YOU that you can leverage
11:29:59 <mark4> like... whats the state of my return stack inside some word
11:30:27 <mark4> not knowing exactly whats on the return stack 100% of the time, at any location in your execution flow is the same as not knowing whats at the top of the parameter stack
11:30:43 <GeDaMo> I wrote a Forth a while back where I could set an inline flag on words to have them inlined
11:30:55 <mark4> : asm>  r> fudge >r !> fudge ;  <--- this is a delay line
11:31:02 <mark4> : foo asm> dont do this yet ;
11:31:09 <mark4> : bar asm> dont do this yet either ;
11:31:11 <mark4> foo bar
11:31:21 <mark4> when bar executes the "dont do this yet" part of foo is executed
11:31:40 <mark4> i use that technique to do SANE assemblers in forth
11:31:48 <mark4> not 5 # ax mov bullshit
11:31:52 <mark4> mov ax, # 5
11:31:58 <mark4> push ax
11:32:12 <mark4> when push is parsed and executed all the operands of the mov are known to the assembler
11:32:20 <mark4> so MOV is executed when PUSH is parsed
11:32:30 <mark4> push is not executed until the next mnemonic is invoked
11:33:27 <mark4> end-code would cause the final opcode mnemonic to be executed
11:34:41 <mark4> degamo yea that sort of makes sense for CODED primitives but i would never support inlining of colon definitions
11:35:12 <mark4> code 1+ add x0, x0 #1 end-code +inline  (where +inline is like "immediate" but different)
11:35:56 <mark4> for a sub threaded forth doing a bl to 1+ or just inlining the opcode... pick one
11:37:00 <mark4> or maybe having an immediate word that causes the next primitve to be inlined <-- this would be preferable to me
11:37:12 <mark4> : foo lots of forth code here [I] 1+ more forth code here ;
11:37:22 <mark4> where the 1+ is inlined because of the immediate word [I]
11:37:28 <mark4> but that makes the compiler more complificated
11:38:44 <mark4> well i guess [i] could be parsing :)
11:38:54 <mark4> and leave the compile loop intact
11:39:51 <mark4> could protect the developer from self by also having a +inline flag on words that can be optionally inlied with [i]
11:40:15 <mark4> oh lol i DID create a macro colon facility in x4 but i never actually use it so i forgot i did it
11:40:30 <mark4> THATS a way to create colon definitions that inline automatically
11:40:40 <mark4> m: foo 100 0 do i . loop ;m
11:40:50 <mark4> : bar 100 0 do foo ;
11:41:12 <mark4> can linline definitions with any kind of loops or ." strings" or anything else
11:41:28 <mark4> which you CANNOT do with postpone foo postpone bar postpone fud postpone bullshit
11:42:05 <GeDaMo> Does it use evaluate? :P
11:42:16 <mark4> i dont have evaluate
11:42:31 <mark4> i do not support : foo "forth code goes here" evaluate ;
11:42:34 <mark4> thats STUPID
11:42:46 <mark4> : evaluate-this forth code goes here;
11:42:54 <mark4> : foo evaluate-this ;
11:43:01 <mark4> evaluate is idiocy
11:45:28 <mark4> wow i dont even find it in my github for x4
11:45:29 <mark4> wtf lol
11:46:58 <mark4> yea thas weird, i have it in my x4 dir but its not in the repo
11:47:06 <mark4> maybe it was held back till it got fixed or something
11:48:39 <mark4> no duh its there. i was looking in the t4 repo not x4
11:48:47 <mark4> https://github.com/mark4th/x4/tree/master/src/ext/macros
11:49:24 --- join: mtsd (~mtsd@h-158-174-23-206.NA.cust.bahnhof.se) joined #forth
11:56:15 <pointfree> Moore's law on hardware: hardware should get smaller. (Chuck) Moore's law on software: software should get smaller.
11:58:33 <mark4> agree with both but mostly with chuck
11:58:50 <mark4> cm said "if its not at least 100 times smaller than the equiv c then its not forth"
11:59:14 <mark4> my curses library is 6 to 8k of compiled size.  ncurses is 500k
11:59:30 <mark4> i can do WAY WAY WAY more with mu curses lib than anyone can do with ncurses
11:59:37 <mark4> i can have overlapping moving text windows for example
11:59:44 <mark4> with text scrolling up/down/left/right
12:00:02 <mark4> i do get tearing but thers no way to sync to vblank :.
12:00:04 <mark4> :/
12:03:59 --- join: dys (~dys@tmo-122-225.customers.d1-online.com) joined #forth
12:41:22 <zy]x[yz> do you guys have any good references about building higher level languages in forth
12:43:00 <GITIB> you just need a parser no? parse the high level code to compile it in forth
12:53:49 <zy]x[yz> hm
12:57:38 <GeDaMo> http://www.nicholson.com/rhn/files/Tiny_BASIC_in_Forth.txt :P
13:11:19 --- quit: GeDaMo (Remote host closed the connection)
13:19:34 --- quit: dys (Ping timeout: 240 seconds)
13:21:27 --- quit: mtsd (Quit: leaving)
13:32:02 --- join: Chef_Gromboli (~Chef_Grom@static-72-88-80-103.bflony.fios.verizon.net) joined #forth
13:43:30 --- join: dys (~dys@tmo-081-48.customers.d1-online.com) joined #forth
14:09:19 --- quit: mark4 (Ping timeout: 240 seconds)
14:30:36 --- part: GITIB left #forth
16:28:22 --- join: rtmanpages (~rtmanpage@129.sub-174-204-5.myvzw.com) joined #forth
16:28:49 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
16:44:23 --- quit: wa5qjh (Remote host closed the connection)
16:47:17 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
16:50:45 --- join: Zarutian_PI2 (~3.1415@89.17.133.173) joined #forth
16:50:45 --- quit: Zarutian_PI (Read error: Connection reset by peer)
16:51:11 --- nick: Zarutian_PI2 -> Zarutian_PI
16:55:20 --- quit: wa5qjh (Read error: Connection reset by peer)
16:57:44 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
17:12:59 --- quit: wa5qjh (Remote host closed the connection)
17:18:03 --- quit: rtmanpages (Ping timeout: 240 seconds)
17:19:50 --- quit: karswell_ (Read error: Connection reset by peer)
17:21:41 --- join: wa5qjh (~quassel@175.158.225.192) joined #forth
17:22:00 --- join: leaverite (~Thunderbi@175.158.225.192) joined #forth
17:48:50 --- join: nighty-- (~nighty@kyotolabs.asahinet.com) joined #forth
17:52:04 --- join: ACE_Recliner (~ACE_Recli@c-98-220-46-30.hsd1.in.comcast.net) joined #forth
17:55:59 --- join: rtmanpages (~rtmanpage@129.sub-174-204-5.myvzw.com) joined #forth
17:58:53 --- quit: Zarutian_PI (Read error: Connection reset by peer)
17:58:59 --- join: Zarutian_PI (~3.1415@89.17.133.173) joined #forth
18:22:20 --- quit: rtmanpages (Remote host closed the connection)
18:27:03 --- join: rtmanpages (~rtmanpage@129.sub-174-204-5.myvzw.com) joined #forth
18:39:59 --- quit: dys (Ping timeout: 260 seconds)
19:07:16 --- quit: wa5qjh (Remote host closed the connection)
19:07:16 --- quit: leaverite (Remote host closed the connection)
19:10:11 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
19:21:03 --- quit: wa5qjh (Ping timeout: 240 seconds)
19:22:25 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
19:35:01 --- join: http_GK1wmSU (~deep-book@129.232.221.173) joined #forth
19:35:35 --- part: http_GK1wmSU left #forth
19:35:49 --- quit: koz_ (Ping timeout: 240 seconds)
19:36:03 --- quit: proteusguy (Ping timeout: 258 seconds)
19:36:40 --- join: proteusguy (~proteus-g@2405:9800:b408:bc31:5dde:f8d6:cf77:ede6) joined #forth
19:36:40 --- mode: ChanServ set +v proteusguy
19:38:25 --- join: koz_ (~koz@121.99.240.58) joined #forth
19:54:39 --- quit: koz_ (Ping timeout: 260 seconds)
19:54:50 --- quit: ACE_Recliner (Remote host closed the connection)
19:55:24 --- join: koz_ (~koz@121.99.240.58) joined #forth
19:59:33 --- join: reepca (~user@208.89.170.250) joined #forth
20:39:06 --- quit: wa5qjh (Remote host closed the connection)
20:43:11 --- quit: Bunny351 (Ping timeout: 276 seconds)
20:44:42 --- quit: Chef_Gromboli (Quit: Leaving)
20:45:11 --- join: wa5qjh (~Thunderbi@175.158.225.192) joined #forth
20:50:20 --- quit: wa5qjh (Ping timeout: 276 seconds)
20:55:07 --- join: wa5qjh (~quassel@175.158.225.192) joined #forth
20:55:28 --- join: leaverite (~Thunderbi@175.158.225.192) joined #forth
21:33:23 --- join: Bunny351 (~Bunny351@p4FD2D6EE.dip0.t-ipconnect.de) joined #forth
21:35:56 --- join: dys (~dys@tmo-081-48.customers.d1-online.com) joined #forth
21:46:09 --- join: roboguy` (~roboguy_@24-143-53-151-static.midco.net) joined #forth
23:08:01 <larsb> GDB wizard anyone?
23:09:45 <larsb> I write my own ELF executable image files.  I want to avoid the complexity of adding symbol information, but I'd like GDB to dig out the symbols from the Forth dictionary.
23:13:11 <larsb> But as far as I can see, there's no way to tell GDB "here's a symbol, it has this name and that value".
23:59:59 --- log: ended forth/17.08.03