The abi is allowed to change post 1.0. If it wasn't, we'd be stuck with cdecl
forever and that sucks.
I've only seen fastcall used for intracrate leaf calls.
Servo and rustc are the two biggest rust projects.
The mailing list is mostly dead BTW. Consider bringing this up on
discuss.rust-lang.org instead.
If you plan on playing with calling convention, aatch and I (cgaebel) have been
considering a rust-specific one. You should drop by on irc some time if it
interests you!
Happy to help,
- Clark
On Sat, Dec 27, 2014 at 11:39 AM, Andrea Canciani <ranm...@gmail.com>
wrote:
> I tried to collect as much information as possible from IRC and from the
> Web about TCO in Rust.
> The most recent (and authoritative) reference I can find is
> https://github.com/rust-lang/meeting-minutes/blob/e3c325c7e30331cb43e0c5b68f35070f211ee4cb/weekly-meetings/2014-05-20.md#tail-calls
> The decision seems to be that it is an interesting feature, but that it
> should be postponed for a future release.
> To me this looks like a good point, but I'm worried about potential
> backward-compatibility hazards.
> In particular, the "be" keyword has been removed from the language and the
> proposed alternative ("become") has never been introduced. Wouldn't it be
> easier to ensure backward compatibility if the "become" keyword was at
> reserved in rust 1.0?
> Another thing I'm worried about is callee vs. caller cleanup of the call
> stack. Changing the rust calling convention post-1.0 would break the ABI,
> so it would be very inconvenient.
> On IRC I was told that rustc was already using the LLVM "fastcall" calling
> convention, but
> https://github.com/rust-lang/rust/blob/master/src/librustc_trans/trans/base.rs#L310
> seems to indicate that the C calling convention is used instead.
> In several posts on the TCO, one of the points against supporting TCO was
> that it involves using a slower calling convention, but I was unable to
> find any benchmark to support that statement.
> Where can I find some discussions about the [dis]advantages of the
> different calling conventions and what design choices led to the current
> one?
> I would like to evaluate the performance (speed, code size) impact of
> changing the calling convention. What would be the best way to do this? Is
> there any "well-known" benchmark for changes that affect the overall
> behavior of the compiler?
> I would assume that rustc itself is probably one of the most interesting
> "real-world" applications written in rust right now. Otherwise, is the
> compiler shootout challenge sufficiently interesting for this purpose?
> Andrea_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
