Port to ARM

[brson]

No description provided.

[bblum]

I was talking with an older researcher friend today at a phd orientation potluck, who knows things about arm, and it seems there will be substantial challenges beyond just writing some new assembly code.

two issues on my mind; i am sure there are more:

• non-coherent memory when using send() (and perhaps in the task spawn path too, but super-likely to be problematic with pipes). you write into the buffer and set the flag, but the other thread can see the flag set before the buffer is initialised. an easy fix would be to insert memory barriers, but it might be worth investigating more clever ways of doing it, to recoup performance.
• atomic intrinsics are no longer so guaranteed. since (cmp)xchg are implemented in terms of ll/sc, there's an extra possibility for failure -- for example, you can get paged out to disk in the middle of an ll/sc, and then the sc will fail even though no other thread interfered. this is super-obviously-wrong in the case of arc::unwrap's implementation (it uses cmpxchg to ensure only one task can get into the unwrap path), and I bet that the use of naked xchgs in pipes might need similar reworking.

(and, of course, probably an entire audit of the concurrency libraries would be prudent...)

[bblum]

now that I think about it, I believe it shouldn't be too hard to write a cmpxchg wrapper with ll/sc that is capable of distinguishing failure modes should not be too hard. so in the case of arc::unwrap, which is much like trylock.

what used to be:

let my_data = ~new_unwrapper_data();
if cmpxchg(&mut unwrapper_data, my_data, 0) {
    // success path
} else {
    fail ~"another task is already unwrapping"
}

becomes (of course this should be wrapped, not open-coded):

let my_data = ~new_unwrapper_data();
loop {
    let oldval = load_linked(&mut unwrap_data);
    if oldval != 0 {
        fail ~"another task is already unwrapping"
    }
    if store_conditional(&mut unwrap_data, my_data) {
        // success path
    }
    // got interrupted / swapped out? keep trying
}

also, @eholk believes that llvm provides the correct semantics for xchg intrinsics already for the given architecture.

[kud1ing]

See the Android tickets: https://github.com/mozilla/rust/issues?labels=A-android&page=1&state=open

[sanxiyn]

I consider this done.

[radare]

android is not the only ARM target. i would love to use rust on rpi, should this bug be reopened to support arm-linux-gnueabihf triplet targets? it shouldn't be too much different from android and will be more generic.

[thestinger]

@radare: I think that should be a new issue, since the port to the ARM architecture itself is done and it would probably just involve build system tweaks to add other triplet targets.

[radare]

Done #5903

On 04/16/13 12:52, Daniel Micay wrote:

@radare https://github.com/radare: I think that should be a new
issue, since the port to the ARM architecture itself is done and it
would probably just involve build system tweaks to add other triplet
targets.

—
Reply to this email directly or view it on GitHub
#1858 (comment).

[frogshead]

---- alkuperäinen viesti ----
Lähettäjä: Daniel Micay
Lähetetty: 16-04-2013, 13:52
Vastaanottaja: mozilla/rust
Aihe: Re: [rust] Port to ARM (#1858)

@radare: I think that should be a new issue, since the port to the ARM architecture itself is done and it would probably just involve build system tweaks to add other triplet targets.

---

Reply to this email directly or view it on GitHub:
#1858 (comment)