Support for ARM targets in Visual Studio

Since Windows 8 will be able to run on ARM devices, does anyone know what support VS will be getting for ARM targets? Specifically, I'm wondering whether we can for instance write a C++ application and set specific ARM microcontrollers as the target CPU.

Now this gets a bit complicated because MS might set VS up such that if you set ARM as the target CPU, it will always be assumed that the application will be running under Windows. Other ARM compilers allow you to specify all sorts of options, like the memory layout etc, which could be different for each of the huge amount of microcontrollers out there.

Or put another way, would I be able to use VS to compile C++ code that can run on an ARM microcontroller of my choice (based on the microcontroller specifics I supply) as a native application, without Windows on that microcontroller?

The reason I'm asking is because I'm working on a .Net->C++ crosscompiler right now, but having to compile the generated C++ code to ARM using tools external to VS is a pain (currently the generated C++ is compiled to x86 for testing purposes). I'm trying to completely eliminate that step of requiring expensive 3rd party tools (or just the hassle of it even if you can get it to work with the free tools).

My current thought is to compile the IL directly to ARM machine code, but this requires an ARM compiler. The ARM instruction set is not that complex, but even so it would be a big project to go from IL to ARM code. If VS will support ARM compilation to arbitrary CPUs, then I might be able to take advantage of that.

My bet is probably no. VS will target the ARM architecture supported by Win8 and nothing else.

@PaoloM:

