I think this post illustrates what Rust is close to... Hello,****
My interest in Rust is from the point of view of an embedded microcontrollers running bare metal programs with no underlying OS. I decided to explore what the language offers in that space by creating an actual running program. For the target I used STM32F4Discovery board since it has an ARM CPU which is already supported by the compiler. What is special about this board with comparison to the Android port is that it has only 192K internal memory (no SDRAM) and no MMU.**** ** ** You can find the project at https://github.com/neykov/armboot.**** ** ** For the first step I chose the fastest approach possible – to generate an intermediate .ll, convert it to assembler and compile it with the gcc cross-compiler for the target (arm-none-eabi). One change was required to the compiler to skip the generation of function prologue for split stacks (see https://raw.github.com/neykov/armboot/master/rustc.patch). This version supports only static memory allocation, though heap access (owned pointers) is easily implemented (i.e. use malloc/free linked to newlib). Zero.rs is used so no managed pointers and garbage collection.**** The generation of the executable file is automated. After generation the .ll file is corrected so it works with unpatched llvm 3.4 and the .note.rustc section is removed so it doesn’t take space on the target device.**** ** ** Major points from the effort:**** **· **I ported a basic C program to equivalent safe Rust program (see main.rs vs blinky.c). It is interesting because it uses an interrupt callback for the actual blinking logic.**** **· **The platform definitions were needed – like IO register locations and memory layout. I created a subset of them, mostly by hand, taking the output from rust-bindgen for the structures. All the #defines and enums had to be created as macros so as not to allocate actual memory on the device if declared as static (which I tried and ran out of memoryJ ). This is somewhat cumbersome since it requires adding “!()” but not a huge problem.**** **· **“unsafe” is not a normal block and doesn’t return a value, can’t be used as an expression. This made it impossible to wrap the unsafe casts from fixed memory locations to borrowed pointers in macros. Instead I had to use inline functions and assign the resulting value to a local function variable.**** **· **No “volatile” equivalent in Rust – currently all code is compiled with disabled optimizations so IO code is not optimized away. Another possible workaround is to use extern “C” functions to do the actual hardware communication.**** **· **I couldn’t move the platform code to a separate library since macros can’t be exported (I saw that this is still a work in progress according to #3114 so not a long term problem).**** **· **There were problems with the code comments in the original source files (i.e. see https://github.com/neykov/armboot/blob/master/sys/inc/stm32f4xx.h). I got compile-time errors because of the special symbol combinations in them which are reserved in Rust.**** **· **No core/std since I used zero.rs.**** ** ** As a future development I will look into adding support for the arm-none-eabi target by the Rust compiler and getting at least part of “core” working on the target device in memory constrained environment.**** ** ** Svetoslav On Wed, Jul 17, 2013 at 1:14 PM, Geoffrey Irving <[email protected]> wrote: > On Tue, Jul 16, 2013 at 9:55 PM, Bennie Kloosteman <[email protected]> > wrote: > > "You really can't have this both ways. Either features like traits and > > implementations matter, in which case my programming in the large > concerns > > come into play, or those features don't matter, in which case Rust isn't > an > > enhancement of C. Pick one." > > > > Why cant i have a large standard lib ...with traits and use a lot of c > style > > modules in my code "modules" ? Together they form a large app... > > > > By "module" i wasnt thinking a rust crate , more say a WCF service .. > with > > loosely coupled message style async communication via pipe / shared > memory. > > C# can do it but C# cant do it pauseless ... nor can i build such a > > framework in C#.. > > > > "App architecture is unquestionably important. No argument. Nonetheless, > > mistakes in the language design - in this case the absence of lexical > > scoping for impls (aka type class instances) - can destroy any hope of > > success for the best imaginable architecture." > > > > I dont think it stopped Haskell ... and for the system programming core > it > > will be even less important ... Im quite sure you can write s decent > kernel > > or service with rust .. Im not convinced you can do a 3D app ( in non c > > style) due to the large amount of concpets embeded in the types . That > said > > it imay still better than C++. > > Am I correct that this discussion is about whether orphan instances > are important? If so, banning orphan instances makes a language > substantially worse than C++, in ways that will certainly damage even > medium scale software. > > One easy example from our code is an overloaded "to_python" function > that converts certain C++ objects into Python objects. Say the > to_python trait/type class is declared in library A, there's an > unrelated library B written by someone who doesn't care about Python, > and library C depends on both A and B. As soon as C wants the ability > to convert B's types to Python, we have orphan instances. > > C++ solves this by making namespaces open, so that C can inject > to_python overloads into B's namespace to be found via Koenig lookup. > This may be a hack, but it's an extremely useful one that I would not > want to lose. > > Geoffrey > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
