So, could it be a feasable for a Zen CPU to have multiple microcode banks it switches between, so that it can run code in multiple architectures? For example, in addition to x86, some microcode for running WebAssembly or Java bytecode with native performance and no JIT overhead?
These often repeated notions about Jazelle make little sense.
J2ME code for Jazelle based feature phones (with appropriate VMs) was noticeably faster than otherwise, to the point Android raw Java performance did not catch up for a really long time. If you have loads of RAM to JIT later then . . . good, but that didn’t arrive for years after the fact.
Android ended up doing AOT (the infamous "optimizing apps" step on boot). The modern versions, iirc, have a hybrid approach, interpreting and JITing for newly installed apps but still AOT compiling while the device is charging.
Directly running wasm/Java bytecode in hardware is just a bad idea unless you somehow have tons of loopless code that'll only be run once; both are stack-based with an unbounded stack size, so each op would have multiple memory loads/stores. At the very least you'd want some rewriting to use multiple registers, at which point a simple JIT/AOT isn't far off.
If you are going to specific devrooms instead of specific talks, you usually don't need to wait in line before getting in. At least that was my experience last year: I got there early in the morning and the rooms were not very full.
From what I understand, this core tries to ourperform the A75 in IPC whilst using less area. However, the P550 cores run at a lower frequency (1.4GHz) than the A75 (2GHz). I wonder if this optimization for area, like in Zen4c, makes it impossible to drive the core at a high frequency, hindering its maximum performance. Nonetheless, it's a great RISC-V core, especially when compared to what brands like SpaceMit and Alibaba T-Head offer.
Not particularly unique at all. Handheld graphing calculators typically were not intended for use where hardware floating point was necessary. TI calculators historically used the Z80, no FPU. Earlier HP calculators did use a custom BCD based (not IEEE954) floating point ISA, but these are still slower than just about any processor in the past 30 years doing software floating point. They didn’t have any hardware multiply or divide for one, this is not an FPU in the modern sense people envision. And later on the HP used common ARMv5 based processors with emulation. None of these ARM processors had hardware floating point. Same with later TI calculators that were 68k and then ARM based.
The HP Prime G2 released in 2018 is about the only mainstream device that happens to have hardware FP, and that’s for a device more touted for CAS features. The FPU is more just something that comes for free with the commodity SoC chosen.
> None of these ARM processors had hardware floating point
More importantly, IEEE 754 floating point ISA is not great for calculators - they don’t require the speed a personal computer does, and calculators work hard to hide the fact numbers such as 0.45 can’t be represented as IEEE 754 floats.
If these vapes are disposable, wouldn't it be cheaper for the manufacturers to use non-rechageable battery technologies like the many ones on AA(A) batteries?
The juice lasts about 10x longer than the batteries, so they'd have to either make them use much less juice, or use larger batteries.
Consumers are paying upwards of $20 for vapes that last less than a week with heavy use, or about 2 weeks with low/average use, so I don't think a dollar saved on batteries is really as much of a concern as "why should I buy your vape vs one of the 5 dozen competitors'"?
From what I read, Greece's policy was (partially) due to labour shortages during the tourism season, while Japan has lots of workers who work many unproductive hours (some just go to the office for the sake of going). I'd say they're different policies for quite different contexts.
If the tablet has both mainline kernel and uboot, it shouldn't be too hard for someone with embbeded Linux experience to port other distros over. However, there's quite a learning curve to doing it yourself.
That was possible before when targeting RV32. If I understand correctly, this makes it possible for LLVM to use all RISC-V extensions supported by the core with a simple command line (the patch describes what features the core supports), resulting in better-optimized code.
However, to run any language on the Pi Pico, that language still needs to interop with Pico's SDK, which you'd have to do manually if no one created bindings yet.
Even if someone got unsigned machine code execution on V8's or SpiderMonkey's JIT, the same could happen on JavaScript Core. All browsers could be vulnerable to something like this (it's just a matter of time before a vulnerability appears), and Apple should be focusing on securing their app sandbox.
In terms of privacy and third party apps, isn't the protection domain name based? Those are native apps, so browser protection wouldn't work.
