
CoreCLR building on ARM - shahid-pk
https://github.com/dotnet/coreclr/pull/1210
======
bpye
There is still work to be done,
[https://github.com/dotnet/coreclr/issues/1192](https://github.com/dotnet/coreclr/issues/1192)
. RyuJIT has legacy backend code and the new RyuJIT backend, only the former
is functional on ARM but won't be supported. Exception handling, also
unwinding for GC is seemingly blocked by an LLVM bug resulting in bad unwind
information being output for the exact build settings we need
[https://llvm.org/bugs/show_bug.cgi?id=24146](https://llvm.org/bugs/show_bug.cgi?id=24146)
. It is quite surprising to me how much visibility this has gotten though even
in the very rough state it's in now.

------
ghuntley
.NET everywhere, that makes five platforms in less than six months. Windows,
Linux by MSFT and OSX, FreeBSD, ARM done out in the open by the community via
GitHub pull-requests!

~~~
mattkrea
Try using it on Linux or OS X. It isn't there yet.

~~~
shahid-pk
So it is on windows too (As the software is in its beta phase) .

~~~
zamalek
RyuJIT is included with .Net 4.6, which RTM'd last week. It's production
quality on Windows. It's probably an older and more stable version of what is
on GitHub.

~~~
shahid-pk
You are correct. Ryujit is ready for production but coreclr has other parts
that are different from .net 4.6 and coreclr specefic (like PAL for non
windows) which is not production tested yet.

------
shahid-pk
Coreclr now compiles on arm tested on rasperi-pi 2. This port was a community
effort. It is still rough (debugging and exception handling not supported
currently) but it will reach their eventually.

------
rottyguy
Is Visual Studio written completely in .net at this point? Meaning will this
get ported over automagically once all the .net pieces are in place on other
platforms (assuming machine resources are available)?

~~~
Locke1689
Speaking for myself, not MSFT:

No, VS is a hellish mix of C++ and .NET. My personal prediction is that VS is
unintelligible and will never be ported to anywhere else.

~~~
saosebastiao
Isn't it amazing that code can get to that point? I mean, even insanely
complex things like space shuttles/stations are understandable. They're
documented, compartmentalized in functionality, and maintainable. If they need
to build onto it or swap out some functionality, they can do it. It's pretty
sad that we let some software turn into behemoths that don't accept change.

~~~
MichaelGG
I'm working on some C code now... functions that span a thousand (or more!)
lines. With all variables declared at the beginning, many having one letter
names or being reused at various points. With lots of chunks of code repeated.
Shit, one chunk of code writes out a whole XML format to a file. Then the
whole thing is is copy and pasted to write the same XML format to a socket.

To add to the incomprehensibility, add feature-hacks everywhere. "get_flag"
just does "thing->flags[name]". But "set_flag"? Hah, that's about 500 lines
long and has all sorts of secret logic. (Does your flag name have a '[' in it?
Does it start with "from_" or "to_"? Then you get a special code branch!)

And then, just to give you the finger, we'll sprinkle newlines everywhere,
seemingly at random, just to make the formatting look bad. Oh, and there won't
even be a line of documentation detailing which structs do what, or any
general logic or guide at all. But that's OK because code _is_ documentation.
Enjoy figuring out the custom "XML preprocessor" invented because "XML is too
limited".

This project was started fresh because a previous one was "bad". If you don't
have someone with a strong sense of aesthetics that can push back on feature
hacks and cheap implementations good intentions quickly decay.

~~~
danieltillett
I don’t mind large functions if they make sense. I have one (god) function
that is around 900 lines long, but it is just a series of function calls in
order that checks each call for errors. Keeping the code linear like this
reflects the data flow and makes it easy for me to remember the call order.

------
batou
Did anyone know they issued a CLR already that worked on ARM, PPC, OSX and
FreeBSD and is open source?

It even requires perl to build!

[http://www.microsoft.com/en-
us/download/details.aspx?id=4917](http://www.microsoft.com/en-
us/download/details.aspx?id=4917)

(they yanked official support for half of the bits bit its still in the tree)

~~~
shahid-pk
Their is a problem with that. First that is 15 years old and is not open
source (it is just source open). This was for educational purposes and first
ever implementation of the common language runtime. It was a prove of concept
project.

~~~
zamalek
> source open

"Shared Source." I.e. Never look at that code, ever. Just pretend Rotor
doesn't even exist. There are projects that will not have you (Mono) if you've
read Rotor code.

------
bigjake
The Raspberry Pi 2 port is not complete, but it is well on its way (props to
benpye who did the bulk of the work.)

The FreeBSD port is a community effort as well.

------
rcarmo
Niiice. Back when I tried doing some of this, it was pretty much an uphill
struggle.

~~~
ghuntley
Come join us over at
[https://gitter.im/dotnet/coreclr](https://gitter.im/dotnet/coreclr) we would
love to have you. Contributions are very welcome and are well received:
[https://sec.ch9.ms/ch9/d47a/a2eb1f1d-e95f-424d-8f40-e93e218c...](https://sec.ch9.ms/ch9/d47a/a2eb1f1d-e95f-424d-8f40-e93e218cd47a/firstdotnetportaward_high.mp4)

~~~
will_hughes
Non-GUID URL for that video: [https://channel9.msdn.com/Blogs/dotnet/First-
NET-Port-Award](https://channel9.msdn.com/Blogs/dotnet/First-NET-Port-Award)

(Side rant: I wish they'd just upload stuff to youtube, the C9 codec/cdn
support never works right for me, even on 100Mbit fibre the low quality
streams stall out)

