Yes, but it doesn't need any funny parsing trick to handle them. Just parse the whole statement as a list of expressions joined by operators, and then you can convert the flat list into a precedence-respecting tree with a few lines of code and an operator-to-precedence table.
Yes, it's as easy as that. Or check out Jonathan Blow on precedence.
The infamous dragon book convinced people to use the wrong tools and have the wrong mindset. It was a work of incompetence. There were no dragons, but the book itself.
Why do I get the overwhelming feeling that the author is not a technical person and they had a LLM write this based on some handwavey ideas? There's virtually no _there_ there.
"...demonstrates its capabilities through worked examples" - The hell it does, your "examples" are three lines long. If you're going to compare it with LLMs, then have it do something LLM-ish. Or hell, the MNIST number recognition task would be better than the "hey look i modeled a flip-flop in my funny language" example.
Am I being harsh? Yes, I am. The author is claiming that they have a system that can automatically generate code for "quantum" and "spintronic" computers, yet offers zero proof of that.
It's ok to be harsh — I was vague, and I know it. Here's why: I remember the story about DOS. Tim Paterson built it, showed too much, and someone else built an empire on it for $50K. I have working constraint rules that produce real circuit behaviors. The paper shows what comes out, not how it works, and that's deliberate. The patent is provisional. I'm not going to hand over implementation details on a forum so someone with more resources can run with it. You'd do the same thing.
The tool chains that Espressif seem to work pretty well with these as well as their earlier (some sort of RISC) processors. I have had some code, however, that did not produce desired results until I upgraded the toolchain.
The other issue I've run into is that some cell phone battery packs that work well with Raspberry Pis won't stay on with the RISC-V ESPs because they draw so little power the battery pack doesn't detect the load.
Silly opinion that has no relevance to building competitive CPUs, but I like that RISC-V is modular and you can pick and choose which extensions to adopt.
Makes writing a simulator so easy (just have to focus on RV32I to get started), and also makes RISC-V a great bytecode alternative for a homegrown register-based virtual machine: chances are RV32I covers all the operations you will need on any Turing-complete VM. No need to reinvent the wheel. In a weekend I implemented all of RV32IM, passing all the official tests, and now I have target my VM with any major compiler (GCC, Rust) with no effort.
If there is any architecture that scales linearly from the most minimal of low-energy cores to advanced desktop hardware is RISC-V.
Disclaimer: I don't know much about ARM, but 1) it isn't as open and 2) it's been around enough to have accumulated as much historical cruft as x86.
When ARM moved to 64-bit the ISA was much more substantially reworked than for AMD's x86-64 transition (which mainly added modes and repurposed INCrement and DECrement to provide the REX prefix which provides a 64-bit size specification and one additional bit for register name specifiers; obviously the page table format also changed). I am not particularly familiar with AArch64, but I got the impression that the main retained cruft from 32-bit ARM was condition codes and the tradeoffs of providing condition codes would lead some not to consider such cruft. The use of four bits for almost every instruction to support predication was eliminated — which was a major cruft point for 32-bit ARM — and the legacy of shift and perform ALU operation orientation of the original ARM (which had timing slack from the slowness of instruction fetch) was de-emphasized.
AArch64 is accumulating cruft, perhaps particularly with respect to SIMD, but it is less crufty than x86-64.
ISA modularity/diversity can be useful for embedded systems, where the software is really firmware. If one is going to have to provide a diversity of compilation targets via either a common distribution format that is compiled to the local machine code or an app store that receives a software format that can be compiled to diverse, the best distribution format (to users or the app store) is likely to be significantly different than an encoding best for direct execution.
Some optional features can be hidden by system libraries (particularly when the main use of the feature is suitable for a separate accelerator). E.g., an instruction that performs a round of AES encryption could be hidden behind an encryption library. However, some uses of an AES instruction involve a very short "message" for which library overhead would be excessive or for which good enough software alternatives would be faster than actual AES.
Indexed memory accesses and conditional select/move, for example, are not really suitable to system libraries (or trapping to software even with a very fast trap handler).
ISA scaling is not necessarily a good design feature. An ISA optimized for the market targeted by ARM M Profile is unlikely to be optimal for future 16-wide decode high performance processors. E.g., if a context only has 16 registers, using 5-bit register specifiers is suboptimal even though it allows software to be "upward compatible" with a 32-register design.
reply