Much of the hosted machinery requires the ability to access memory on
syscalls. This feature was overlooked in the previous implementation of
ReplyAndReceiveNext, which caused it to not properly return memory.
Implement the ability to call `.memory()` on ReplyAndReceiveNext
messages.
Note that this requires the use of a sentinal value in the
previously-unused `valid` field.
Signed-off-by: Sean Cross <sean@xobs.io>
This call is used to return values while simultaneously listening for
new messages.
The -legacy suffix is used to disambiguate scalar values, so we know
whether to send Scalar1, Scalar2, or Scalar5 messages.
Signed-off-by: Sean Cross <sean@xobs.io>
This reflects the fact that up until now, the `Message` struct has
merely been the envelope that surrounds the message. It does not contain
any actual Message contents.
Signed-off-by: Sean Cross <sean@xobs.io>
With the addition of scalar5, existing api calls must be updated to take
advantage of it. This will allow `send_message()` to return a `scalar5`.
Signed-off-by: Sean Cross <sean@xobs.io>
Add syscall and return definitions for Scalar5, as well as
ReturnScalar5. This will enable us to pass up to five scalars as a
return from a blockingscalar call.
Signed-off-by: Sean Cross <sean@xobs.io>
The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
Look at `target_os` to determine whether to enter "hosted" mode or not.
If `target_os` is "xous", then the Xous standard library should default
to using builtin Rust libstd features.
If it is "xous", then we should instead use our arch-specific
implementations.
This enables third-party programs to directly use the `xous` crate
without specifying feature flags.
Signed-off-by: Sean Cross <sean@xobs.io>
the Vex has a custom flush instruction, after contacting
charles he recommends maybe adding some nops to make sure it
completes (maybe hardware bug? unclear. we're about to find out.)
This allows for a more reliable detection of target_os configuration
in build scripts. The target is inconsistent between some architectures,
notably armv7a is `armv7a-none-eabi` skipping the `unknown` (the vendor,
I guess) part. This happen with some of the unrelated Cortex-M targets
present, and others may also be.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
this will help speed up performance profiling as we can
resolve the physical address of the performance buffer allocated
in RAM and use a USB command to read it out, instead of streaming
it over serial.
