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-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
