[HN Gopher] Parsing RISC-V assembly
___________________________________________________________________
Parsing RISC-V assembly
Author : azhenley
Score : 31 points
Date : 2020-10-26 20:13 UTC (2 hours ago)
(HTM) web link (web.eecs.utk.edu)
(TXT) w3m dump (web.eecs.utk.edu)
| jeff-davis wrote:
| If we move away from general-purpose computing toward a mix of
| specialized processors, will there be a whole set of standardized
| RISC-V extensions for GPU, ML, etc.? Or is RISC-V going to mainly
| stick to general-purpose code?
|
| 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?
| pavehawk2007 wrote:
| To my knowledge, and looking at http://riscv.org, this is
| supposed to be an open-ISA (instruction set architecture).
| Their specification allows chip manufacturers to write their
| own extensions using the "custom" opcodes.
|
| 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.
| narrationbox wrote:
| The SDKs for the non big name (Nvidia, Google, AMD)
| accelerators have very poor developer experiences. (Granted
| CUDA/ROCm isn't much better) A number of the embedded SDKs
| require you to use their custom framework and won't support
| Tensorflow/Torch models out of the box. Onnx and similar
| conversion frameworks target only the big name chips, not off
| the shelf generic AI accelerator chips. Embedded systems need
| more software engineering.
| jeff-davis wrote:
| So RISC-V is open, but the extensions are often proprietary?
|
| 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?
| pavehawk2007 wrote:
| Properitary = custom...it just means that it's particular
| to a single chip manufacturer. They have set aside opcode
| space for doing just that. RISC-V can't forecast everything
| someone will want to do with a RISC-V chip. Instead, they
| promise not to use those opcodes so that it won't conflict
| with a chip manufacturer's "custom" instructions.
|
| 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.
| thethirdone wrote:
| This works for the basics of RISC-V assembly, but fails for a lot
| of assembly code that GCC accepts. It should be fine for most
| human written code, but machine generated code is also common.
|
| Most notably, labels starting with a period are not accepted, but
| gcc generated assembly has tons of labels like that.
| [deleted]
| [deleted]
| azhenley wrote:
| Thanks! That should be an easy fix. The documentation is
| _terrible_.
|
| What else did I miss?
| thethirdone wrote:
| > Unfortunately, the documentation on legal syntax is
| absolutely terrible.
|
| 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.
___________________________________________________________________
(page generated 2020-10-26 23:00 UTC)