Rust works fine with Cortex-M3/M4 (a bit larger than dsPIC, and their documentation isn't as nice as Microchip's). Library support isn't great though - try zinc.rs or roll your own. An STM32F4 Discovery board is $15. Just in case you didn't have enough to play with...
Shameless self-plug coming here, but it's pretty directly relevant: I've recently started tinkering with rust on a handful of STM32 "discovery" boards. I'm currently focusing on building a low-level environment to use as a foundation for higher-level HAL projects like zinc. The code is still pretty rough around the edges and evolving fast, but I'm open to collaboration and willing to help deal with breakage due to the current pace of change, as time permits, if anyone just wants to build something on it.
I was/am doing something similar (haven't touched it in a bit though).
I avoided putting anything in linker scripts that didn't have to be there (IIRC, memory blocks and VTOR (for assembly startup routine that can handle flash or RAM)). Peripheral addresses stayed in Rust so that the optimizer could see them (eg writing to RA and then RB, the high u16 stays the same).
BTW F103C8 "dev boards" are available from China for $5.
zinc's "ioregs" macro system takes care of that sort of optimization quite nicely these days, actually. For each peripheral register, one of the things it generates is an "update" structure that the optimizer can eliminate, which allows you to chain updates to multiple fields in a single write. For example, in my stm32f4-discovery "blinky" example it does the bsrr writes to flip 2 LEDs in a single write (I've inspected the generated asm to verify this).
EDIT: nevermind, I realize I misunderstood; you're referring to the optimizer being able to see that both reg addresses have the same high 16 bits. I thought you were referring to the actual interactions with the register contents. Yea, that makes sense.
EDIT 2: for what it's worth, i did a quick test just now and found that moving the addresses into the source actually made the generated code significantly worse. I'm just tinkering around on a lunch break and I need to get back to real work, so I can't investigate too deeply, but the 2 biggest factors I see are that (1) it simply doesn't perform the optimization you describe, and (2) it makes things even worse because rather than addressing relative to the peripheral base address it loads a complete new constant address for every operation.
I just remembered, hardcoded addresses are actually even more important for utilizing "bit banding" for atomic writes to peripheral registers. Not that you couldn't find a way to do this with addresses in the linker script, but it's more straightforward to handle efficiently with compiler optimization.
(And if one isn't atomically writing to control registers when interrupts are enabled, you are most likely building on a foundation of nondeterministic bugs. Rust's linear types kind of inform you of this, but to do anything useful the temptation is to unsafely share across threads)
re edit 2: Really? I'd obviously looked at my generated code and saw the expected improvement, so we must be doing something different.
Re edit 2: I'm pretty new at Rust so it's entirely possible I did something in an unusual way that caused the compiler to emit worse code than it would otherwise. My quick hack to test was to declare the registers as &mut, and assign them by casting a u32 literal to *mut, dereference and take &mut of that. It was just the first thing that actually compiled ;). I did also try directly transmuting the u32 to &mut and got the same output.
It's also possible something has changed in rustc since you were playing with it.
It's very possible rustc has changed, but I hope not because the generated code was looking pretty good.
My basic register write is volatile_store(($base as * mut u8).offset(idx as isize) as * mut u32, v); $base is just a hex literal address. There is an extra cast because I defined 'idx' in terms of bytes.
I might not have been concerned about the absolute smallest code when I accessed $base+4 then $base+8 (use of a small offset vs loading a second constant), but I definitely observed eliminating redundant loading of the high half between different registers.
I was compiling with "-O -Z no-landing-pads -C lto".
Well then go lobby for creating dsPIC support in LLVM! Selling 10M chips at a time is great and all, but designs start with a single engineer. The 16F84 was the hobbyist darling until gcc-avr ate its lunch.
PIC is not an open-source-friendly company. They literally wrapped a license manager around gcc and used it as their C compiler on several platforms, and their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc. If they did switch to LLVM, it'd probably be so they could closed-source their compilers completely.
Sheesh. I worked with their 8-bit chips in an era when using a C compiler was essentially just a nicer syntax for ASM (and you really didn't want to deal with code written by someone who thought differently). In that environment, their easily available good documentation is about as close as you can get to Free. Software complexity was of course on the rise and I figured it was only a matter of time until they "got it" with regards to a Free C compiler etc.
It's sad to hear that they've dug their heels in even further and are now one of the few examples of bad-faith attacking the GPL through contracts. Especially because recently reading their ENC28J60 documentation was a nice break after wading through STM/ARM's stuff.
If I'm ever again in a position where I'm choosing chips for a production design, I'll be verifying what you said for myself (diligence) and then steering clear to less risky alternatives.
> their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc
This is a quite serious concrete accusation. It would put Microchip in the company of Tivo and Sveasoft - not simply ignoring the GPL, but actively attacking it through bad-faith contractual restrictions.
But yes, I would definitely have to see the specific license for myself before forming any conclusions. HN is essentially just gossip, and GP could have very well interpreted a clause too broadly. But I'm not interested in sorting through what's new in the Microchip world just to preemptively answer this, especially because he could be referring to a single specific library that would be hard to find.
Microchip does have a standard license for maybe 99% of its firmware libraries, that includes this proviso, that just forbids you from using the software on microcontrollers made by other manufacturers:
Microchip licenses to you the right to use,
modify, copy and distribute Software only
when embedded on a Microchip microcontroller
or digital signal controller that is integrated
into your product or third party product
(pursuant to the sublicense terms in the
accompanying license agreement).
If there are any other restrictions, I'm not aware of them.
PIC is not the name of the company. It's Microchip Technology, Inc. You seem to be upset about something, since I don't think you have the facts straight about the XC series of compilers; the source code for XC16 and XC32 is posted here under "Source Archive" http://www.microchip.com/pagehandler/en-us/devtools/dev-tool...
Microchip has a number of open-source initiatives. You can use the internal guts of MPLAB X from Java via MDBcore, for example, as a scriptable debugger/simulator.
