[rust-dev] How do I pass -march down to llvm from rustc?

2014-03-23 Thread Vladimir Pouzanov
I'm trying to experiment with rust and some embedded code. Currently I have to do a three-pass compilation: rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s arm-none-linux-gnueabi-as main.s -o main.o First,

Re: [rust-dev] How do I pass -march down to llvm from rustc?

2014-03-23 Thread Vladimir Pouzanov
Nevermind, I lost -O somewhere in between copying and pasting command line flags. Optimised version doesn't have any morestack references (which is strange concept though). On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov farcal...@gmail.comwrote: Figured out I can use --target thumbv6m

Re: [rust-dev] How do I pass -march down to llvm from rustc?

2014-03-23 Thread Vladimir Pouzanov
rustc to generate freestanding code given some additional options? On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.comwrote: Nevermind, I lost -O somewhere in between copying and pasting command line flags. Optimised version doesn't have any morestack references (which

Re: [rust-dev] How do I pass -march down to llvm from rustc?

2014-03-23 Thread Vladimir Pouzanov
to just compile the IR yourself (the stack checking is a target-specific machine pass, which is why it shows up with --emit asm but not --emit bc) On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov farcal...@gmail.com wrote: So it doesn't work in the end. rustc --emit bc with flags set

[rust-dev] matching on a few bits in int

2014-03-28 Thread Vladimir Pouzanov
There's one thing that I often have to deal in embedded code — doing match on a few bits from an I/O register, which is commonly u32: let val : u32 = ...; match (val 0b11) 6 { 0b00 = ..., 0b01 = ..., 0b10 = ..., _ = {} } You can clearly see two problems here: I need to provide a

Re: [rust-dev] matching on a few bits in int

2014-03-28 Thread Vladimir Pouzanov
to catch those type of errors! - Clark On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov farcal...@gmail.comwrote: There's one thing that I often have to deal in embedded code — doing match on a few bits from an I/O register, which is commonly u32: let val : u32 = ...; match (val 0b11

Re: [rust-dev] Static_assert on a hash

2014-03-30 Thread Vladimir Pouzanov
readable. Well... Maybe it's time to do some big macro for matching all the stuff and hope that compiler will optimise it anyway. On Sun, Mar 30, 2014 at 10:12 AM, Simon Sapin simon.sa...@exyr.org wrote: On 30/03/2014 09:50, Vladimir Pouzanov wrote: I have a chunk of code that toggles different

Re: [rust-dev] Static_assert on a hash

2014-03-30 Thread Vladimir Pouzanov
, gpio::SPI_MISO); // p13 - TXD would fail, because there's no SPI_MISO defined for port 0 pin 15. On Sun, Mar 30, 2014 at 11:41 AM, Simon Sapin simon.sa...@exyr.org wrote: On 30/03/2014 10:30, Vladimir Pouzanov wrote: That shifts the issue even more into runtime, doesn't it? My goal

Re: [rust-dev] Static_assert on a hash

2014-03-31 Thread Vladimir Pouzanov
That actually sounds like a good option, thanks! On Sun, Mar 30, 2014 at 11:22 PM, comex com...@gmail.com wrote: On Sun, Mar 30, 2014 at 8:08 AM, Vladimir Pouzanov farcal...@gmail.com wrote: gpio::Pin::new(0, 15, gpio::Out, gpio::UART1_TXD); // p13 - TXD compiles, but something like

[rust-dev] Porting some nesC features to rust?

2014-03-31 Thread Vladimir Pouzanov
I'd like to propose to extend the language with some concepts from nesC, which is a nice but quite unknown C superset outside of TinyOS world. The concept would allow better static polymorphism and better code optimisations and is loosely based on nesC modules/components. It might be possible to

[rust-dev] A new better way to build rust apps

2014-04-01 Thread Vladimir Pouzanov
I decided to switch away from Rakefiles (after I switched to them from Makefiles) and make a dependency generator / build system in rust to get 20% more coolness factor. Here's a sample config file: https://gist.github.com/farcaller/4c08908fe526e0631989. As you can see, the syntax is somewhat

Re: [rust-dev] Porting some nesC features to rust?

2014-04-02 Thread Vladimir Pouzanov
If I get it right, calls to traits are resolved in runtime (so, traits are kind of similar to C++ virtual methods). What I'm proposing here is a compile-time approach. Let's say we have the following trait: pub trait LCD { fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8);

Re: [rust-dev] matching on a few bits in int

2014-04-04 Thread Vladimir Pouzanov
I've submitted an RFC for this one: https://github.com/rust-lang/rfcs/pull/29 On Sat, Mar 29, 2014 at 6:14 PM, Bill Myers bill_my...@outlook.com wrote: I think the best solution is to add uN and sN types where N is not a power of two, which LLVM should already support. Then you can write

