Parsing RISC-V assembly
web.eecs.utk.edu
web.eecs.utk.edu
It's assembly, not anything like C, C++, etc. It's simple. You're supposed to be able to handle it with regexes.
> If you are looking for a hand-written lexer and parser for RISC-V assembly that builds a parse tree
Huh? Parse tree for assembly?
> For example, "xor xor, xor, xor, xor" will be parsed just fine, despite it not being legal RISC-V assembly.
Then ... why parse it??????
See, this is what happens when you refer to assembling as compiling. They are not the same.
No. If you're going to implement an assembler that supports constants and symbols which can be combined into expressions. And expressions can easily be parsed for example[0]:
〈primary expression〉->〈constant〉|〈symbol〉|〈local operand〉|@|
(〈expression〉)|〈unary operator〉〈primary expression〉
〈term〉->〈primary expression〉|〈term〉〈strong operator〉〈primary expression〉
〈expression〉->〈term〉|〈expression〉〈weak operator〉〈term〉
〈unary operator〉-> + | − | ~ | $ | &
〈strong operator〉-> * | / | // | % | << | >> | &
〈weak operator〉-> + | − | | | ^
Why not? The structure you need to represent something like
lea eax, [eax + eax * 4]
(I'm aware that RISC-V addressing modes are probably simpler than the x86 example above.)
If there are a ton of extensions, will we need to compile all code for a particular machine so that it generates the right code for that machine's mix of special-purpose chips? What will that mean for virtualization and/or containerization?
The Kendryte K210 is a RISC-V-compliant CPU. It has off-core components, such as what they're calling a KPU The ML and GPU cores are controlled via I/O, not by the CPU directly. These are called platform-level components. In general, this uses MMIO with a hard-wired memory address to control. You can see the KPU (their ML accelerator) here: https://s3.cn-north-1.amazonaws.com.cn/dl.kendryte.com/docum...
See section 3.2.
I think the extensions are meant to be modular. Right now, not many embedded devices allow for the H mode, and hypervisor-ing is still in development. Currently, I know of Machine mode, Supervisor mode, and User mode, but since the change from 2018 to 2019, they have really started to ramp up the virtualization ISA support.
And what does virtualization even mean when extensions proliferate? Will you need a distinct physical machine for each combination of extensions that someone might want to virtualize?
Here's a post from SiFive talking specifically about DSAs in RISC-V: https://www.sifive.com/blog/part-1-fast-access-to-accelerato...
In terms of virtualization, most of the extensions can be emulated. This happens a lot with the hodgepodge of extensions laid on Intel/AMD, such as SSE, SSSE, AVX, and so forth. Just because the underlying physical machine doesn't necessarily support it doesn't mean that the guest can't. At the operating system level, the OS can read the misa (Machine ISA) register to see which extensions are supported, and emulate those which are not. I don't think RISC-V solves the issues that virtualizing Intel/AMD also suffer--and I don't think that's really their goal.
In terms of the host, if there is an extension that cannot be emulated, then yes, I would think you'd need the physical machine to be able to support it.
Most notably, labels starting with a period are not accepted, but gcc generated assembly has tons of labels like that.
What else did I miss?
I totally agree. Determining the semantics of wierd assembly is even harder. At least for syntax you can just see confirm if gnu-as accepts it.
> Did I miss anything else?
I haven't looked into what is actually parsing at all, but it correctly accepts things like %hi, strings delimited by quotes, @function, labels that are just numbers. I had expected some of those to be rejects based on the post.
I don't know what else might fail because I can't try any auto generated code because of the period label issue. I would recommend trying the assembly generated by compiling this project; it shows a bunch of weird pieces of syntax.