Re: [rust-dev] compiling Rust to C?

2014-07-18 Thread Cameron Zwarich
The biggest problem would be probably be handling stack unwinding (IIRC the 
LLVM C backend never tried to handle this either). The only option when 
targeting C is to use setjmp / longjmp, but that is going to be pretty 
inefficient. Alternatively you could just abort instead of unwinding.

Cameron

On Jul 18, 2014, at 12:29 AM, Josh Haberman jhaber...@gmail.com wrote:

 Is there any prospect of compiling Rust to C anytime in the mid to near 
 future?
 
 This would be a really attractive option for anyone who wants to write
 in Rust, but wants the extreme portability of C.
 
 Actually maybe I should first ask if this is actually a tractable
 problem. Are there technical reasons that would prevent compiling Rust
 into portable C?
 
 LLVM's C Backend seems to have fallen out of maintenance -- would this
 provide the solution I am looking for, if it were maintained?
 
 Thanks,
 Josh
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] compiling Rust to C?

2014-07-18 Thread Josh Haberman
On Fri, Jul 18, 2014 at 12:35 AM, Cameron Zwarich zwar...@mozilla.com wrote:
 The biggest problem would be probably be handling stack
 unwinding (IIRC the LLVM C backend never tried to handle
 this either).

Interesting, I can see what that would be a challenge.

 The only option when targeting C is to use
 setjmp / longjmp, but that is going to be pretty inefficient.

Why do you think of setjmp/longjmp as inefficient? If you use the
_setjmp/_longjmp variants that don't fiddle with the signal mask, they
seem pretty efficient to me.

The bigger problem with setjmp/longjmp to me is that they don't let
you clean up variables sitting on the stack, as Rust language
semantics do I believe?

I can think of a way to do this portably, but it costs two extra
pointers every time you declare any stack variables. Basically you
could, every time you declare local variables, make them part of a
struct that has a pointer to the enclosing local var struct, and a
pointer to an unwind function. Then when a task fails, traverse this
list of frames and run the unwind function for each one before calling
longjmp().

It's wasteful of stack space (since this is basically duplicating
unwind info that exists at the system level, like in .eh_frame), but
it is portable.

In any case, it sounds like no one is working on this, so it's
probably unlikely to happen unless someone takes it up. Thanks for the
info!

Josh
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] compiling Rust to C?

2014-07-18 Thread Cameron Zwarich
On Jul 18, 2014, at 9:52 AM, Josh Haberman jhaber...@gmail.com wrote:
 
 The only option when targeting C is to use
 setjmp / longjmp, but that is going to be pretty inefficient.
 
 Why do you think of setjmp/longjmp as inefficient? If you use the
 _setjmp/_longjmp variants that don't fiddle with the signal mask, they
 seem pretty efficient to me.
 
 The bigger problem with setjmp/longjmp to me is that they don't let
 you clean up variables sitting on the stack, as Rust language
 semantics do I believe?
 
 I can think of a way to do this portably, but it costs two extra
 pointers every time you declare any stack variables. Basically you
 could, every time you declare local variables, make them part of a
 struct that has a pointer to the enclosing local var struct, and a
 pointer to an unwind function. Then when a task fails, traverse this
 list of frames and run the unwind function for each one before calling
 longjmp().
 
 It's wasteful of stack space (since this is basically duplicating
 unwind info that exists at the system level, like in .eh_frame), but
 it is portable.

This is more along the lines of what I meant. The 32-bit ARM Darwin ABI 
actually uses this form of exception handling, and LLVM has some support for 
it. Unlike DWARF unwinding you incur a cost for every cleanup that you 
register, so it can be quite expensive. Having had to debug issues with it in 
the past in LLVM, I'm not sure I would really trust the codegen to be correct.

Cameron
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] compiling Rust to C?

2014-07-18 Thread Eric Christopher
On Fri, Jul 18, 2014 at 12:29 AM, Josh Haberman jhaber...@gmail.com wrote:
 Is there any prospect of compiling Rust to C anytime in the mid to near 
 future?

 This would be a really attractive option for anyone who wants to write
 in Rust, but wants the extreme portability of C.

 Actually maybe I should first ask if this is actually a tractable
 problem. Are there technical reasons that would prevent compiling Rust
 into portable C?

 LLVM's C Backend seems to have fallen out of maintenance -- would this
 provide the solution I am looking for, if it were maintained?


FWIW I removed the C Backend a few years ago because it was largely
unmaintained. It would likely need to be rewritten from scratch to do
this. If you're curious about it, let me know.

-eric
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev