191–200 of 312 posts
Earlier quoted context omitted.
Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.
Isn’t modern JS backward compatible with 1.1?
Earlier quoted context omitted.
maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.
WASM is _designed_ to be easily jitted, without the expensive machinery we had to put in place to do this for x86, so the whole point is not require a new architecture. Because of this I find WASM to be the best direction yet for a "universal ISA" as it's very feasible to translate to most strange new radical architecture (like EDGE, Prodigy, etc). (Introducing a new ISA is almost impossible due to the cost of portin…
Earlier quoted context omitted.
Its not that it isn't capable, its that it has more gocha's than most other languages of it size (and no, just because the gocha is well defined doesn't mean that it doesn't trip programmers up). Its also despite a couple decades of hard work by some very good compiler/JIT engineers at a considerable disadvantage perf wise to a lot of other languages. Third its most common runtime environment, is a poorly thought out…
Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being forced to do things a certain way. But when it comes to JS and even other dynamic languages, people for some reason absolutely lose their minds, like a teenager whose parents are going out of town and are leaving them home by themselves overnight for the first…
Javascript requires some self-discipline, where other languages discipline you if you try to fuck things up yourself. It's kind of like a drunken sailor on leave going on a bender on-shore - the minute they leave the ship all bets are off. Some people just can't wrap their head around using weak/dynamic typing, because it loosens the rules. But that doesn't mean there aren't any rules.
I code in a dozen other languages and Javascript is still my favorite because it's so easy to use, no boilerplate, and it doesn't give me any "gotchas" because javascript actually does follow some very basic easy to understand rules. The people that don't bother to learn those rules invariably shit on javascript. It's not fair, it's not real criticism.
And practically all of the "examples" of bad javascript is almost always code that nobody should ever write, in any language, because it's just stupid to write code in those ways. But people think "aHa, aNoThEr 'gOtChA'" and the myth of javascript being somehow inferior continues. And to anyone who actually knows how easy javascript is to use, it just looks silly, pathetic, and obnoxious.
Earlier quoted context omitted.
Yep. They have a compiler to bring it down to the metal so IDK what you're saying. --- EDIT --- @saagarjha, as I'm being slowposted by HN, here's my response via edit: OK, sure! You need some agreed semantics for that , at the low level. But the hardware guys aren't likely to add actors in the silicon. And they presumably don't intend to support eg. hardware level malloc, nor hardware level general expression evaluat…
The metal which largely respects C's semantics? For example, here are some instructions that exist to match C's atomics model: https://developer.arm.com/documentation/den0024/a/Memory-Ord...
I suspect that the OS and Architecture communities have known about one-way barriers for a very long time, and they were only recently added to the Arm architecture because people only recently started making Arm CPUs that benefit from them. And that seems like a more likely explanation than them having been plucked from the C standard.
Moreover, one-way barriers are useful regardless of what language you're using.
Earlier quoted context omitted.
Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?
There is one CPU that exposes its out of order inner workings, the VIA C3 ("ALTINST"). The unintended effects are so bad that people that accidentally discovered it referred to it as a backdoor: https://en.wikipedia.org/wiki/Alternate_Instruction_Set
Because it was implemented in a flawed way.
> "In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.["
Anyone else remember the ARM Jazelle DBX extension? I wonder if they'll end up dumping this in this the same way. I don't remember very many phones supporting DBX, but IIRC the ones that did seemed to run J2ME apps much smoother.
Earlier quoted context omitted.
>> Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings? Because exposing that would be a huge burden on the compiler writers. Intel tried to move in that direction with Itanium. It's bad enough with every new CPU having a few new instructions and different times, the compiler guys would…
> Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently. Exactly this hinders any substantial progress in computer architecture for at least 40 years now. Any hardware today needs to simulate a PDP-7 more or less… As otherwise the hardware is doomed to be considered "slow" should it not match the C abstract machine (which is mostly a PDP-7) close enough.…
Earlier quoted context omitted.
1-2% for a single language at the cost of polluting an entire instruction set.
What is the cost of this pollution? I am genuinely curious, I don't know much about instruction set design.
Earlier quoted context omitted.
Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?
> Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".