this allows the ADC to depend on core HAL services. It's structured
so that other 'misc' services would go into the "other" module,
just to keep the overhead of threads/services down a bit. Up until
this point all the other services mapped to existing/other
server names, like the RTC, susres, etc.
This will hopefully save some troubles for developers who
accidentally invoke a divide without realizing it.
Prints an error with instructions on how to resolve the
situation.
- handle .rodata, .data, .bss, .set labels better. This allows
for static globals
- handle call instructions. These are manually resolved by
changing the call pseudo-instruction into a jal with a rust
assembly-compliant label.
1. we can't resolve jump tables in Rust assembly. The label
grammar isn't rich enough to do this. As a result, this code
genreation method is suppressed.
2.there is no 'div' instruction on this PicoRV, so the +m is
converted to +zmmul, which correctly emits mulitplies, but
skips the divide.
A soft divide library is provided for programs that require
division.
This C routine incorporates statics, arrays, globals,
switch/case, division, and a bunch of other stuff that
is designed to exercise corner cases in the assembly conversion
script.
The program itself just cycles LEDs in a rainbow vomit pattern.
the reason we do this is that if we don't switch off library
modules, they are compiled in and just become dead code in the
OS image. with enough modules, this will eventually become
a significant drag on binary size.
This macro introduces page-level padding around the BIO code
regions, so that the rust assembler/linker computes relative
offsets correctly. This is necessary for code that is
autogenerated from C that uses `statics`
It's not recommended to be used *everywhere* because even
tiny BIO snippets of a few bytes would be blow up to 4k each.
erratum_check.py will automatically scan bio_code! segments
in a .rs file, flag patterns that could be a problem, and
can automatically patch these, if requested.
Getting compiled code going has revealed a couple of frankly
embarassing erratum in the BIO. Kind of shameful to make such
a n00b mistake but I guess my sole defense is I had to put it
together in a hurry with little resources.
Here's the bugs:
BUG 1 ("phantom rs1"): For lui/auipc/jal, the 5-bit field at
instruction bits [19:15] is not gated off. If that field decodes
to register 16-19 (x16-x19) for just these instruction types,
a spurious pending read is made from the corresponding FIFO,
which affects correctnes and can block execution.
BUG 2 ("phantom rs2"): For non-R/S/B-type instructions, the 5-bit
field at instruction bits [24:20] should be gated off but isn't.
When that field equals 20 (0b10100), a spurious `quantum` signal
triggers, which can affect the instruction fetch pipeline
This script inspects the output of the Clang assembly, and in the
process of translating it to Rust assembly, transparently patches
almost all of the cases with work-arounds. The assumptions and
exceptions for the work-arounds are:
- The stack pointer is initialized and valid. This is always
true for Clang-derived scripts because it's in the _start()
routine
- No interrupts that can mutate stack: true because interrupts aren't
supported in this implementation.
There is one edge case that isn't covered: J-type instructions
aren't patchable at this stage because the label offsets haven't
been resolved into instructions. However, "naked" jal instructions
are rare in compiled code - it's always jalr, which is an I-type
instruction. This is noted as a warning when the script runs, and
is fixable by simply inserting a "nop" after the jal instruction
if the target is at the wrong address - this will shift the immediate
so that it no longer contains the 0x14 (decimal 20) pattern in
the immediate field.
An abomination: a zig-based C toolchain, installed via python,
compiles to clang assembly, translated by python script, into
Rust assembly. Then compiled and linked into your app.
Really tempting fate with this one...will I come back to this
commit in a couple years and be filled with regret?
Already, I have some misgivings - the zig toolchain is
definitely not stable, and has been through some API changes,
and doesn't run on all platforms. But - I forge ahead.
