<OriansJ>well it could become possible to run M2-Planet on 64KB if we break it up a little bit to enable optimizations and sepecializations. <OriansJ>but that would mean taking 2 steps backwards in our current bootstrapping path and admit we made a few bad design decisions <xentrac>the majority of C programs don't include any inline assembly <xentrac>(although after growing to a sufficiently large size, people often find it worthwhile to add it) <xentrac>because inline assembly is nonportable, and many C programs are portable <xentrac>so many people think that C without inline assembly support is worth the trouble. it's situational <OriansJ>xentrac: without inline assembly, syscalls become quite hard to implement (unless one just links to an assembly file that achieves approximately the same thing) <xentrac>yeah, although Windows NT on the 286 did it; the idea was that user programs wouldn't be able to just call into the kernel because the kernel DLLs would be loaded in unpredictable cases <xentrac>and if they guessed wrong they would crash <xentrac>at least not for running untrusted code <xentrac>not too different from what Windows 3.0 did, but of course that did use asm <OriansJ>xentrac: and those DLLs needed assembly to work <xentrac>in Windows 3.0, but not really in NT <OriansJ>In the end; assembly will always be tucked into the back of C be it in standard libraries or otherwise. <xentrac>I mean yeah the linking was accomplished by twiddling registers and doing indirect jumps and whatnot but that was in the compiler, not the OS <xentrac>I've been thinking that in modern machines with room for lots of cores, it might make sense to just give them separate memory spaces and load different processes onto different cores <OriansJ>or provide them with the illusion that they have the whole machine to themselves <OriansJ>with no idea about any other software installed or running <xentrac>they would have a whole machine to themselves <xentrac>on a machine with memory-mapped I/O and an interrupt calling sequence compatible with your C ABI, you could plausibly do everything in C, with things like *(uint32_t*)0x2eff = 3; <xentrac>but that's really more an effort in restricted programming, like writing A Void without the letter "e", than a practical thing to aim for <OriansJ>xentrac: well unless one uses tagged memory but such machines are quite rare <xentrac>yeah, C doesn't deal well with tagged memory <xentrac>despite how far backwards the standard bends to support weird machines <OriansJ>actually it enables alot of amazing performance optimizations if I remember correctly <OriansJ>Lisp machine C was the golden standard for performance for a little bit there if I remember correctly. <xentrac>could be. Lisp is a much better language to write an optimizing compiler in than C is <OriansJ>all error catching and handling is done entirely in hardware <OriansJ>xentrac: well as I have yet to write an optimizing Compiler I don't honestly know. <xentrac>and early-80s C compilers were not very good at optimizing <xentrac>in part because they were written in C, which makes that kind of thing especially challenging <OriansJ>but I do know assembly is an amazing language for writing a minimal C compiler in. <xentrac>you should send Ken Thompson a thank-you note <OriansJ>So if one had alot of RAM and a sufficiently fast CPU, ther is nothing stopping a C compiler written in C from being a good optimizing C compiler. (See GCC) <OriansJ>(even if bootstrapped from a minimal C compiler) <OriansJ>I just think it is a matter of of human effort applied. <OriansJ>once one goes past C, there are marginal gains in programmer efficiencies beyound the benefits of DSLs where one trades systems efficiency for programmer efficiency <xentrac>well, you can of course write anything in C <OriansJ>but then again, I have long stopped believing in magic in computers and started to appreciate the lifetime efforts of many loving, caring and passionate humans; carving a future out of the stone of the computing environments in which they lived. <xentrac>but GCC's original optimizer used a Lispy DSL, implemented in C, to express its optimizations (and indeed the whole code generation thing) <OriansJ>well RMS was very much a Lisp hacker <OriansJ>and thus heavily influenced his code choices and style <xentrac>and that was why GCC produced dramatically better code than most Unix vendor compilers <OriansJ>So, I feel that is less about Lisp and more about the sheer number of amazing programmers who threw hours/days/years at GCC. <OriansJ>Technical advantages rarely surpass social advantages. <OriansJ>Hence why major projects are done in things like node.js and not haskell or scheme. <OriansJ>It is just a natural side effect of human choice. <xentrac>well, also, node.js is just freaking awesome <OriansJ>More people like language X, therefor the greatest progress is made in language X even though language Y is logically superior. <xentrac>generally speaking, JS takes about half as many tokens as Scheme to express the same thing <OriansJ>personally I can't stand javascript; it just doesn't appeal to my tastes. <xentrac>and there are things that are much flatter in JS than in Scheme, like the K combinator <OriansJ>every language has advantages, otherwise who would bother to use them? <xentrac>f => g => x => f(x, g(x)) or if you like f(x)(g(x)) <xentrac>also V8 produces faster code than most Scheme compilers <xentrac>which is a technical advantage that arises from a social advantage, since Scheme is probably less difficult to optimize <xentrac>I think one of the significant choices that made Stallman amazing at writing a C compiler was specifically taking an AI/Lisp approach to the problem of writing a compiler <xentrac>which turned out to give better results with less effort than most of the vendor compilers <xentrac>TI DSPs for many years used a C compiler that was actually written in Lisp, but that wasn't really consonant with Stallman's goal <xentrac>I think JS has all of the compiler-writing-relevant advantages that Lisp had at the time, and there are better languages for writing compilers in today <xentrac>I think npm has been a big advantage for Node, but I don't know Haskell well enough to compare npm to Hackage. is there an npm equivalent for Scheme? Raven, Akku, the Racket Package Index? <OriansJ>xentrac: perhaps I see JS from a very different perspective. <OriansJ>It is generally lazy, inefficient and very poorly engineered software. <OriansJ>Leaning heavily on pyramid building levels of human suffering to get mediocre performance. <xentrac>the Racket thing seems to have 1400 packages, Raven has like 25, Akku has 278 <OriansJ>also outside of standard libraries, why bother supporting packages? <xentrac>yeah, that's how I saw JS in 2000 before I started programming in it <OriansJ>why import a package to see if a number is even or odd? <OriansJ>That is just stupidly bad engineering. <xentrac>now JS's performance is, as I said, better than most Schemes, although still much poorer than C or LuaJIT <OriansJ>I could understand if one imported a package to support HTTPS or bitorrent or another complex protocol <OriansJ>but the sheer number of questionable things in JS packages is just beyound the pale <xentrac>well, by reducing the costs of software reuse to such a minuscule level, npm guarantees that many packages will have very little value <xentrac>using leftpad really doesn't save you a lot of work <OriansJ>xentrac: and enables a backdoor to be slid in quietly <xentrac>but it's excellent evidence that npm makes the costs of software reuse quite low for most people <xentrac>less so perhaps for those of us who are worried about security ;) <OriansJ>why bother running code you can't trust? <OriansJ>the person who just stole your bank credentials? <OriansJ>thanks to your bank not doing a proper audit of their JS code pulled via NPM? <xentrac>also for the company that built the bank's site <xentrac>I'm just as worried about whether a prototype I'm slapping together to try out a UI prototype is "stupidly bad engineering" as I am worried about whether my shopping list is "stupidly bad writing" <OriansJ>we shouldn't have infinitely nested bootstrap dependencies hiding god knows what as the basis of anything we depend upon for real business. <xentrac>which, to be clear, it is. my shopping list is poorly written <xentrac>but lots of people accept the risks because the tradeoffs seem reasonable and the wins are big <xentrac>I was pretty shocked at the number of dependencies of a simple Rails app when I did some work with a Rails consultancy in like 2012 but it's nothing compared to what's in an empty app from create-react-app <xentrac>anyway, having more libraries available generally makes you more powerful as a programmer, at least if you have some way to find the libraries you need <xentrac>and the fact that JS gets used for writing lazy, inefficient, and very poorly engineered software is no more a black mark against it than the fact that English gets used for saying lazy, inefficient, and very poorly written sentences and speeches <xentrac>on the contrary, the fact that even the most vulgar and ignorant find it to their advantage to climb over the absurd irregularities of English and use it anyway is a powerful testimony to the great advantages of English <OriansJ>I honestly feel programming should be an engineering activity. where one thinks about what they code and are willing to admit when they did the wrong thing and try to fix it. <xentrac>That's definitely the right way to do programming in an engineering context <xentrac>But there are lots of other reasons to program <OriansJ>Look, I program for the benefit of society as a whole. <xentrac>aside from JS, Node is great because it comes with a fairly comprehensive asynchronous I/O library, and the only other language I know of for which that's true is Tcl, which has big disadvantages of its own <xentrac>I appreciate it! But not everybody does; a lot of people program because they like it, or because it's a medium for them to communicate what they want to communicate, or because they have a repetitive task they would benefit from automating, and that's okay <OriansJ>xentrac: selfish goals only last until you scratch enough of the itch to stop feeling the pain. Real progress is when the goals are bigger than you. <xentrac>We have derived enormous benefits from the limited extent to which even the smallest-minded people can see that their interests are aligned with ours <OriansJ>but how many people stopped short of solving real social problems correctly forever because they finished scratching their own itch? <OriansJ>Look, I assume everyone will utlimately act in their own selfish interests <xentrac>"It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner," etc. The great breakthrough of free software was to find a way for self-interest to succeed in solving real social problems by contributing to a shared commons, due to the replication power of general-purpose computers. <xentrac>even if those problems aren't solved correctly, an imperfect solution is often better than none. <xentrac>back to JS, I really like it, even though sometimes I'm writing things that aren't lazy, inefficient, and very poorly engineered. (Sometimes I am!) <xentrac>but I like it for doing things properly and efficiently for much the same reasons that it's good for doing things lazily and inefficiently <OriansJ>xentrac: it is just one tool in the toolbox we have collectively made together. <xentrac>namely, it's a higher-order garbage-collected language with a reasonable OO system, a bitchin compiler, and excellent support in interstices where nothing else will work. <xentrac>Also, its syntax is pretty reasonable, which is a nice plus. <xentrac>Also, its debugging tools are a fricking dream. <OriansJ>xentrac: there are no magic languages; only cases where languages are a great fit for the problem at hand. <xentrac>I still use Python pretty often though, and Lua also has a special place in my heart. <xentrac>I think there are better and worse languages, though, even though the best language for a particular thing may not be the best language for something else. <xentrac>JS wouldn't be any good for programming an antilock braking system, though, and it would be pretty challenging to write an OS (kernel) in. <OriansJ>JS appeals to the short term thinking patterns we are all vulnerable to. But we need to think long term if we wish to do what is best for the generations that follow us. Moore's law in regards to shrinking transistors and Dennard scaling is dead. Koomey's law is approaching its final limits. The limitless resources dreamed of in years past will never appear. We must accept reality and sacrifice short term advantage if we wish to <OriansJ>bootstrapping provides no short term advantages. Economically no one cares, not even the groups that desperately should. <OriansJ>How many cryptocurrencies have funded such developments? <OriansJ>how many banks, militaries or governments? <OriansJ>There is no fame in this work; no great demand. <dddddd>Future generations will invent neutrino-computing or something like that we can't even imagine :P We'll be here in the meantime. <OriansJ>dddddd: we already have quantum machines, but JS is not the language one uses on such machines. <OriansJ>Its assembly (and scheme like assembly) <OriansJ>because programmer effort is cheaper again. <OriansJ>The wheel of reincarnation rolls on again. <OriansJ>a $1 computer is sufficient to bootstrap GCC and software for a quantum computer <OriansJ>which right now costs in the Millions of Dollars <OriansJ>honestly, there are many ideas that are good for hardware architectures that are just plan bad for bootstrapping (like tagged memory) <OriansJ>I enjoy bootstrapping but I understand that there are places where it just doesn't make sense to go there. <OriansJ>like a brainfuck CPU (those actually exist) or OISC processors <xentrac>Yeah, I think there's definitely something to that: to some extent rapid feedback crowds out deep thinking in programming just as in any other discipline. <xentrac>But I think they're complementary virtues. <markjenkinsznc>I'd say there is some minor fame at the end of this, I expect this project of projects will be recognized with a FSF award some day ***ChanServ sets mode: +o rekado
<bauen1>it appears that switching to user space is working (and causing a syscall interrupt) <bauen1>now for the fun part of making everything preemptible, and have it not break on nested interrupts ... <xentrac>are nested interrupts really necessary? Can you just turn them off? <xentrac>or is this an experiment in seeing how far you can go with preemptibility, as opposed to writing your first kernel? <bauen1>xentrac: i guess nested interrupts are the wrong term, but bad things happend if you have kernel code that disabled interrupts call kernel code that assumes it has to disable and reenable interrupts <`Lion>very interruptive things would happen ***roptat_ is now known as roptat
<xentrac>bauen1: nested interrupts are when an interrupt happens while you're in an interrupt handler for, generally, a different interrupt. some CPUs can handle them <OriansJ>xentrac: who cares if they are necessary? If bauen1 wants to have that in their kernel, who are we to say otherwise? Whoever does decides, no exceptions. <xentrac>oh, for sure, I didn't mean to deprecate them <xentrac>just wondering if they were writing reentrant interrupt handlers because they didn't know there was an alternative <xentrac>but it seems like they weren't really talking about nested interrupts but rather keeping their prologues and epilogues consistent with their callsites <xentrac>nested interrupts are definitely a very worthwhile thing to implement for some kinds of real-time OSes <xentrac>and, as you say, certainly a valid thing to implement just because you want to, but in other OSes it's often a more practical choice to just not use interrupt priorities