[rust-dev] Building a static array of pointers

2014-04-04 Thread Vladimir Pouzanov
Is it possible to port the following C code to rust? __attribute__ ((section(.isr_vector))) void (* const isr_vector_table[])(void) = { _stack_base, main, // Reset isr_nmi, // NMI isr_hardfault,// Hard Fault 0,// CM3 Memory Management

Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Vladimir Pouzanov
like in C (note: I'm not saying `T*` and `T[]` are the same type, I know they aren't) On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin simon.sa...@exyr.org wrote: On 05/04/2014 11:39, Vladimir Pouzanov wrote: The problem is that [extern unsafe fn()] results in 8 bytes, pointer to the actual

Re: [rust-dev] matching on a few bits in int

2014-04-08 Thread Vladimir Pouzanov
!(do_something(), bits 4 to 8 { 0 = DivideBy1, 1 = DivideBy2, 2 = DivideBy4, _ = UnknownDivisor }; On Fri, Apr 4, 2014 at 7:11 AM, Vladimir Pouzanov farcal...@gmail.com wrote: I've submitted an RFC for this one: https://github.com/rust-lang/rfcs/pull/29

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
type T that implements LCD. fn fooT : LCD(x : T) { // x's type is T rather than LCD x.line(); // static dispatch based on type T known at compile-time } On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com wrote: On 02/04/14 06:25 AM, Vladimir Pouzanov wrote: If I get

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
{ spi: S, ... } and then: implS: SPI LCDS { ... } On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com wrote: I might have found an unsupported case. Consider the following: trait SPI { ... } struct McuSPI; impl SPI for McuSPI { ... } struct

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
object) doesn't implement `SPI` (the trait). You would have to explicitly implement `SPI` for `SPI`. I'm not really sure how to solve this without using trait objects; you seem to want an inherently dynamically-dispatched system. On Tue, Apr 8, 2014 at 2:08 PM, Vladimir Pouzanov farcal

[rust-dev] Convincing compiler that *T is safe

2014-04-13 Thread Vladimir Pouzanov
I have a number of I/O mapped registers that look like: struct Dev { .. // u32 fields } pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev; with macro-generated getters and setters: pub fn $getter_name(self) - u32 { unsafe { volatile_load((self.$reg)) } } unfortunately, calling a getter

Re: [rust-dev] Convincing compiler that *T is safe

2014-04-14 Thread Vladimir Pouzanov
, Apr 14, 2014 at 10:19 AM, Huon Wilson dbau...@gmail.com wrote: On 14/04/14 06:12, Vladimir Pouzanov wrote: I have a number of I/O mapped registers that look like: struct Dev { .. // u32 fields } pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev; with macro-generated getters

[rust-dev] LLVM doesn't inline my static, any good reason for that?

2014-04-20 Thread Vladimir Pouzanov
I'm working on a proof-of-concept implementation for https://github.com/rust-lang/rfcs/pull/44 [Linker placement attribute], and I actually got code that is working, but the outcome is worse than I expected. Consider the following snippet: #[unsafe_override_address] static Tinst : T = 1000;

Re: [rust-dev] LLVM doesn't inline my static, any good reason for that?

2014-04-20 Thread Vladimir Pouzanov
Apparently I had a problem of double pointer. The solution was to use static Tinst : 'static T = 1000; though I have modified the code now so that T works as well. On Sun, Apr 20, 2014 at 2:04 PM, György Andrasek jur...@gmail.com wrote: On Sun, Apr 20, 2014 at 10:46 AM, Vladimir Pouzanov

[rust-dev] morestack prologue contains broken machine code

2014-04-21 Thread Vladimir Pouzanov
Starting recently (no more than two weeks), rustc is generating a broken prologue for arm. Here's the sample assembly: 0x0f44 +0: push {r4, r5} = 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3} 0x0f4a +6: mov r5, sp 0x0f4c +8: b.n 0xa78 main+2616 0x0f4e +10: ands r4, r0

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-21 Thread Vladimir Pouzanov
find the initial commit for support at rust-lang/llvm [2]. [1] - http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html [2] - https://github.com/rust-lang/llvm/pull/4 On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com wrote: Starting recently

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-22 Thread Vladimir Pouzanov
to submit patch against https://github.com/rust-lang/llvm or send it to upstream? On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov farcal...@gmail.comwrote: Hm, it seems to have precautions to stop mrc from materializing on Thumb1. I guess I need to take a better look into what's going wrong

[rust-dev] A small announcement for zinc, the bare metal rust stack

2014-04-22 Thread Vladimir Pouzanov
This is the project I've been tinkering with for a good number of weekends — zinc, the bare metal stack for rust is available at https://github.com/hackndev/zinc. I've just finished a major refactoring work for LPC1768 code, so STM32F4 is kind of broken yet, and LPC1114 is totally dropped, but

Re: [rust-dev] A small announcement for zinc, the bare metal rust stack

2014-04-23 Thread Vladimir Pouzanov
Luckily enough, I had the concept for zinc even before I started coding in rust :-) And yes, there are lots of different oxides in rust world. On Wed, Apr 23, 2014 at 3:58 AM, Thad Guidry thadgui...@gmail.com wrote: Actually...I do not. :) On Tue, Apr 22, 2014 at 9:05 PM, Chris Morgan

Re: [rust-dev] A small announcement for zinc, the bare metal rust stack

2014-04-23 Thread Vladimir Pouzanov
simple, and I think that it might be possible to extend ~T ownership for something like that. On Wed, Apr 23, 2014 at 3:47 PM, Ben Gamari bgam...@gmail.com wrote: Vladimir Pouzanov farcal...@gmail.com writes: This is the project I've been tinkering with for a good number of weekends zinc

Re: [rust-dev] A small announcement for zinc, the bare metal rust stack

2014-04-24 Thread Vladimir Pouzanov
On Thu, Apr 24, 2014 at 9:01 AM, Ben Gamari bgam...@gmail.com wrote: Unfortunately this replaces the ugly possibility of unpredictable crashes with the slightly less ugly possiblity of unpredictable deadlocks if we run out of stack in the middle of execution. Perhaps threads could be

Re: [rust-dev] A small announcement for zinc, the bare metal rust stack

2014-04-25 Thread Vladimir Pouzanov
in .rodata, but we have #[link_section] to deal with that. * same as above, but use extern with further linker script placement (same way as I deal with ioregs in zinc). On Thu, Apr 24, 2014 at 11:37 PM, Ben Gamari bgam...@gmail.com wrote: Ben Gamari bgam...@gmail.com writes: Vladimir Pouzanov

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-25 Thread Vladimir Pouzanov
with writing tests or taking a peek at the patch if you want! I'm acrichto on IRC On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov farcal...@gmail.com wrote: The problem is that mrc is generated unless target is thumb1, but cortex-m3 is thumb2 that still doesn't support mrc: http

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-25 Thread Vladimir Pouzanov
believe that in the hopes of keeping it as light as possible it never makes any function calls. I do agree though, that it's at tricky situation in that case. How does TLS otherwise work for that platform? On Fri, Apr 25, 2014 at 8:14 AM, Vladimir Pouzanov farcal...@gmail.com wrote: I have

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-30 Thread Vladimir Pouzanov
I guess I've misread how __STACK_LIMIT works, it seems that I can change it's value on context switch so that it keeps track of the current running task. Works flawlessly, so I'm going to proceed with my original patch now. On Fri, Apr 25, 2014 at 6:33 PM, Vladimir Pouzanov farcal

[rust-dev] Symbol visibility problem

2014-04-30 Thread Vladimir Pouzanov
I have the following setup: libzinc, compiles as rlib, provides all the stuff support, compiles as obj, provides __morestack, memset/memcpy and other required things libapp, compiles as staticlib emitting obj, depends on libzinc, builds with lto. I link libapp.o and support.o to get the

Re: [rust-dev] Symbol visibility problem

2014-04-30 Thread Vladimir Pouzanov
that help your use case, or are you thinking of something more complex? On Wed, Apr 30, 2014 at 6:49 AM, Vladimir Pouzanov farcal...@gmail.com wrote: I have the following setup: libzinc, compiles as rlib, provides all the stuff support, compiles as obj, provides __morestack, memset

Re: [rust-dev] Symbol visibility problem

2014-04-30 Thread Vladimir Pouzanov
also had to move __STACK_LIMIT into external C file, as I couldn't define it as external in one crate and provide it in another crate down the chain. On Wed, Apr 30, 2014 at 5:29 PM, Vladimir Pouzanov farcal...@gmail.comwrote: Right, so I have a publicly reachable symbol __STACK_LIMIT inside my

Re: [rust-dev] morestack prologue contains broken machine code

2014-05-01 Thread Vladimir Pouzanov
, Vladimir Pouzanov farcal...@gmail.com wrote: I have a side question related to the same code. Currently __STACK_LIMIT is constant, but I would like the preamble to verify stack overflow for multithreaded context, i.e. __STACK_LIMIT will depend on the current running thread. Is there any

[rust-dev] How do I bootstrap rust form armhf?

2014-06-04 Thread Vladimir Pouzanov
I'm trying to run rustc on an arm board, but obviously there's no precompiled stage0 to build the compiler. Is there a procedure to cross-compile stage0 on other host machine where I do have rustc? -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/

Re: [rust-dev] How do I bootstrap rust form armhf?

2014-06-06 Thread Vladimir Pouzanov
Thanks, I managed to bootstrap my rustc already with a few hints. On Fri, Jun 6, 2014 at 4:19 PM, Valerii Hiora valerii.hi...@gmail.com wrote: I'm trying to run rustc on an arm board, but obviously there's no precompiled stage0 to build the compiler. Is there a procedure to cross-compile

Re: [rust-dev] how is Rust bootstrapped?

2014-06-09 Thread Vladimir Pouzanov
Rustc runs on arm just fine. On Mon, Jun 9, 2014 at 11:32 AM, Kevin Cantu m...@kevincantu.org wrote: Perl and Python may still be dependencies for small things on some platforms, IIRC, too. Anyways, to get `rustc` on a new architecture, it must be one LLVM supports, and then you should

Re: [rust-dev] Nightly docs for Dash

2014-06-14 Thread Vladimir Pouzanov
Funnily enough I did the same yesterday. I made a small extension to https://github.com/indirect/dash-rust, my fork can be found here: https://github.com/farcaller/dash-rust It removes the left side navigation panel from docs and adds TOC generation. On Sat, Jun 14, 2014 at 2:55 AM, Valerii

[rust-dev] Flatten a tree into HashMap, how do I pass a mut around?

2014-06-15 Thread Vladimir Pouzanov
I have a tree of Nodes where each node might have a name. I'm trying to convert the tree into a HashMap of named nodes, but my code is getting extremely complex due to the fact that I cannot pass mut HashMap around. let mut named_nodes = HashMap::new(); let nodes = vec!( ... ); named_nodes =

Re: [rust-dev] Flatten a tree into HashMap, how do I pass a mut around?

2014-06-15 Thread Vladimir Pouzanov
); return false; } else { map.insert(name.clone(), *n); } }, None = (), } } true } My failure point was that I didn't realise you cannot access mut while yo have a reference to anything you pass mut to. On Sun, Jun 15, 2014 at 8:14 AM, Vladimir

