log☇︎
253600+ entries in 0.167s
mircea_popescu: no dude. the reason the disease perpetuates itself is the functionally illiterate product of the stunted intellectual life in the colonies ; whereby there's this outpour of idiots who imagine "what i can do" is an acceptable limit of "what i shall do". so they'll be writing things in c "because that's what i know".
asciilifeform: (where the operands can be of any size you like)
asciilifeform: well no, that was 'compiler' for sane-people addition
asciilifeform: which is how the disease perpetuates itself.
asciilifeform: to our grief, it is very very easy to write a (sad, inefficient, but working) c compiler.
mircea_popescu: so it's more of a fashion / kink high consensus thing than a real matter.
mircea_popescu: the only valid statement of it is that "all other languages bootstrap in c". see recent discussion with phf.
mircea_popescu: no argument there
asciilifeform: point earlier was, the 'c is THE close-to-the-metal language' is a half-truth
mircea_popescu: (a demand for tobacco powered by europe's elite aiming to protect itself from diseases through smoke permitted richmond to be a thing.)
mircea_popescu: hey, it's what built the united states
asciilifeform: as for the 'kink high' aspect, the rubes are approaching the retardation in much the same way medieval folk approached the plague
asciilifeform: all of this retardation is because c semantics are very much inhospitable to working on variably-sized, non-register-sized operands
asciilifeform: mircea_popescu knows very well what they do
mircea_popescu: pretty sure that's what gfx people do, for instance, some of the fellows that first encountered 128 bit, 256bit and so forth overflowing ints.
mircea_popescu: i suppose the solution everyone uses is to declare a special class made of arbitrary length bitfields and define procedures on it such as these.
asciilifeform: but underneath the emperor's robe, there is same bare arse as everyone else has.
mircea_popescu: ok. chiefly because the fashion in kink high this season is to pretend that fixed memory like this is not even used anymore.
asciilifeform: it is used in every box you can presently buy. pretenses to the contrary.
mircea_popescu: none of these map to any code other than asm ; chiefly because fixed memory like this is not even used anymore.
asciilifeform: (the reverse is not true, of course)
asciilifeform: so to continue the tale, NONE of these ops (add-with-carry, shift-with-carry, etc) map to any conceivable c code !
mircea_popescu: myeah. except the one in my head ; cuz if i had made cpus then add dword 0xAABBCCDD, 0xAABBCCDD = 557799BA and adc dword 0xAABBCCDD, 0xAABBCCDD = 557799BA + set carry bit. but then again i dun make them.
asciilifeform: nono, this is quite elementary.
mircea_popescu: myeah ; color me satisfied. i thought you have to use adc to pop it and push it both.
mircea_popescu: oh and then adc pops the carry bit ?
asciilifeform: you get a carry bit set to 1, and [edi] is 0x557799ba .
mircea_popescu: so what happens if the first instruction overflows ?
asciilifeform: the contents of edi+4 is unaffected by the first instruction, mircea_popescu .
mircea_popescu: <asciilifeform> add dword [edi], 0xAABBCCDD << say edi = 0xAABBCCDD. the contents of edi+4 after this will be 0.
asciilifeform: mircea_popescu want me to work it out pedantically ?
mircea_popescu: is something supposed to be processed backwards here or what ?
asciilifeform: it adds the overflow bit (which can physically be 1 or 0, think about it) to the next add.
asciilifeform: mircea_popescu: that's what add-with-carry is for
mircea_popescu: and if your first add overflows then what ?
asciilifeform: we also have things like shift-with-carry,
mircea_popescu: i'd say we are adding two ints to two consecutive memory maps, but w/e.
asciilifeform: because we have this great thing called 'adc', add-with-carry.
asciilifeform: ( we are on a 32-bit box in this example ) and we add 0x12345678AABBCCDD , a 64-bit int, to another 64-bit int, to get a 128-bit result.
asciilifeform: say [edi] points to one
asciilifeform: let's say i'd like to add two 128-bit ints together.
asciilifeform: i will give example here, to nail in the point: ☟︎
mircea_popescu: i suppose these are unrelated complaints.
asciilifeform: well let's say that we redefined int as 64b. then the headache would simply be 'why does c not give us the 128-bit mul result that pentium happily disgorges when we mul rax, rbx'
mircea_popescu: worst fucking idea ever and who the fuck came up with it.
mircea_popescu: i spent 100s of engineer-hours fixing the idiocy of "int" not being 64 bit ; it's a disaster for human productivity directly comparable to the black death.
mircea_popescu: why the fuck do 64 bit platforms even bother with 32 bit ints ffs.
asciilifeform: ^ this is a personal hatred of asciilifeform's, when dealing with bignumatrons
asciilifeform: from comments, '...there are many processor features that are not directly available in C even though they are available in a wide variety of processors (the overflow flag is a prime example). A similar situation that comes to my mind now is that 32bit*32bit multiplication results in a 32-bit integer in C even though most processors yield a 64-bit result...'
mircea_popescu: "may not use the datastructs you are dereferencing in any control code involving the dereferencing. F."
mircea_popescu: absolute minimum defensive coding for unix ; taught as such decades ago in fucking romanian.
mircea_popescu: i dunno man. "This looks (to me) as good C code as it gets. However, this code triggers undefined behavior: after the first iteration of the loop frees the node pointed to by head, it is undefined behavior to perform the tmp != head comparison, even though head is not dereferenced." << if this looks like good c to him he would have flunked my higschool class.
asciilifeform: d 32-bit even though pointers became 64-bit. The problem now is that transformations that assumed integers and pointers to be the same size don't work anymore, because now their point of overflow is different.'
asciilifeform: e.g., 'Pointer arithmetic. In the good old times, an int and a pointer used to have the same size. People happily used ints as array indices. Array indexing is just pointer arithmetic, and in some architectures (like x86), you can often perform the pointer arithmetic plus load in a single instruction. Then came 64-bit architectures. For reasons I don't really get (compatibility?), on x86-64 and other 64-bit architectures ints remaine
asciilifeform: even if the peanut gallery has shat all over it.
asciilifeform: the issue in subj link is quite real though.
mircea_popescu: no you don't understand, "Software, lingüística, mitologia nórdica e rock'n'roll". a true renaiswitter man.
phf: that second link looks like alternative take on cdrcoding, but since the first post started with "i read on twitter from discussion on hacker news"..
mircea_popescu: all the various "c-with-serials-filed-off-because-i-wanna-john-smith-all-over-the-place" inherit this bizarre property.
mircea_popescu: you ever saw a "this should not be in c because it's stupid" in the past 30 or so years ?
asciilifeform is out of telepathic-psychoanalytic pills, is ill-equipped to answer the q of what 'c programmer's concept of identity' may be.
mircea_popescu: this is not identity but the opposite thereof.
mircea_popescu: the ~only thing they produce is "oh yeah, those other people do that other thing ? SO DO WE!"
mircea_popescu: one node higher from that : i was unaware anyone involved actually had the subjective mechanism of indentity. it works like this "don't do that, only gypsies do that, we're not gypsies". that's identity. whereas who in c ever said anything of the kind ?
asciilifeform incidentally currently cpp's for money, and has much that could be said on the subj, but naggum already said it
asciilifeform: at least the cpp folk are - typically - aware that their retarded horror has broad swath of vendor-specific behaviours and miscellaneous strange.
asciilifeform: as opposed to 'in unix' or 'in winblows'
asciilifeform: you'd be surprised, there are folks who are convinced that they've been 'programming in c' for 30+ yrs.
mircea_popescu: i thought it was like the romanian language, a subjective superset of all languages.
mircea_popescu: this is the first time i hear c had an identity.
asciilifeform: ( also of interest, to certain folks, by same: http://inf.ufrgs.br/~vbuaraujo/blog/?entry=20160528-lisp-without-cons-cells )
mircea_popescu: anyway. only way to open coconuts.
mircea_popescu: i suppose a machete esp in the rula style as seen there is a very credible cavalry sword.
shinohai: I can't make it out, looked very close to a dried bovine penis for all I can tell.
mircea_popescu: oh yeah, anyone figured what that thing in my hand is ?
mircea_popescu: it may be illustrative to point out at this juncture that well over half of player time in eulora is spent with the character superimposed on a very pike like thing.
shinohai: So that's what that stick he is carrying in the new trilema banner is for. ☟︎
asciilifeform: (who is actually king vlad himself, posting via a time wormhole)
asciilifeform: shinohai: nah, that'd be mircea_popescu
shinohai: I consider asciilifeform the republican authority on impalement methods
asciilifeform: think 'old version.' if there existed a medieval gcc, i'd at least consider it. ☟︎
mircea_popescu: asciilifeform> the parallels with medieval copyists invite themselves... << it's called scholarship, hater.
trinque: they are there as blessings!
asciilifeform: for n00bz and perhaps also for mircea_popescu , i will add the note here, that lisp folk don't generally ~read~ the parens, they read the indentation. this requires proper tools, such that the possibility of encountering misindented crapola is ~= 0.
trinque: clozure cl seems to work for what I need
trinque: was particularly curious about armhf threads, which sbcl lacks
phf: needless to say, i have no idea what i'm doing(r)(c)
a111: Logged on 2016-10-03 14:29 trinque: heya phf, did you ever take on that sbcl arm port (and which arm was it) ?
phf: http://btcbase.org/log/2016-10-03#1551544 << sbcl already has an arm port, courtesy of nyef. i am doing the same work for cmucl, but i'm very far from actually getting there. i'm going by armv7 with vfpv3-d16, mostly because that's what ccl does and their code is imho most readable ☝︎
phf: hmm, fair question, but i don't remember, i can't remember if tab even indents to the right place, i'll check in a bit
phf: fwiw they had a graphical editor going back to mit cadr, and it flashes and highlights
asciilifeform: phf: interlisp had a graphical 'structure editor', i have never used it, and now i wonder if the {} thing was slightly less braindamaged given the context of having it.
asciilifeform: (in linked example, we get a transformation of commonlisp into a language with entirely different syntax and evaluation rules, 'while you wait!111')
asciilifeform: sometimes a localized bit of custom notation is the only reasonably-compact abstraction.
asciilifeform: i like having the [], {}, etc. available for readtableisms.
phf: and then not give you readtable!
asciilifeform: that was one of the off-putting things, actually, re the clojure people, why did they have to clobber every key on the keyboard
asciilifeform: and also because genera was a product of adults, rather than children, it is a sin specifically of the latter to obsess over very dubious 'optimizations' like 'super-paren {}'
asciilifeform: phf: this is largely because they introduced proper editing
phf: for how cavalier cadr is with parenthesis, all of that is gone by the time of genera