9600+ entries in 0.008s
mircea_popescu: anyway, has a shitty html blog, all the symptoms people go through in that quarter or two between when they get the republic illumination and when they become actually useful/productive.
mircea_popescu: "hen I stopped work on my fork, the other project stopped, but when I started up again, so did they. All I was doing was keeping the CVS tree just active enough to exclipse mine, and I was tired of it."
mircea_popescu: basically, the cunts were just taking dood's patches and dropping them in their toilet.
mircea_popescu: "(People sent me bug reports about the 0.9.24 release. Yeah, that release contained a lot of code copied out of my tree into CVS, but the release was based on CVS, not on my tree.) By 2008 as CVS sank into obsolecense, TCC had clearly decided to go down with the ship. No matter how much work I put into my fork it would never eclipse the "official" tcc project (which could of course read my code to advance their tree)."
mircea_popescu: this is actually more substantially gnu than any tech/engineering/cs/anything. invidious wikitards rather than anything else.
mircea_popescu: obody wanted to work with me on my version because it wasn't "official"."
mircea_popescu: "This used to be the page for my fork of Fabrice Bellard's Tiny C Compiler, but I got sick of competing with a mostly dead CVS archive that nevertheless remained "official". Every time I worked on my fork it inspired new work in the old CVS archive, and every time I set my fork aside the old project ground to a halt. Even though the old tcc project repeatedly stagnated whenever I stopped working on my fork for a few months, n
mircea_popescu: Mocky just trying to evaluate if this thing worth digging up
mircea_popescu: but the ensemble will not move at the speed of a single core will it ?
☟︎ mircea_popescu: Mocky so if i declare a procedure which increments a global and a local counter, and then call it in a loop from multiple threads, at the end the globa lflag will contain the sum of the local flags ?
mircea_popescu: hanbot write down the whole story as you go, but basically yes.
mircea_popescu: conquering china, also expensive. who knows, maybe it can be massaged to pay for itself.
mircea_popescu: kinda makes it a particularly delicious spot to rape the femstate.
mircea_popescu: ie, whenever you encounter "competitions" of malformed nonsense, you're exactly in the position of the ~spectator~ to special olympics.
mircea_popescu: i suppose the pov where design is ~constrained~ activity, and the concept of "design competition" must strictly describe a situation where machine a with 64 registers of which one is mask and machine b with 64 registers + ONE separate mask register compete.
mircea_popescu: and whenever you go with option 3, guess what. 1 IS MASK!
mircea_popescu: as a general design principle! you may NOT have "multiple" on a machine. it's 0, 1, buswidth-count. THAT IS IT.
mircea_popescu: let me guess, the same fucking people who made mul without carry.
mircea_popescu: then it was too late, and then it just became incomprehensible.
mircea_popescu: i was trying a tongue in cheek, "yes, now it has more code and less functionality, but it follows whatever trend of insanity".
mircea_popescu: i mean, "<asciilifeform> nao it resembles minix, 100x the mass of the original, and ~less~ function" <mircea_popescu> yeah, but it's in ruby, or w/e the fuck unity.
mircea_popescu: (note: "lists.gnu.org" moved to "lists.nongnu.org"). and other keks.
mircea_popescu: sounds like he did a lot of the same stuff here contemplated. shoot fellow an arrow maybe ? is he old ?
mircea_popescu: moreover, the recent exception handling discussions & digs exposed most eminently the hole the shit's in. you could improve on gcc right now, just by fixing its idiotic tokenizers, "optimized" log n-onsense ans so forth.
mircea_popescu: this isn't the q. there's exactly one thing that shits bytecode. much like in 2011 there was exactly 1 thing that extended the blockchain.
mircea_popescu: ada-musl will have to get its own backend, even if it's mpi-style confiscation.
mircea_popescu: anyway, to land this far going baloon : currently, the large chunk of sanification work will likely still be
http://btcbase.org/log/2019-02-20#1898113 ; there's no way to have a world without a backend, there's no way to learn how to build one without unpacking the only one that exists, and so on.
☝︎ mircea_popescu: moreover -- b is actually a major spot of research, because we don't even exactly know WHAT we will set down as "must be / must not be".
mircea_popescu: though if memory serves intel mkt dept had internal proposal to "usg pronounces pentium right, everyone changes bookeeping to suit it"
mircea_popescu: it's independent of a, because if it turns out all iron fails math we'll dump all iron, not re-write math.
mircea_popescu: and that b) it is likely to be easier to start picking low hanging fruit from right rather than left, simply because cheaper fruit lowerly hanging there.
mircea_popescu: and i'm saying that a) both approaches share a lot of overlap (you say no, but you agree next line that conceptually, field is broken -- that is overlap!!! you just agreed!)
mircea_popescu: nevertheless, the obvious alternative, factually there as holes follow fills and so on, is "approach from code end". and this approach'd be something like a ~proper~ standards lib. ie, both with proper access and proper primitives.
mircea_popescu: nothing wrong with this. and will have to be at least attempted.
mircea_popescu: but back to it, let's try and use different terms : i deem your "whole thing is an emu, in machine lang, bios boots into it" to be a "approach from machine end".
mircea_popescu: very early 1500s medicino-chemistry-philosophical-barbershop flavour to the whole field.
mircea_popescu: fucking bs "science" where ALL the notiuons are broken.
mircea_popescu: which is the point, it's a waste of time to consider "how linus separated" or "how rms thought should be separated". whoile thing's built on magic musherooms, "sky quadrants" etc.
mircea_popescu: anyway, i think i fully understand what you mean re "no compiler, no linker" : it is evidently a broken situation when you have TWO patsh from "what master said" to "what machine does".
mircea_popescu: asciilifeform i'm aware, evolved not designed. nevertheless, the fundamental breakage here is that glibc is proposed as a "library" rather than a "kernel mod". not that these terms make any fucking sense anyway, but what the fuck am i gonna do.
mircea_popescu: asciilifeform the large problem here is that the ast will have to be ultimately a homomorphism of machine language. which is the dubious part in the "emulator" pov.
mircea_popescu: to follow the logic : the notion that you'd have a kernel mod to interface with peripherals, but not with code, is somewhat bizarre.
mircea_popescu: terminology fails, mostly because terminology was made by morons and we're trying to discuss analysis in roman numerals here, but consider "glibc" would be a... well i guess a kernel mod the program links against as a library ?
mircea_popescu: but srsly now, the "standards lib" lets me print to screen but not print to ram ? wut.
mircea_popescu: or in other words, the overlap is large even if the barbarians cut it wrongly and on the basis of their cuts it seems to not be\
mircea_popescu: ie, the fact that glibc doesn't come with sane memory allocator ~is a failure of glibc~.
mircea_popescu: certainly. but once you start talking about unified abi, you're very much starting there.
mircea_popescu: then again this whiole discussion is moot, because step 1 towards that magical bios asm blob is a tmsr standards lib to replace glibc anyway.
mircea_popescu: even so. as far as reading goes, you still read it the same number of times, whether it's linked or bios'd.
mircea_popescu: the 2nd gets linked in however many binaries you wish, still is a single item.
mircea_popescu: however, consider situation 1, where "it is in emulator" and situation 2, where "it is in this one tmsr standards library".
mircea_popescu: from the pov of auditing it is certainly cheaper to move it into the "emulator"
mircea_popescu: asciilifeform large part of people's complaints re leverage are insane. take the recent naggum piece discussed, he complains, literally, that "he wants to lie once rather than everywhere". duh, no sed where this man lives ?
mircea_popescu: asciilifeform it's never cheaper to have a coupling than a straight link. nevertheless, couplings are used.
mircea_popescu: other than this, the "we don't want to fuck our brains with $bad-arch" is a dead end -- you will, whether to write gcc for it or to write bios for it.
mircea_popescu: the obvious counter there will be "but not cheaper than baking ONE sane gcc". which is true, but nevertheless not as useful -- sometimes having an interface, even if "spurious" is better than not having it, which is why parents don't customarily discuss family finances with their 12yos.
mircea_popescu: like all attempts to date have, here or anywhere else.
mircea_popescu: understand tho, it has a very visible facet of wishful thinking. i mean yes, obviously, way the fuck better to have all the needful stuff in one place than added to each binary. this much is certain. nevertheless, the notion that you can stuff a converter from insanity to sanity "in the bios" requires just as much a magical stone as any other "universal sanity-insanity bridge".
mircea_popescu: asciilifeform re bios emu -- i am certainly not against trying this. it's not possible to say much more than that as things stand now.
mircea_popescu: see, the old british ban on champerty & maintenance meanwhile dead. the fact that it happened to rando kid dun matter, trial can be bought.