00:00:00 --- log: started forth/17.12.28 01:01:41 --- quit: gravicappa (Remote host closed the connection) 01:11:06 endersending, looks like there's no valid forth op code where that address is. If it's a prom them something is giving you the wrong address. 01:35:02 --- join: dys (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) joined #forth 02:02:50 --- quit: proteus-guy (Ping timeout: 240 seconds) 02:19:12 --- quit: dys (Ping timeout: 250 seconds) 02:23:04 --- join: dys (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) joined #forth 02:36:44 --- join: proteus-guy (~proteus-g@2405:9800:bc10:1ca:20c7:fab6:8ca6:f9dd) joined #forth 02:37:30 --- quit: nighty- (Quit: Disappears in a puff of smoke) 02:44:56 --- join: gravicappa (~gravicapp@h62-133-162-38.dyn.bashtel.ru) joined #forth 02:55:50 --- quit: gravicappa (Ping timeout: 248 seconds) 03:55:02 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:28:47 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 04:43:45 --- join: [1]MrMobius (~MrMobius@h8.71.186.173.dynamic.ip.windstream.net) joined #forth 04:44:46 --- quit: MrMobius (Ping timeout: 272 seconds) 04:44:46 --- nick: [1]MrMobius -> MrMobius 04:59:42 --- join: gravicappa (~gravicapp@h62-133-162-246.dyn.bashtel.ru) joined #forth 05:00:47 reepca, not sure what your criteria are but my plan (haven't done it yet beyond a small proof of concept) is to compile words as 16-bit addresses, and then mmap shared libs aligned to 64k boundaries 05:02:42 then there will be a farcall word preloaded in each 64k block which reads a 32-bit or 64-bit address from the execution stream, preloads the IP with the high-order bits, and vectors to the other module 05:03:32 so at any given time the high-order bits are preloaded with the shared lib's runtime address and NEXT just loads the bottom 16 bits from the next cell in a word 05:03:48 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 05:04:40 and then of course you'd have to have a relocation table to fix up those addresses passed to farcall 05:08:01 in fact maybe that could be some kind of token-based thing: a farcall is compiled as the 16-bit farcall xt followed by a 16-bit token and then a 16-bit address, where the token part is an index into a table of the higher-order address bits and that's what gets patched by the relocation fixup 05:09:14 the other downside is that the core word would either have to be referenced by farcall, which is bloaty, or always duplicated in the shared libs, which feels redundant 05:10:08 and of course it also means no one module can exceed 64k 05:35:09 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 06:46:18 --- join: [1]MrMobius (~MrMobius@h8.71.186.173.dynamic.ip.windstream.net) joined #forth 06:48:23 --- quit: MrMobius (Ping timeout: 256 seconds) 06:48:23 --- nick: [1]MrMobius -> MrMobius 07:53:53 --- join: Gromboli (~Gromboli@static-72-88-80-103.bflony.fios.verizon.net) joined #forth 09:16:03 --- quit: ncv (Ping timeout: 255 seconds) 09:39:39 --- quit: dys (Ping timeout: 252 seconds) 10:09:48 zy]x[yz: I'm not sure what my criteria are either - I just know that people on the internet say shared libraries need to be position-independent, and I'm curious about making shared libraries with forth. And as far as I can tell, by "position-independent" they mean "works if you copy it anywhere, no fixups", apparently because fixups in position-independent code defeat the purpose and make it impossible to actually share the one copy in 10:09:48 memory. I've been trying to understand how this stuff fits together lately, but the ELF specification is not very newbie-friendly and the wikipedia articles aren't sufficiently detailed. Or there are fundamental concepts I'm just not "getting". 10:10:53 yeah, your point about not being able to share one copy in memory is why I added the idea of fixups going into a table that could be in another section 10:12:26 another way to do it is to compile to a relative-addressed threaded code 10:12:36 but that makes for a more expensive inner interpreter 10:12:59 or subroutine-threaded with relative jumps 10:13:10 oh yeah 10:14:03 that's basically how C does it: I think all -fpic does is guarantee that all jumps and calls will be relative 10:14:31 well, maybe s/ all// 10:16:45 Hm, so there's no way to do position-independent with interpretive threading methods without a speed penalty? 10:18:02 not that I know of, but I don't claim to be any expert 10:18:24 same here, I have no idea what relative-access features even x86 or x86-64 supports 10:18:27 hmm.. COMPILEing Forth code to be relative only might work by assuming: new_ip := current_ip + code_address. 10:19:21 not that immediatley come to mind. hm. 10:19:26 so basically an extra ADD instruction in $NEXT I presume. 10:19:45 yeah, it makes your next about 50% more expensive 10:19:55 --- join: dys (~dys@tmo-101-161.customers.d1-online.com) joined #forth 10:22:27 $NEXT looks like JMP [wip++], yes? 10:23:03 x86-64 supports rip-relative 10:23:53 do you have enough code that it is even worthwhile sharing between processes? 10:25:42 i mean, if you only have some kB, you can just generate position-dependent code per process too 10:27:23 can you still do dynamic linking that way? I don't have a good idea what the hard requirements for dynamic linking are. 10:31:25 they 10:32:26 they're os-dependent, but you can definitely do as zy]x[yz suggested with a fixup table for the symbols you export, but JIT the code in each process instead of having it baked into the .so 11:46:31 --- quit: gravicappa (Ping timeout: 248 seconds) 15:08:47 --- quit: groovy2shoes (Remote host closed the connection) 15:11:47 --- join: [1]MrMobius (~MrMobius@h8.71.186.173.dynamic.ip.windstream.net) joined #forth 15:13:00 --- quit: MrMobius (Ping timeout: 268 seconds) 15:13:00 --- nick: [1]MrMobius -> MrMobius 15:34:40 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 15:38:49 --- join: wa5qjh (~Thunderbi@freebsd/user/wa5qjh) joined #forth 15:39:43 --- quit: wa5qjh (Read error: Connection reset by peer) 15:46:31 --- quit: Zarutian_PI (Read error: Connection reset by peer) 15:46:42 --- join: Zarutian_PI (~3.1415@173-133-17-89.fiber.hringdu.is) joined #forth 16:05:47 --- join: [1]MrMobius (~MrMobius@h84.166.28.71.dynamic.ip.windstream.net) joined #forth 16:07:50 --- quit: MrMobius (Ping timeout: 240 seconds) 16:07:50 --- nick: [1]MrMobius -> MrMobius 17:11:23 --- quit: dddddd (Remote host closed the connection) 17:21:20 --- quit: dys (Ping timeout: 240 seconds) 17:37:21 --- join: Zarutian_PI2 (~3.1415@173-133-17-89.fiber.hringdu.is) joined #forth 17:37:21 --- quit: Zarutian_PI (Read error: Connection reset by peer) 18:48:05 proteus-guy, i just say your comment from the other day. i gave up on the card and bought a new one, since i dont have enough expierence with openboot anf forth to load a new firmware ontop 18:53:08 https://muchassemblyrequired.com/game.php guys, check this 18:53:32 its a online game using 8086 like assembly to drive your robot 18:53:51 i was thinking if it could be install a tiny forth? 18:54:19 crc: maybe could use your nagro vm to replace that :D 18:55:20 yunfan: I'll take look at that tomorrow 18:58:21 crc: ok 18:58:44 crc: i was very intersting of making it as a multi player online game :D 21:55:36 --- join: deep-thought (~event-hor@2001:8003:f064:400:f66d:4ff:fe58:ff4b) joined #forth 21:55:53 --- quit: Gromboli (Quit: Leaving) 22:21:33 --- join: gravicappa (~gravicapp@62.133.162.208) joined #forth 22:24:19 --- part: deep-thought left #forth 22:58:35 --- quit: endersending (Ping timeout: 268 seconds) 23:23:23 --- join: wa5qjh (~quassel@175.158.225.199) joined #forth 23:23:23 --- quit: wa5qjh (Changing host) 23:23:23 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 23:24:42 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 23:59:59 --- log: ended forth/17.12.28