Yea you are probably right. It would really be great if we can use VS to target ARM microcontrollers. They already have almost all of the pieces in place (compiler for WinCE, WP7, and now Windows 8, and there is already an ARM emulator as well), so it might not be too hard to do this for them. I know this might not appear to be in MS's best interest but consider that if you are going to target one of those microcontrollers, then you probably aren't going to run Windows anyway (most embedded applications don't need a full OS). Instead MS can have additional VS sales.

I've been looking at ARM tools and it is not pretty. Decent IDEs cost up to $6000, and they are all clunky and look like they are stuck in the 90's. The free/cheap ones are a pain to set up. There might be a market for MS here if they add the ability to VS to have arbitrary ARM targets.

The biggest problem with this is probably the fact that there is a bewildering amount of ARM microcontroller variations out there, each needing their own configuration file in order to allow the compiler to create the correct output (memory layout, IO configurations, peripherals, etc etc).

@BitFlipper: You have to remember that the CPU isn't the only variable. You have to consider the chipsets to control all the peripherals.

@cbae:

Yes you are correct. That is what I meant with the last paragraph, but I updated it to be a bit clearer.

@BitFlipper: Couldn't you leave the project as "AnyCPU" and have the code JITed to whatever it needs to be?

@spivonious:

In this case I'm talking about having to compile ARM code for microprocessors that have limited flash and RAM sizes, around 512K flash and 64K RAM. These can't run the full version of Windows, or even just .Net. There are some of these that run .Net Micro Framework, and I have been playing with a few of these (Netduino and Fez Panda II).

The biggest problem with them is that .Net MF code runs slow, about 100 to 1000 times slower than native code on the same microcontroller. This is because the code is always interpreted and never JITed. And I suspect the reason it is never JITed is because a JITter in itself takes a lot of resources, and then it needs to emit new code that itself takes even more memory. It is just impractical.

I have been playing around with my own pet project that takes a full .Net compiled exe and uses reflection to examine the IL, from which it generates C++ code (it does a static code path analysis in order to strip out any types and code that your code doesn't actually use). That code contains its own CLR runtime that supports GC, threading, type checking, generics, etc. This code can then be compiled to a stand-alone native exe that doesn't need anything else to run. So far I have only been compiling the generated C++ code to x86 and testing it on my PC (with great results so far). The idea is to use external tools to compile that C++ code to ARM code, but I came to the realization that this is always going to be a pain because the ARM tools are either really expensive ($6000), or the free and cheap tools are clunky and difficult to set up (actually, even the expensive ones are a far cry from VS).

So my latest idea is to modify my .Net->C++ compiler to generate native ARM code instead. Which is quite a big task for one person. And this is why I was wondering what support VS will be getting down the line for ARM targets. While compiling code for microcontrollers doesn't seem like MS's market, they do have most of the tools in place to have a complete dev environment to support this, and if you consider how many alarm clocks, washing machines, and what else you have that need some form of intelligent control, that has to be a large market. And all of those have been using tools that are stuck in the 90's, even the most expensive ones.

Visual Studio doesn't and won't be supporting microcontrollers as a backend format for quite some time. You can however purchase a commercial microcontroller compiler and use it as the backend from within Visual Studio by using a custom build rule.

@evildictaitor:

Yea that is pretty much what I figured. In the meantime I'm going to try and see if I can retrofit my .Net->C++ compiler to emit ARM code instead.

BTW, the ARM instruction set is pretty interesting. In some ways it is very simple as there are only a relatively small set of base instructions. Check out this PDF that describes the instructions in detail in only 64 pages. Note that every single instruction can be conditional, not just branching as in the case of x86/64. So an ADD, SUB, load/store registers, push/pop or whatever can have an added condition. This allows you to create very efficient code, but I have a suspicion it is going to be difficult to create optimized ARM instructions from IL instructions. I might just need to do it the naive way and map them 1:1 for now, and play with optimizations later on. I think even such a naive approach would result in code that performs much much faster than what you get right now from the current .Net Micro Framework.

@BitFlipper:

Right, ARM is RISC.  There's also a 16-bit THUMB instruction set for programs that need to run in small space.

Any one know when ARM will become obsolete, when Moore's law tosses it into the garbage can?

Kinda like how the 80286 computer was the biggest selling computer one year, then obsolete the next when the 30386 came out. I was fortunate enough to skip right past the 80286, jumping from a 4 MHz 8088/86 to a 20Mhz 80386.

I had to spend a small fortune to buy a computer capable of running the Windows NT beta and SDK, $4,500 ($7,000 in todays dollars) for a 50 MHz 80486 with 16MB of ram and a 1x speed CD rom drive.

@Proton2:ARM refers to the architecture rather than a specific model, in much the same way we generally use x86 to refer to the whole line of processors. So there's not much chance of it become 'obsolete' any time soon.

ARM refers to the architecture rather than a specific model, in much the same way we generally use x86 to refer to the whole line of processors. So there's not much chance of it become 'obsolete' any time soon.

I like to think of ARM as missing instruction sets that the x86 architecture has so that the x86 for example can carry out in one clock tick what the ARM cpu would take many clock ticks to complete, thus the x86 is much faster. When Moore's law brings the size and power consumption down to a point where heat and battery life are no problem, then thats when ARM will become obsolete. I don't know when this will happen but it certainly seems that it will happen before this decade is out.

Or am I missing something about ARM that someone could enlighten me on?

I like to think of ARM as missing instruction sets that the x86 architecture has so that the x86 for example can carry out in one clock tick what the ARM cpu would take many clock ticks to complete, thus the x86 is much faster. When Moore's law brings the size and power consumption down to a point where heat and battery life are no problem, then thats when ARM will become obsolete. I don't know when this will happen but it certainly seems that it will happen before this decade is out.

Or am I missing something about ARM that someone could enlighten me on?

ARM isn't missing anything - it's Turing Complete. It can do anything that x86 can do. And although x86 processors tend to be faster than ARM processors, they're also usually much more power hungry per operation which makes it less useful in phones and fridges.

2 hours ago,evildictait​or wrote

*snip*

ARM isn't missing anything - it's Turing Complete. It can do anything that x86 can do. And although x86 processors tend to be faster than ARM processors, they're also usually much more power hungry per operation which makes it less useful in phones and fridges.

I would tend to think that there wouldn't be too much concern for the power efficiency of the CPU inside of a fridge.

...they're also usually much more power hungry per operation which makes it less useful in phones and fridges.

If the x86 can complete a task 4 times faster and use only 2 times the power an ARM would use, the x86 ends up being twice as efficient.

And don't forget, I am talking about a future process node technology at perhaps the 9 nM size or some such where power efficiency is orders of magnitude better than todays chips.

If the x86 can complete a task 4 times faster and use only 2 times the power an ARM would use, the x86 ends up being twice as efficient.

Lightweight ARM processors use somewhat less than half the power of a fully featured Intel x86 processor.

And don't forget, I am talking about a future process node technology at perhaps the 9 nM size or some such where power efficiency is orders of magnitude better than todays chips.

That's why ARM has never really cornered the gaming or high-spec desktop machine market, and probably never will. ARM is much lower power than x86 for the same amount of information processing which makes it much better for scenarios where power is a big concern and can be traded for speed, i.e. small devices such as phones, possibly low-end laptops and even in HPC datafarms.

 evildictait​or wrote

 Lightweight ARM processors use somewhat less than half the power of a fully featured Intel x86 processor.

... ARM is much lower power than x86 for the same amount of information processing...

For certain scenarios, where there is no advantage of the extra circuitry inside of the x86 chip, ie: advanced instruction sets, ARM makes sense.

For other scenarios, the x86 can do the computing work far more effeciently than the ARM.

Now imagine a future scenario were we have smart phones with x86 chips running inside of them, the battery lasts all day, and the devices don't get hot while using them, and the software that runs on them is far more capable than what can run on an ARM based device. Maybe for a small amount of computing that takes place on such a device, it doesn't need all that extra circuitry, but so what, at least when you do need the processing power, its there for the user.