IRC channel logs

2019-11-14.log

back to list of logs

<oriansj>vagrantc: looks like I need to do a minor release for mescc-tools as commit 1a9c5358385247e75cafe1f451496a1fd13675bc fixed the regression for ARMv7l; which will result in passing tests on that architecture (or your could do a debian ~1 sort of thing)
<oriansj>janneke: Don't think of Gnu MES on Debian as a bootstrap point but rather as another Scheme Interpreter and MesCC as just another C compiler on Debian.
<oriansj>janneke: also, I am experimenting with something crazy to substancially simplify the task of maintaing Mes.c long term
<vagrantc>oriansj: sure
<janneke>oriansj: nice perspective, and great!
<amz3>hello, people!
<amz3>as usual, I midly offtopic, but that is the only (friendly) channel I know where I know there are people that know about hardware things.
<amz3>there was this big mega press release about web assembly being the "Next-Big-Thing"
<amz3>It is called "bytecode alliance".
<amz3>my question is: would it be possible for hardware manufacturer, to standardize a bytecode (as the name bytecode alliance) imply, so that hardware can be programmed in this so called web assembly (wasm) or it is just a dream of mine?
<amz3>it is probably a multi-year project, even a decade away, but still the idea to target wasm instead of C, and create a bootstrap path that would do machine native assembly -> wasm -> scheme and native assembly -> wasm -> C / C++
<amz3>beware if you look for the actual article press release, it is full of web buzz words.
<oriansj>janneke: I just realized I pushed a broken commit to mes-m2 (forgetting to add the definition of TPRIMITIVE) and just pushed that now
<gio>amz3: What is the difference with RISC-V?
<oriansj>amz3: well the first hardware problem I can imagine is that essentially a file system has to become an object stored entirely in memory and hard storage was to be transparently backed by hardware.
<oriansj>Now that has been done before https://en.wikipedia.org/wiki/IBM_System/38 and honestly although it has some nice properties; you instantly have to throw 30-50% of the hardware's performance out of the window.
<amz3>gio: tx for the reply. That is the kind of reply I was looking for ie. a open ISA. Based on the RISC-V wikipedia. WASM is very tiny, it is higher level. It was developed in the context of web browser to allow to support multiple programming languages in browsers. The only immediate alternative usecases, I can see, is "high level" expert system (like databases), that can be configured or manipulated.
<amz3>For instance posgresql, could expose a wasm bytecode interpreter or jit compiler, and allow clients to write queries in any language that can target wasm. Otherwise, said, it it sill fuzzy to me what would be the purpose of wasm as the frontend of a processor.
<oriansj>that being said amz3, gio brings up a very important point. Much like the Java CPUs of old; https://en.wikipedia.org/wiki/PicoJava such designs are doomed to be more expensive and lower performance than a general purpose processor with a sufficiently large customer base..
<amz3>wasm ought to be the target of many or any programming language.
<amz3>I am looking for the perfect design, not widespread adoption.
<oriansj>amz3: There is no such thing as perfect design outside of DSPs
<oriansj>one could argue Knight is perfect for bootstrapping and AMD64 is perfect for general software support
<oriansj>perfect requires context and requirements
<oriansj>MOnSter 6502 could be perfect if you want hardware you can audit
<gio>It would be difficult to argue that AMD64 is perfect for anything at all.
<gio>It's just the one we happen to have.
<oriansj>or the galaksija is perfect for easy to make computer
<oriansj>gio: I'm with Linus on that x86 is pretty amazing if you ignore the ugly bits you don't have to use.
<oriansj>AMD64 stripped out a bunch of bad instructions from x86 and upgraded to 16 registers; allowed SSE3 instead of x87
<amz3>perfection in the sense of the following quote: "Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual." https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
<gio>Torvalds is for sure more experienced than me in those things, but I can't feel it pretty amazing.
<gio>To me it seems to be a big mess where everything depends on everything else, decoding is complicated, there are a lot of special cases and exceptions.
<oriansj>amz3: Clearly Lilith https://en.wikipedia.org/wiki/Lilith_(computer)
<oriansj>gio: what do you mean everything depends on everything else?
<gio>Also, you only consider the programmer's task. But there are also the CPU implementor, the KVM implementor, the reverse engineer, ...
<oriansj>gio: I said General Software Support perspective; The CPU implementation, KVM implementation and programming efforts are traded to gain that advantage
<gio>oriansj: amd64 has a lot of possible flags and modes, and many opcodes change what they do depending on the current mode, flags, prefix, whether the system is in a VM and possibly other things. I find so many dependencies confusing.
<gio>Also interrupts, tasks, gates and whatever have a lot of little (or big) variations depending on many bits of system state.
<gio>Now, with the emergence of new microarchitectural bugs, you also need to be aware of more and more things you have to avoid.
<gio>I find it complicated.
<gio>Manuals are thousands of pages long and, in my humble and probably inexperienced opinion, have plenty of room for clarity improvement.
<oriansj>gio: well the good news is one can operate in a single mode (long mode); avoid all flags and only have to deal with a single prefix (0x48); reduce down to a single interrupt, ignore tasks and gates entirely. Throw out the VM bit entirely and it is easier to implement x86 without the hardware optimizations that introduced those vulnerabilities
<oriansj>As for the manuals; the length is the not the point of issue for me but rather the accuracy of the contents
<gio>oriansj: Ok if you like so, but I don't call something "pretty amazing" if to make it operate reasonably you have to throw away 80% of its features.
<oriansj>gio: I'd rather ignore the 80% of features I dont use; rather than complain about the 1% of features that I need and the hardware doesn't provide...
<oriansj>in the end, hardware will accrete features that no one uses because pulling features means you just broke people's working programs
<oriansj>Much like the Linux ABI; yeah it has a bunch of stupid things and it is complex but if you need your program to work for 40 years, there isn't a debate about what the world at a whole cares about
<oriansj>Despite all the flaws, I don't see many people using a BSD instead of Linux
<oriansj>Nor that many people using a beautiful CPU architecture like Knight; when ARM and x86 despite being ugly monsters dominate the market
<oriansj>Why doesn't ARM have integer divide instructions? why did I have to literally roll my own integer division routine for a modern OoO processor when integer division hardware is so cheap
<oriansj>Why does AMD64 require idiv ebx; when R0 <- R1 idiv R2 would be a better solution? Short answer legacy mistakes always accrete.
<oriansj>Having a crufty architecture that is 41 years old and actively used by hundreds of Milliions of people is an amazing achievement
<oriansj>yeah, as a compiler writer I ignore most of the features it provides. So do the Operating system Developers. But those programs you depend upon keep working for decades
<gio>I totally understand why amd64 has so much cruft. I do not think Intel engineers are bad at designing ISAs. Still, I don't call the outcome perfect.
<oriansj>gio: which metric of perfection do you wish to use?
<gio>My personal feeling is that whatever you choose, amd64 won't fit. However, it is midnight here, so my personal take on perfection now coincides with bed. Have fun!