< 1742601882 479334 :mtm!~textual@47.202.75.129 QUIT :Ping timeout: 276 seconds < 1742601923 210353 :mtm!~textual@47.202.75.129 JOIN #esolangs mtm :Textual User > 1742606904 135042 PRIVMSG #esolangs :14[[07User:None114]]4 10 02https://esolangs.org/w/index.php?diff=154317&oldid=152942 5* 03None1 5* (+56) 10/* My Esolangs */ < 1742607828 862732 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement < 1742612781 343121 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1742612979 730497 :FreeFull!~freefull@79.186.73.126.ipv4.supernova.orange.pl QUIT :Quit: Lost terminal > 1742614716 820929 PRIVMSG #esolangs :14[[07General blindfolded arithmetic14]]4 10 02https://esolangs.org/w/index.php?diff=154318&oldid=154209 5* 03Stkptr 5* (+3386) 10/* with +, -, * (at least FSM) */ > 1742614835 294800 PRIVMSG #esolangs :14[[07General blindfolded arithmetic14]]4 10 02https://esolangs.org/w/index.php?diff=154319&oldid=154318 5* 03Stkptr 5* (+188) 10/* Relation with Diophantine equations */ < 1742615919 17711 :tromp!~textual@2a02:a210:cba:8500:40b3:acb4:4579:83af QUIT :Ping timeout: 265 seconds < 1742617481 532498 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Do you know if there are issues with optimization with the C compiler if you are storing a capability in a uint64_t variable even though arithmetic is not allowed (and will result in a run time error)? < 1742617660 704513 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like if the machine only has 32-bit words? < 1742617770 723111 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`? capability < 1742617773 548867 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :capability? ¯\(°​_o)/¯ < 1742617818 407047 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(what kind of capability? in what sense is "arithmetic not allowed"?) < 1742617990 381576 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A literal answer might be "no, C doesn't know what a capability is," but that's unfairly strict. < 1742618158 14498 :int-e!~noone@int-e.eu PRIVMSG #esolangs :This may turn into an ABI question very quickly, which is outside of the scope for C, though not for C compilers. < 1742619034 595070 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I described what I mean by "capability"; from the point of the view of the instruction set it is really just a 64-bit value that is tagged in such a way that arithmetic cannot be performed on it; it is called a "capability" due to the operating system. The machine will have 64-bit words since it will be compiled for a specific machine that has this feature. < 1742619094 643402 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but that doesn't explain in what way arithmetic even could break anything, as long as the right values are passed to system calls, or maybe stored in special memory locations < 1742619098 76004 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I mean if the C compiler is not modified, but targets whatever instruction set it is a modification of (probably RISC-V) such that it otherwise remains compatible. < 1742619213 389305 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Performing arithmetic on the values would cause the CPU to result in a trap, so the program will not continue executing (unless the operating system handles the trap and allows the program to continue). It also happens if the program converts it to an array of bytes and then tries to extract the individual bytes; that is also an error resulting in a trap. < 1742619334 789618 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(In an actual program, typedef would probably be used, but I am asking about how the C compiler would handle such a situation if it is not modified to handle it.) < 1742619772 163716 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Would it cause a problem with unaligned memmove? < 1742619990 914179 :int-e!~noone@int-e.eu PRIVMSG #esolangs :So those capabilities have hardware support now? But the compiler is somehow unaware? That sounds... unlikely, those two go together. < 1742620080 325836 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :My intention is in case you are using an existing cross-compiler and cannot modify it for whatever reason. (There are reasons why you might want to modify the compiler other than this too, but sometimes you might want to or have to use existing compilers that you cannot easily modify (even if it is FOSS, it might take too long to modify and maintain it, or too long to compile the compiler).) < 1742620084 267413 :int-e!~noone@int-e.eu PRIVMSG #esolangs :or, like, such capabilities would end up in special registers that are managed with special instructions that you'd use compiler intrinsics or inline assembly for; in the former case the compiler knows; in the latter case, the compiler will document how values are represented in registers passed into your assembly code < 1742620127 833300 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I feel that this question is, simultaneously, way too specific, and too vague. < 1742620340 871671 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :It seems to me that splitting them into individual bytes might be more of a problem than arithmetic would be. There are a few reasons I had for not using special registers, including that you can store them in ordinary memory (except areas that the operating system disallows for this use, such as video memory). < 1742620455 740358 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I think Flex computer does something similar, although it has its own instruction set. (From reading the documentation, it would seem to me that (although the documentation does not actually mention this, as far as I can tell), it is possible for the difference of two pointers to be zero even though they are two different pointers.) (This I am describing is not Flex computer, though.) < 1742620493 273232 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :You may be right that it is too specific and too vague, but I am not sure how to make it better. > 1742625586 552249 PRIVMSG #esolangs :14[[07Amethyst14]]4 10 02https://esolangs.org/w/index.php?diff=154320&oldid=154299 5* 03PrySigneToFry 5* (+998) 10 < 1742627727 979532 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds < 1742627728 48907 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1742627810 649921 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life > 1742628970 718045 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Xtex 5* 10New user account > 1742629164 378621 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 M10 02https://esolangs.org/w/index.php?diff=154321&oldid=154307 5* 03Xtex 5* (+158) 10/* Introductions */ > 1742629312 817790 PRIVMSG #esolangs :14[[07Esolang:Community portal14]]4 10 02https://esolangs.org/w/index.php?diff=154322&oldid=153079 5* 03Xtex 5* (-13) 10/* Other real-time discussion communities */ refresh link < 1742631641 807869 :craigo!~craigo@user/craigo QUIT :Quit: Leaving > 1742636421 764615 PRIVMSG #esolangs :14[[07EchoLang (None1)14]]4 10 02https://esolangs.org/w/index.php?diff=154323&oldid=146239 5* 03PrySigneToFry 5* (+16) 10 > 1742636523 762082 PRIVMSG #esolangs :14[[07Brainfuck 2.014]]4 N10 02https://esolangs.org/w/index.php?oldid=154324 5* 03PrySigneToFry 5* (+4594) 10Created page with "Brainfuck 2.0 is designed by PSTF, it is based on [[EA Script, It's in the code.]] but it didn't costs anything. = Instructions = All commands work on a 30,000-bit tape, a stack, and a counter. == Basics == {| class="wikitable" |+ |- ! Instruction !! Meanin > 1742636577 811577 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=154325&oldid=154308 5* 03PrySigneToFry 5* (+20) 10 > 1742637924 621825 PRIVMSG #esolangs :14[[07Swapfuck14]]4 M10 02https://esolangs.org/w/index.php?diff=154326&oldid=148596 5* 03Rdococ 5* (-142) 10/* Computational class */ < 1742641832 172864 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1742643785 510700 :APic!apic@apic.name PRIVMSG #esolangs :Moin < 1742644947 284275 :mtm!~textual@47.202.75.129 QUIT :Ping timeout: 244 seconds < 1742645100 198522 :mtm!~textual@47.202.75.129 JOIN #esolangs mtm :Textual User > 1742646074 996465 PRIVMSG #esolangs :14[[07User:None114]]4 10 02https://esolangs.org/w/index.php?diff=154327&oldid=154317 5* 03None1 5* (+17) 10 < 1742647165 922539 :FreeFull!~freefull@79.186.73.126.ipv4.supernova.orange.pl JOIN #esolangs FreeFull :FreeFull < 1742648525 516826 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname > 1742648566 672496 PRIVMSG #esolangs :14[[07User talk:Hotcrystal014]]4 10 02https://esolangs.org/w/index.php?diff=154328&oldid=153549 5* 03PrySigneToFry 5* (+196) 10 > 1742650754 241412 PRIVMSG #esolangs :14[[07XD14]]4 10 02https://esolangs.org/w/index.php?diff=154329&oldid=136855 5* 03PrySigneToFry 5* (+138) 10 > 1742650829 732189 PRIVMSG #esolangs :14[[07NH314]]4 10 02https://esolangs.org/w/index.php?diff=154330&oldid=119728 5* 03PrySigneToFry 5* (+55) 10 > 1742651204 480661 PRIVMSG #esolangs :14[[07Talk:Braindrunk14]]4 10 02https://esolangs.org/w/index.php?diff=154331&oldid=139868 5* 03PrySigneToFry 5* (+72) 10/* How many chance will the classic output "Hello, world!"? */ new section < 1742653068 528479 :lynndotpy6!~rootcanal@134.122.123.70 QUIT :Quit: bye bye < 1742653146 334092 :lynndotpy6!~rootcanal@134.122.123.70 JOIN #esolangs lynndotpy :lynn < 1742653775 73712 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1742653865 727391 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : Do you know if there are issues with optimization with the C compiler if you are storing a capability in a uint64_t variable even though arithmetic is not allowed (and will result in a run time error)? ← so there is a CPU sort-of like that which gets unintentionally targeted by existing C compilers – valgrind implements a virtual CPU and it can track extra bits of data about memory, e.g. whether that data is initialised < 1742653926 532890 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in order to work with existing C programs that were written without knowledge of it, it had to allow a number of things that would otherwise not be allowed, e.g. in Valgrind memcheck, arithmetic on uninitialised data is permitted but returns uninitialised results, and copying uninitialised data is allowed, but branching on uninitialised data isn't < 1742653966 707486 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I imagine it wouldn't be too hard to design the sort of capability-locking CPU you want as a Valgrind backend (relative to the other possibilities for implementing it, at least) < 1742653998 707771 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and in practice, most compilers don't optimise copies of machine-word-sized things into anything other than copies (although they may copy through memory or through a vector register) < 1742654008 490215 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because generally that's what's fastest on the CPU < 1742654151 580420 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, I don't think optimisers *guarantee* to not, e.g., spill values by representing them as an arithmetic combination of other known values – they're allowed to do so in theory, just usually don't in practice < 1742654372 710394 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh, https://xkcd.com/3062/ resonates with this in a weird way < 1742654675 254231 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :https://sourceware.org/glibc/manual/latest/html_node/Atomic-Types.html#index-sig_005fatomic_005ft has some vague wording on this: "In practice, you can assume that int is atomic [wrt signal handlers, not threads]. You can also assume that pointer types are atomic; that is very convenient. Both of these assumptions are true on all of the machines that the GNU C Library supports and on all POSIX systems < 1742654681 270239 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :we know of." but that text was written so many years ago that the compilers may have changed since < 1742654730 186390 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think you need a "volatile" to benefit from those guarantees < 1742654751 344237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :otherwise it breaks in situations as simple as reading the same global variable twice < 1742654809 582050 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: ok, but here we're not making a signal handler, we just want to know that the magical integer that zzo mentions is copied as a whole between memory and registers rather than eg. character by character < 1742654964 278458 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though of course the processor will have to follow that tag bit for every word of a vector register separately across all loads and stores for this to work, but I think zzo38 is assuming that the processor does that < 1742654992 60149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, compilers often use over-wide registers for that sort of thing, but don't tend to generate, e.g., XOR swaps < 1742654994 122118 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :because eg. copying a large structure or array can use vector registers < 1742655004 158673 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I think copying a large array can become a call to libc memcpy < 1742655022 258828 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and that may attempt to copy a byte at a time in some situations < 1742655048 432974 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, with the caveat that the compiler requires that the memcpy implementation is a no-op when the from and to address matches, which is not generally true in the C standard < 1742655087 372449 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I think that wording I quoted from the libc manual does try to imply that memcpy doesn't break pointers or ints into smaller pieces < 1742655113 51316 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(they have to be aligned, but C or C++ requires that anyway of these types) < 1742655179 289130 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and if instead of a well-written memcpy you write your own char* loop then of course you don't get such a guarantee < 1742655338 94860 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm how closely does this question tie into the earlier discussion about CHERI? < 1742655491 756532 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that said, I find zzo38's hypothetical quite esoteric. normally you'd either make those capabilities a special type with copy and destroy functions in the library (with possibly compiler support if they're sufficiently magical); or make them similar to unix file descriptors so they're a plain integer but you have to close them explicitly and use extra functions to pass to a different process (except < 1742655497 764314 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :they need not be like unix file descriptors in that they need not have a guarantee that creating a new capability takes the lowest unused number, and they could be in a different namespace than ordinary file descriptors); or if you really want plain data then you'd make it wider, sized between 16 and 64 bytes, and filled with random data each time you create, then they can be bytewise copied fine. < 1742655650 786549 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I've been trying to get gcc to optimise a copy of an int array followed by a char array into one big memcpy, but it refuses to do so < 1742655666 702618 :int-e!~noone@int-e.eu PRIVMSG #esolangs :FWIW I wish zzo38 had explained the tag bit detail a bit sooner. It makes the question much clearer. < 1742655678 776976 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :clang will generate a call to libc memcpy, though < 1742655707 367073 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: is it in code where you aren't allowed to write past the end of the char array and that end needn't be aligned? < 1742655712 89795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but oddly it generates two calls for the int-then-char < 1742655730 684491 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes, if gcc is allowed to write past the end (e.g. struct padding) then it does < 1742655820 243025 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually the compilers are showing a big lack of joined-up-thinking here < 1742655841 455950 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if I have a struct with two array fields, and copy the struct, it compiles to one memcpy – if I copy both fields, it compiles two two memcpies, even though that is equivalent < 1742656067 430799 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strange < 1742656078 156428 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is true in both gcc and clang < 1742656097 215004 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, clang uses a call to libc memcpy and gcc uses the processor's memcpy intrinsic < 1742656116 309810 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(modern x86 and x86-64 have a memcpy routine in microcode that you can call into) < 1742656168 780645 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"call" meaning `rep movs[size]`? < 1742656171 214678 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it isn't immediately clear whether the processor's microcoded memcpy is faster or slower than one running in software – the issue is that the branch predictor cares about the memory addresses of branches in order to remember their histories < 1742656176 819341 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: yes < 1742656179 831948 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sure, gcc has the right to use either a built-in memcpy that it can optimize inline or call a memcpy that libc or you provide < 1742656202 425900 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so if the whole thing is written as a single rep movsq then the branch predictor has nowhere to store its memory of how the copy branched < 1742656244 161635 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Naively... it /could/ attach it to the rep movs if it wanted to? < 1742656257 566507 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: there are multiple branches within the microcode, typically < 1742656265 23913 :int-e!~noone@int-e.eu PRIVMSG #esolangs :right < 1742656334 684386 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :modern CPUs also have predictors for not just where branches go, but whether an instruction is a branch or not < 1742656349 682905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in order to be able to speculate past the "branch" before the instruction is even decoded < 1742656404 419934 :int-e!~noone@int-e.eu PRIVMSG #esolangs :heh then again you get extra speculation opportunities for `rep movs` because you know a lot of registers that won't change < 1742656415 712836 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I mean if you want to < 1742656419 708459 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :AMD got hit with a new Spectre variant semi-recently in which the processor was trained into expecting that a return instruction would actually be a branch instruction, sending the speculative execution off to a gadget despite the existing Spectre mitigations < 1742656444 691742 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(hmm it's not even speculation then, just out-of-order execution) < 1742656458 458966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think I can reasonably get an efficient (i.e. implemented with aligned vector moves) memcpy down to just two branches < 1742656463 666112 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one which special-cases short inputs and one for the loop < 1742656487 136984 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(for long inputs you unconditionally copy the first vectorful of data using misaligned vector moves, likewise the last vectorful, and then just copy the aligned portion in between with a loop) < 1742656505 14028 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: sure, the cpu wants to predict the target of the ret instruction, and I think it uses both the normal branch predictor for that and some special mechanism just for rets. that's why they even tell you to use a two-byte ret instead of the one-byte near ret. < 1742656512 769350 :int-e!~noone@int-e.eu PRIVMSG #esolangs :memcpy has to deal with unaligned cases though and that'll be a few extra jumps? < 1742656547 402532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: the two-byte ret case doesn't apply any more – when it did, the reason was that the branch predictor had a limit for how often in bytes it could make predictions < 1742656556 120529 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so if you had a jump two executed bytes in a row, it would cause trouble < 1742656570 793885 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I guess you can try extra arithmetic where you use a bit-wise or of the pointer arguments, mask the bottom bits, then add the length and compare that... < 1742656583 915518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: no, the idea is you unconditionally copy the first (e.g.) 32 and last 32 bytes, using unaligned copies < 1742656584 960646 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: you know https://www.agner.org/optimize/#asmlib has an optimized memcpy written by someone who understands optimizing for different x86 cpus right? he can specialize it for different processor implementations because they behave differently < 1742656589 722805 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then copy all the aligned 32-byte blocks in between < 1742656626 571949 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: you still have to check that the alignments match < 1742656629 992347 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this works for any input that's at least 32 bytes long regardless of alignment (although if source and destination have different alignments you have to misalign either the reads or the writes, but you'd probably do that anyway) < 1742656647 819960 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: no you don't, if the alignments don't match the you still want unaligned reads and aligned writes < 1742656662 523632 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so you can always just do aligned writes regardless if the alignment matches < 1742656680 202549 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so I think the two reasonable ways to do it are either a) unaligned reads and aligned writes, or b) aligned reads, a shuffle/permute, and aligned writes < 1742656701 478736 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: but there are special instructions for aligned reads which might be a tad faster? < 1742656708 165367 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b) isn't generally used, but it could in theory be faster < 1742656719 660449 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: those instructions aren't faster, they just trap given unaligned inputs < 1742656735 595724 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :aligned reads are faster than unaligned reads *but* this is true regardless of whether you use the aligned or unaligned read instruction < 1742656758 312098 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you don't pay for an unaligned read unless the input actually is misaligned, regardless of which instruction you use < 1742656803 552935 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is talking about modern x86, in which unaligned reads are actually as fast as aligned as long as they don't cross a cache line boundary) < 1742656821 545290 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I guess that makes sense. But yeah it sounds like it might vary between architectures. < 1742656833 350348 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(but normally when doing unaligned reads in a loop, you amortize the misalignment penalty across all the reads rather than treating the crossing and non-crossing ones differently) < 1742656858 492973 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I don't think shuffle/permute is ever worth for that, because if you must do an unaligned copy then the x86 processor optimizes the unaligned read better than you can with shuffles; however, you can argue that sometimes when you have written the source recently but won't read the destination for a while you may want to do an aligned read and unaligned write to reduce latency < 1742656876 362565 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, for 16-byte reads, those cross boundaries ¼ of the time when misaligned so you approximate by saying they're 25% slower (the boundary-crossing read runs at half speed) < 1742656885 597328 :int-e!~noone@int-e.eu PRIVMSG #esolangs :especially if you find an architecture that didn't start out with supporting unaligned reads for everything the way x86 did < 1742656927 453600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so the reason it might help is that the unaligned read is reading two cache lines, then the next read is reading the same cache line again, so you have 1 more memory access < 1742656954 752273 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, that access is to L1 (as you only just read it) which might allow it to beat the arithmetic < 1742657011 652563 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, I think it can beat the unaligned read when the processor can do store-load forwarding because you just stored, but I think in that case an aligned read and unaligned write won't be worse than trying to shuffle < 1742657041 973024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oddly, I discovered recently that x86-64 has two different misaligned-vector-read instructions nowadays (MOVDQU and LDDQU) – LDDQU is apparently faster for misaligned reads in cases where the memory isn't written to in the near future, MOVDQU if it is < 1742657043 706231 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :although... < 1742657046 571948 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. I see plenty of room for zzo38's plan to go wrong. Like... would a CPU really add support for those tags to all vector registers, if it has them? That sounds like a big ask... < 1742657072 849233 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, I concede, I think there might be some rare case when a vector byte shift is faster < 1742657091 551155 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I don't think I'd ever write that, but if you're very good at optimizing you could < 1742657091 682427 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not entirely sure what's going on microarchitecturally to cause that sort of performance difference < 1742657108 955817 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the real question here is "what is the copy bound by" < 1742657126 455368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if either end of the copy is not in L1 then I think the bottleneck will be L2/L3/main memory speed < 1742657153 326600 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes < 1742657154 512363 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the manually-aligned and unaligned-read versions will run at the same spee < 1742657156 59175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* speed < 1742657217 426232 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and if you do copies of short ranges (which is very common in real code) then you can easily mess up and then bound will be the cost you're imposing on instruction decoding caches by using a more complicated code than you should have < 1742657218 914619 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a cache-line-boundary-crossing L1 read is the same speed as an aligned L2 read, so the cost of the misaligned read doesn't matter as soon as you hit L2, that would be a good reason to do the misaligned read version < 1742657235 454868 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so memcpy entirely within L1 is the interesting case < 1742657282 946397 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :incidentally, is L3 slower or faster than correctly prefeteched main memory nowadays? e.g. if you're just reading at sequentially increasing addresses, does hitting main memory rather than L3 even matter < 1742657340 513136 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://stackoverflow.com/questions/47425851/whats-the-difference-between-mm256-lddqu-si256-and-mm256-loadu-si256 says there's no difference except for Pentium 4? < 1742657343 582907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's a program I've been performance-optimising for ages, and discovered the hardware prefetcher being cleverer than I expected < 1742657438 594877 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ooh! so the difference is not "will write it soon" but "recently wrote it", and the instructions had different store-forwarding behaviour once < 1742657524 324683 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, the store-load-forwarding is why you may want aligned reads even if it means you have to do either unaligned writes or vector shifts, even though unaligned writes are usually a bad idea, but if you won't read the destination for a while then it might not matter too much < 1742657543 116682 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm so I guess the change is that they incorporated all the opitimzations into movdqu for the common case (cached write-combining memory) < 1742657553 154472 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I don't really know if it's ever really worth, I just can't exclude that it's not worth < 1742657577 65513 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: isn't the normal sort of cache called "write-through" by Intel? write-combining is something else, and rarely used < 1742657584 936472 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm not sure I even want to know, I don't think I want to optimize code that involves unaligned stuff (like byte-string handling for network communication) to this level < 1742657675 135701 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: the case that got me looking at this was writing a compiler that's operating on data that it can't prove aligned, even though it logically should be < 1742657691 85368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the same sort of thing as "memcpy where you don't know where the pointer comes from" < 1742657722 249504 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :unrelated question. in libcurl for HTTP/HTTPS, how do I tell the library that it should close persistent connections now because I won't be starting a new request for a while and they'll be too old to reuse by then anyway? the documentation is unclear. I still want to keep other data (SSL and DNS caches) between the requests, just not the network connections. < 1742658033 18122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, in practice, I think most mallocs don't guarantee cache-line alignment when allocating large amounts of memory < 1742658056 397221 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :logically they should – there's basically no cost to doing so and it could help in some situations < 1742658066 66757 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(there is cost for small allocations, which would be a reason not to do it there) < 1742658291 573107 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :these days all the malloc libraries have an API for aligned allocations and I think they all support 64-byte alignment properly because that's a common thing to ask for, so if you want cache line alignment you can get it < 1742658536 164565 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hold on, that's not true < 1742658623 343939 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hold on, that's not true, glibc doesn't seem to expose an api for aligned realloc < 1742658790 825067 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: I guess we're both wrong, the normal operation for RAM is write-back. Now I'll have to read what write-combining actually means to Intel. Write-through means all writes by the CPU end up as individual bus or memory transactions going out of the CPU. Write-combining relaxes that, but how much... < 1742658974 450949 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I actually checked how my own PC's RAM is currently configured. Which was less obvious than I thought it would be; /proc/mtrr doesn't list the default, only the special regions...) < 1742659011 317412 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(but rdmsr 0x2FF works) < 1742659108 174518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ah right, yes, write-back < 1742659145 625099 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my mental model for how write-combining works is that it has its own separate very small cache that is only used for writes, but I don't know whether that's correct or not < 1742659218 295226 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :non-temporal writes are write-combining even on regular memory, that's what makes me think it works like that < 1742659245 558803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. < 1742659565 476983 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"13.3.1 Buffering of Write Combining Memory Locations" is where it goes into details of operation < 1742659763 549900 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Also MTRRs are not the end of the story... there's a page attribute table mechanisms that I've never heard of. Can I inspect those? Hmm. < 1742659894 558410 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I can, it's exposed in the debug-fs, cf. https://wiki.gentoo.org/wiki/MTRR_and_PAT < 1742660029 72706 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and for me it only has entries in the lower 4GB, outside of RAM, so the default write-back should still win. < 1742660054 329397 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but there are write-combining regions in there, presumably for the GPU < 1742660115 666378 :int-e!~noone@int-e.eu PRIVMSG #esolangs :this was... a fun rabbit hole < 1742660650 37415 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Actually let me retract the vector register remark regarding tracking tag bits... you're already going to maintain those tag bits in caches and RAM, might just as well go the extra mile. < 1742663191 201322 :tromp!~textual@2001:1c00:3487:1b00:e1c2:84b0:caab:9b02 JOIN #esolangs * :Textual User > 1742666517 854180 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move_redir10 02 5* 0347 5* 10moved [[02NH310]] to [[NH]] over redirect > 1742666517 870132 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete_redir10 02 5* 0347 5* 1047 deleted redirect [[02NH10]] by overwriting: Deleted to make way for move from "[[NH3]]" > 1742666577 4766 PRIVMSG #esolangs :14[[07NH14]]4 10 02https://esolangs.org/w/index.php?diff=154334&oldid=154332 5* 0347 5* (-110) 10 < 1742666648 800444 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Tangent to the discussion's multiple points: how do folks feel about SWAR/broadword techniques? If we're storing a relatively small value with a relatively large number of tag bits, then we might end up with values that are 4+4, 8+4, or 8+8 bits wide. < 1742668333 374399 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: so most "tagging for security/safety", like CHERI uses and like zzo38 is using with capabillities, generally only needs to be done on wide values < 1742668368 785434 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :tagging small values is useful for things like carry bits, but normally SWAR-style vectorisation doesn't store carry bits (which is something that has caused some complexity for me recently) < 1742668419 344386 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can sometimes check for carry by comparing the one of the inputs to an addition to the output, to see if the result was lower than an input (IIRC it can't be between, so you can compare to either input safely) < 1742668441 934060 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, unless I'm missing something, AVX2 has neither carry bits nor unsigned integer comparisons < 1742668474 744367 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the "compare to an input" doesn't work to check overflow for signed addition < 1742669072 296713 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait AVX2 doesn't have unsigned comparison? let me check that < 1742669107 838273 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I thought even SSE2 had unsigned comparison < 1742669540 491645 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :huh, you're right, it takes three instructions to unsigned compare in SSE2. only AVX512 adds an instruction for it. < 1742669546 307498 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I totally forgot this < 1742669873 806 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :nope, only *two* instructions for an unsigned compare: PMINU[BWDQ] followed by PCMPEQ[BWDQ] < 1742671408 484818 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think it's still three – that implements ≥ / ≤ not > / < < 1742671564 43275 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and you need an extra instruction to invert the sense of the result < 1742671730 195754 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: kind of, but you usually don't need an extra instruction to invert a boolean vector, you can almost always just merge it for free in the next instruction that uses it (possibly also with giving inverted result) < 1742671782 862943 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and this is easy to implement in library level with an inverted vector type and overloaded functions < 1742671804 36492 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, is that why PANDN exists in addition to PAND? < 1742671827 775845 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(there isn't a PORN, maybe they didn't like the mnemonic) < 1742671894 176883 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, this way PAND, PANDN, POR, PXOR cover all the boolean operations < 1742671951 178597 :mtm!~textual@47.202.75.129 QUIT :Ping timeout: 252 seconds < 1742671953 452637 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I partly implemented this inverted scheme in the SSE4_1 vector library for work back when not every computer that I was working with had AVX yet < 1742672018 587398 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I didn't completely implement it because there are operations that I didn't add, but while I was the only user it would be easy to just add more functions as I need them < 1742672048 832442 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and I indeed added some in later versions < 1742672064 213530 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :this is in C++ < 1742672243 20039 :mtm!~textual@47.202.75.129 JOIN #esolangs mtm :Textual User < 1742672309 463603 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean PAND, PANDN, POR, PXOR cover all the two-input *bitwise* operations if you allow that sometimes the output is complemented < 1742672396 610621 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :one use is a PAND, PANDN, POR sequence for componentwise branchless if-then-else conditional < 1742672398 140886 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess i'm thinking mostly of when you want to use the boolean as an if conditional (but in a SIMDy way, i.e. you evaluate both sides) < 1742672412 535897 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in that case having an inverted result might not be what you want < 1742672591 182127 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, sometimes you need to insert an extra invert. < 1742672633 893682 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1742673985 709870 :APic!apic@apic.name PRIVMSG #esolangs :cu < 1742674342 561049 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, yet another different question. do you think I can still claim that sqlite3 is the second most installed software library in the world? I talked about this at some point on esoteric, but that was years ago and something like that could change during the years. < 1742674379 159164 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in particular, do Windowses come with a copy of tzdb, or do they have an entirely different implementation? because maybe tzdb is ahead of sqlite3 > 1742674610 912639 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=154335&oldid=154325 5* 03Buckets 5* (+14) 10 < 1742674646 230949 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and I guess the netlib code for decimal formatting of floating point may be a candidate too < 1742674682 836360 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I want this for my cv or job interviews so it doesn't have to be strictly true, but it at least has to be plausible enough that a potential employer can believe it > 1742674698 456023 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=154336&oldid=154309 5* 03Buckets 5* (+13) 10 > 1742674737 635682 PRIVMSG #esolangs :14[[07Go back14]]4 N10 02https://esolangs.org/w/index.php?oldid=154337 5* 03Buckets 5* (+1286) 10Created page with "Go back is an Esoteric programming language created by [[User:Buckets]] in 2020. {| class="wikitable" |- ! Commands !! Instructions |- | #[] || Infinite Loop/Start. |- | [] || Infinite Loop. |- | +m || Change the current Loop by + m. |- | -n || Change the current Loop b < 1742674861 840177 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh, https://sqlite.org/mostdeployed.html now talks about this explicitly < 1742674875 889272 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it says "probably one of the top five" < 1742674907 471528 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and "our best guess is ... second most deployed" < 1742674943 156260 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, then I can absolutely round that up to second most deployed in a job interview, regardless of tzdb > 1742674995 527437 PRIVMSG #esolangs :14[[07Esorn14]]4 M10 02https://esolangs.org/w/index.php?diff=154338&oldid=154315 5* 03Buckets 5* (+1) 10 > 1742675069 654827 PRIVMSG #esolangs :14[[07Esorn14]]4 M10 02https://esolangs.org/w/index.php?diff=154339&oldid=154338 5* 03Buckets 5* (+1) 10 > 1742675217 737275 PRIVMSG #esolangs :14[[07Happy14]]4 M10 02https://esolangs.org/w/index.php?diff=154340&oldid=153949 5* 03Buckets 5* (+1) 10 > 1742675460 535478 PRIVMSG #esolangs :14[[0714]]4 M10 02https://esolangs.org/w/index.php?diff=154341&oldid=154304 5* 03Buckets 5* (-1) 10 < 1742675666 778992 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :If capabilities are required to be aligned, then it is simpler; each general-purpose register needs one tag bit and each eight bytes of general-purpose RAM needs one tag bit, and you don't have to worry so much about broken apart copies, etc, although there is still the consideration of doing unaligned copies of smaller data. < 1742675706 159496 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :However, I think there are some reasons why you might want unaligned capabilities; this is more difficult but I think still might be able to be done. < 1742675731 250487 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :With unaligned capabilities, each general-purpose register has one tag bit and each byte of general-purpose RAM has two tag bits. < 1742675825 454407 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Copying blocks of memory into a place that will overwrite part of a capability should be safe (although there are a few considerations having to do with virtual memory), but it will have to ensure that ythe first byte of the source is not a non-first byte of a capability and the last byte of the source is not a non-last byte of a capability. > 1742675852 648057 PRIVMSG #esolangs :14[[07Happy14]]4 10 02https://esolangs.org/w/index.php?diff=154342&oldid=154340 5* 03Ractangle 5* (+0) 10 > 1742675873 620502 PRIVMSG #esolangs :14[[07Happy14]]4 10 02https://esolangs.org/w/index.php?diff=154343&oldid=154342 5* 03Ractangle 5* (+0) 10 > 1742675886 77176 PRIVMSG #esolangs :14[[07BrainWrite14]]4 M10 02https://esolangs.org/w/index.php?diff=154344&oldid=96575 5* 03Buckets 5* (+220) 10 < 1742675899 364184 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : ok, yet another different question. do you think I can still claim that sqlite3 is the second most installed software library in the world? I talked about this at some point on esoteric, but that was years ago and something like that could change during the years. ← I would have guessed zlib as most-installed, although I forgot about tzdb < 1742675931 946900 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, the page you link also mentions zlib > 1742675983 126022 PRIVMSG #esolangs :14[[07Array?14]]4 10 02https://esolangs.org/w/index.php?diff=154345&oldid=149392 5* 03Ractangle 5* (-6) 10/* Implementation */ < 1742676000 715469 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, I also assume that zlib has more copies than sqlite3 > 1742676008 533786 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03Ractangle 5* 10moved [[02Array?10]] to [[UNAI]] > 1742676008 572354 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03Ractangle 5* 10moved [[02Talk:Array?10]] to [[Talk:UNAI]] < 1742676029 424260 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :libpng is also mentioned on the sqlite page, although I would expect libpng to depend on zlib < 1742676039 85582 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in which case it couldn't reasonably beat it < 1742676044 863520 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zlib will eventually lose out as more modern compression libraries that also have their own implementation of zlib take it over, but that'll take like decades > 1742676053 577566 PRIVMSG #esolangs :14[[07UNAI14]]4 10 02https://esolangs.org/w/index.php?diff=154350&oldid=154346 5* 03Ractangle 5* (-7) 10 < 1742676115 744501 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not convinced, most computers with a more modern compression library will still need zlib for things that have it as a dependency < 1742676144 606944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I used zlib as a dependency of NH4 on the basis that the user was very likely to have a copy already < 1742676159 571841 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah < 1742676167 204670 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm… now I'm thinking about the way that on Windows, programs are expected to ship their own libcs < 1742676205 395356 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Some programs might have different implementations of DEFLATE < 1742676218 912511 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it makes it very difficult to use open-source compilers on Windows, because the libc needs to link against OS internals which aren't widely known (I think they might be publicly available but am not sure) and the Microsoft-provided libcs have license conditions preventing you linking against them with your own non-MSVC compilers > 1742676221 280337 PRIVMSG #esolangs :14[[07UNAI14]]4 10 02https://esolangs.org/w/index.php?diff=154351&oldid=154350 5* 03Ractangle 5* (-91) 10/* Commands */ > 1742676244 243830 PRIVMSG #esolangs :14[[07UNAI14]]4 10 02https://esolangs.org/w/index.php?diff=154352&oldid=154351 5* 03Ractangle 5* (+0) 10/* Hello, world! */ < 1742676258 485673 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :mingw works by linking against an OS-provided library which has a lot of libc functionality in it, although it isn't a standard libc and not all the functions in it obey the C specification < 1742676271 910106 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and Microsoft say not to do that, but don't offer reasonable alternatives > 1742676273 458084 PRIVMSG #esolangs :14[[07UNAI14]]4 10 02https://esolangs.org/w/index.php?diff=154353&oldid=154352 5* 03Ractangle 5* (-2) 10/* Cat program */ < 1742676291 203597 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Will ReactOS be helpful for making open-source compilers on Windows? < 1742676313 222922 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I don't understand, aren't you just supposed to use the libc that comes with MSVC, even if it is not compliant with the C specification in a lot of ways? < 1742676319 950398 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: that's an interesting point, actually – ReactOS/Wine's shared codebase would probably a useful target to develop against if writing a Windows libc from scratch < 1742676395 428669 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: you can't do that legally, but I think you have confused two libcs – there is the libc that comes with MSVC which is mostly specification-compliant, and which you can distribute with your programs but can't legally link against with non-MSVC, so mingw can't use it – and there is the libc-like library which comes with Windows (called MSVCRT.DLL) which is not very standards-compliant < 1742676408 750389 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(yes, it's confusing that the one called MSVC is the one that doesn't come with MSVC) < 1742676430 71719 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: you can't ship that MSVC, but can't you link to it and have the user install the library separately downloading it from Microsoft if it doesn't ship with Windows? < 1742676469 469276 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm very likely confused about how all this works < 1742676594 244776 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also for just the operating system interfaces, aren't they in a separately library that you can link to without linking to any libc-like thing? < 1742676613 440537 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes but the documentation for that is hard to find < 1742676623 490703 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think that's what Microsoft's "official" suggestion is, but AFAICT nobody has actually done that < 1742676638 480551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(i.e. "if you're writing your own compiler you don't get to leech off our libc") < 1742676662 760752 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder whether any of the existing Linux/Unix libcs works on Windows, using Windows kernel interfaces < 1742676668 489274 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :what does the clang C and C++ environment that zig distributes these days do? < 1742676742 691097 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: found it: "Distribution of the Visual C++ Runtime Redistributable package, merge modules, and individual binaries is limited to licensed Visual Studio users and is subject to such License Terms." < 1742676767 750886 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so either the developer or the end user would need a Visual Studio license < 1742676792 860402 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I do have a Visual Studio license, but for a computer that is no longer operational < 1742676808 895940 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: that says "distribution". you can still link to it, and have the user download it from microsoft, can't you? like with microsoft's fonts < 1742676860 871802 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe? this is the point where I would start to not trust a programmer's interpretation of the law < 1742676897 690129 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean, all this nonsense about windows being hard to develop to is part of why I prefer to develop for linux rather than windows. It's not even just libc directly, but that many other programmers find windows development difficult and so don't port their libraries to windows in a convenient form, so anything I try will run into a dependency being hard to use. Or the dependencies are available, but they < 1742676900 900162 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would be incompatible with the GPL (which only lets you link to closed-source system libraries in certain circumstances, and this isn't one of them) < 1742676903 698853 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :are for different pseudo-architectures on windows, like they use different libcs or compilers, and I can't link them together. < 1742676920 886438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I agree, although Windows is less hostile to develop for than Mac OS X nowadays < 1742676941 370761 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Apple have lots of rules for developers to follow, which wouldn't be as bad if they didn't keep changing < 1742676967 925496 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and game consoles are even worse, sure < 1742676986 387997 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but OS X just never came up, whereas I use Windows for work all the time, so I do encounter that problem < 1742677001 90462 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I haven't tried to develop for Android but a former coworker did, I'd put it somewhere around the Windows level of difficulty < 1742677032 41125 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least Windows can be cross-compiled onto relatively simply, meaning that the only real problem is the dependencies < 1742677058 33254 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :exactly, needing a visual studio license as a developer isn't a problem if it's for work < 1742677065 140442 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :BSD is easy to develop for, just as good as Linux < 1742677074 399506 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I don't want to have to spend time porting every dependency < 1742677133 350517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I haven't targeted many other things – some bare-metal microcontrollers where the major issue is that the toolchains are usually terrible < 1742677143 19499 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like most potential dependencies are well-written and should be possible to port, but I shouldn't have to < 1742677161 340686 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of them, the officially supported compiler was an old version of gcc that had been patched to call out to a separate executable to see whether you'd paid for a license < 1742677184 130603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is not technically a GPL breach because nothing was preventing you patching it back again, but they were hoping that people wouldn't go to the trouble of recompiling < 1742677221 407575 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, I don't care too much about the bare-metal microcontrollers, but they happen to be useful in that a lot of the rust and zig community do care about such uses, and that makes rust and zig get more attention and better development even for windows or linux < 1742677228 63575 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(or you could just replace the separate executable with your own executable that implemented the same API) < 1742677272 653840 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most of my microcontroller development was done in asm, though < 1742677287 201742 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, shapez the game is following that model: they have a (cheap) payed licensed version sold on Steam and an open source version where you have to do some slight inconvenience to compile it for yourself < 1742677295 110626 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because I was working with microcontrollers too small for most compilers to be able to target them, as their runtimes wouldn't fit < 1742677345 770723 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they had substantially less than a kilobyte of RAM < 1742677356 161266 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and a few kilobytes of flash memory to store the program < 1742681696 385981 :tromp!~textual@2001:1c00:3487:1b00:e1c2:84b0:caab:9b02 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1742681845 4587 :tromp!~textual@2001:1c00:3487:1b00:e1c2:84b0:caab:9b02 JOIN #esolangs * :Textual User < 1742684349 97030 :tromp!~textual@2001:1c00:3487:1b00:e1c2:84b0:caab:9b02 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1742684445 524586 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I had seen many requests from different IP address and user-agents that do not seem to be legitimate, and had read that apparently they are LLM scraping that are badly implemented. < 1742684483 30775 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I had seen, and also had some ideas, about how to work against it or how to stop it. Will the use of a EICAR test file help at all? < 1742684650 683790 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Can redirects be used to confuse them? < 1742684711 32748 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(possibly redirects to http://127.0.0.1/ if that is able to be usable to control anything?) < 1742684992 295574 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: there are lots of different badly implemented scrapers out there < 1742685009 665051 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and no consensus about how to deal with them < 1742685114 36943 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :They all seem to claim to be Mozilla-based, and use different IP addresses for every request (possibly with the exception of redirects, as far as I can tell) < 1742685146 40595 :alec3660!~quassel@user/alec3660 QUIT :Quit: https://quassel-irc.org - Chat comfortably. Anywhere. < 1742685175 440507 :alec3660!~quassel@user/alec3660 JOIN #esolangs alec3660 :alec > 1742685331 645539 PRIVMSG #esolangs :14[[07Countup14]]4 M10 02https://esolangs.org/w/index.php?diff=154354&oldid=101775 5* 03Buckets 5* (+2) 10