On 06/21/2013 03:53 PM, Thomas Daede wrote:
On Fri, Jun 21, 2013 at 5:42 PM, Brian Anderson <[email protected]> wrote:
On 06/21/2013 02:53 PM, Thomas Daede wrote:
On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson <[email protected]>
wrote:
On 06/21/2013 08:20 AM, Thomas Daede wrote:
- Compiling runtime and Core without thread support

This is a major refactoring project which isn't made any easier by the
current situation in which we have 2 entire runtimes.

https://github.com/mozilla/rust/issues/7282
I'm not sure what you mean by two entire runtimes. Are you referring
to the split between core and std?

We are in the process of rewriting the old C++ rust task scheduler (which to
large degree is 'the Rust runtime') in Rust. At this moment and for at least
another few weeks there is an entire C++ runtime implementation in src/rt
and another in libstd/rt written in Rust. All the code paths in std that
depend on runtime state currently have branches to pick between the two
implementations, so an effort to refactor the libraries to create a
microcontroller profile will have to deal with additional complexity.


- Adding compatibility with the newlib C library

Last time this came up we preferred musl.

https://github.com/mozilla/rust/issues/7283
I had never heard of musl, but it looks like it's Linux only, whereas
newlib is designed for "bare metal" or RTOS-based systems.

- Adding configurable stack allocation

I'm not sure this means in this context. Can you elaborate?
Right now Rust uses a segmented stack, and I believe the stack is
allocated in 4MB segments - which is way too huge. It would be better
to be able to set the size of the segments - or maybe fix the size of
the stack(s).

I didn't imagine you wanted to use green thread scheduling still. That will
be interesting.

I was under the impression that *all* stacks in Rust were segmented
and bounds-checked. Is that not true for the main stack? If so, it
won't actually be a problem, though I was actually interested in
porting the scheduler at some point.

Rust does not necessarily require segmented stacks, though almost all existing code uses them. Even today if you override the `start` function (a more primitive `main`) with the `#[start]` attribute, you can run Rust code with no before-main runtime setup and will not be using segmented stacks.

One small correction though: Rust stack segments are not allocated in 4MB segments. The initial stack segment is somewhere between 3k and 21k depending on platform. From there each new segment doubles in size.



_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to