[rust-dev] What do I do if I need several muts into a struct?

2014-06-16 Thread Vladimir Pouzanov
I have a problem figuring the reasonable data access pattern for my code, here's a brief description. I have a tree structure where each node has a path and an optional name. Path is used to locate the node in tree hierarchy, names are stored in a flat namespace as node aliases: lpx17xx@mcu {

[rust-dev] A shiny test framework

2014-07-22 Thread Vladimir Pouzanov
I've just published a tiny test framework: shiny at https://github.com/farcaller/shiny. It's best used with hamcrest-rust. This library exists because I find it ugly to redefine all the initialisation code in every test case and I can't simply move it to a function due to problems with moving [T]

Re: [rust-dev] A shiny test framework

2014-07-22 Thread Vladimir Pouzanov
framework and Hamcrest assertions/matchers for Rust! On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko errordevelo...@gmail.com wrote: Dude, that's pretty much rspec ;) sweet! On 22 Jul 2014 20:07, Vladimir Pouzanov farcal...@gmail.com wrote: I've just published a tiny test framework: shiny

[rust-dev] Programmaticaly accessing compiler warnings

2014-11-01 Thread Vladimir Pouzanov
Hi all. Is there any way to access compiler warnings and errors other than parsing stdout? I'd prefer a bit more structured approach. -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org

Re: [rust-dev] Problems cross-compiling to ARM9

2015-01-01 Thread Vladimir Pouzanov
which uses the same instruction for any ARM device, may be that was patched in upstream, may be not. You can also ask Vladimir Pouzanov and zinc.rs [2] team, AFAIK they had the similar problem too and definitely have a workaround. [1] https://github.com/rust-lang/rust/blob/master/src

Re: [rust-dev] Declaring the API unsafe while keeping the internal safety checks

2015-01-02 Thread Vladimir Pouzanov
second attribute, lol, possibilities are endless. But indeed unsafe is likely only, currently, for memory safety. Still I like the idea! I love the idea. I read your email earlier today but only shortly ago I realize what you mean. On Jan 1, 2015 5:17 AM, Vladimir Pouzanov farcal...@gmail.com

[rust-dev] Cross-compilation with plugins is effectively dead?

2015-01-10 Thread Vladimir Pouzanov
I have some concerns related to https://github.com/rust-lang/rust/issues/18699 and I'd like to get some advice from the team. Support for cross-compiling code with plugins was broken for a few months now for anything but linux. Finally it seems to be broken for linux as well halting all our