Syntevo’s SmartGit is a Git client with Mercurial and Subversion support, and while I can not comment on its mg or svn support, its git and GitHub support is amazing. And the best thing is SmartGit is free for non-commercial use and runs on Mac OS X, Windows and Linux. Commercial licenses seem to be very reasonable and on par with other commercial git products.

When you are merging or rebasing hundreds of changing, doing that by hand from the cmd line is dreadful… I’ve been merging the newer branches of Mono into PlayScript and it can be painful since the Apache open-source version PlayScript was pulled by Zynga from Github two years ago without warning. When you are looking at hundreds of commits, and in a couple of cases, thousands of changes in between release tags and branches of Mono, doing that via the cmd line is doable, but it will give you nightmares. The SmartGui interface just works; walking the source tree, staging/unstaging, ours/theirs resolver, 3-way visual resolver/merge, markdown support, Github integration, etc… is just fast and clean and once you learn a few keystroke shortcuts that merge do done in a heartbeat. ;-)

I’ve used a couple of other git GUIs and merging and rebasing in them just not seem intuitive and the speed of their interfaces when dealing with a repo as large as Mono is killing me and I’ve ended up back in the cmd line.

I’m not going to do a full and comparative review as this product is free for non-commercial use, so just download a copy and take it for a test drive yourself. I doubt you would will be disappointed.

I posted up the PlayScript compiler 3.2.3001 to Github which is a merge of the mono-3.2.3 tag into the playscript-mono branch.

To speed up testing the merge, I am disabling a number of options in the build. Please log any issues via Github

./configure --with-mcs-docs=no --with-profile2=no --with-profile4=no --with-profile4_5=yes --with-moonlight=no --with-tls=posix --enable-nls=no --prefix=/Users/administrator/playscript-install

I posted up the PlayScript compiler (3.2.2002). This is the last posted release of the Apache licensed open-source version before Zynga pulled it from public domain.

I will be migrating it to the Mono 4.x compiler in the days and weeks ahead before working on finishing and getting the ActionScript language side stable (feature complete?). Not really looking forwarded to the Mono 4.x migration as the number of internal API changes to the mcs compiler since the 3.2.0 release is quite extensive.

If you want to compile and use the current 3.2.2002 release, just autogen.sh like normal.

Note: Due to dependency updates on OS-X since Mono 3.2 was release, I had to supply “ –with-tls” option as it was auto-selecting __thread instead of _posix.

./autogen.sh --with-tls=posix --enable-nls=no --prefix=/Users/administrator/mono-install

Note: Since this is mono 3.x, to build you will need gmcs during the bootstrap process. If you only have Mono 4.x installed, you will need a 3.x mono install to proceed. I just did a separate mono checkout of 3.2 and built it with a different install prefix location. When doing an initial/full compile and install, you can add this 3.2 install location to the front of your PATH and the default mono bootstrap will work cleanly.

In the PlayScript work that I am doing on the Mono mcs compiler, keeping the PlayScript compiler in-sync with Mono’s mcs can be a pain due to the large number of changes that occur on that repo.

While I have different ‘tricks’ to try to help merging, the first thing is you have to keep one branch of your fork in-sync with the original repo that your forked, mono/mono.git in my case.

I created two local clones of my GitHub forked repo and added an ‘upstream’ remote to the original mono repo.

1
2
3
4
5

git remote -v
origin    https://github.com/sushihangover/PlayScript.git (fetch)
origin    https://github.com/sushihangover/PlayScript.git (push)
upstream  https://github.com/mono/mono.git (fetch)
upstream  https://github.com/mono/mono.git (push)

One local clone is named PlayScript-master and the other is PlayScript.

The PlayScript-master is used to keep in-sync with the upstream repo, build the bleed-edge mono framework and compiler and run the mono unit-tests. This is so I always know what the current mono master looks like and how the unit tests are running so I can review the changes I am making in the local PlayScript repo and make sure that I am not injecting regression failures in the C# side of the compiler. (I’ll blog about that later). While the PlayScript-master repo will always Fast-forward on a “git merge upstream/master”, the PlayScript repo will not, I only merge one branch/tag mono release at a time to master branch and then merge/rebase playscript branch in order to maintain my sanity (some of the internal API changes on even Mono minor releases can drive a person to drink).

So to quickly update my master mono as it will always fast-forward, I have a script in the root repo called mono-master-update-install.sh.

1
2
3
4
5
6

cd ../PlayScript-master
git fetch upstream
git merge upstream/master
git push origin
make
make install

Note: You can add the mono unit tests to the end of that script if you wish.

Note:: I have the PlayScript-master master branch installing into a prefix of ~/mono-install and the PlayScript playscript branch installing into the ~/playscript-install. That way I can always switch quickly between the installed ‘released’ Mono framework, the pure bleeding-edge mono build and the PlayScript build with a simple path change.

Ok, you just have a major brain-fart and you did a merge from a remote that has more conflicts than the Sahel region… before you do ANYTHING to your local repo, just do a:

1

git reset --merge ORIG_HEAD

Or, depending upon your git version, you can also:

1

git merge --abort

The merge is gone and that list of 1000+ file conflicts that scrolled endlessly when you hit the return key will not haunt your dreams tonight.

Have a two local repos that you what to mash and merge together so you can live with just one local/remote repo?

Will, you are in luck, git allows a file based uri to be used vs. using https or git protocols.

1

git remote add NewRemoteName /file/path/to/existing/repo/.git

1

git remote add 2013nov22 /Users/administrator/Documents/Code/playscript/playscript-mono-2013nov22-compile/.git

I not sure when exactly -Xtheirs was added to git (~1.7.? timeframe), but it is a great and fast way to replace (overlay) all the changed files from one branch on top of another one without doing an interactive accept of each and every file, or doing a forced merge, etc… Great for document, multi-media files and other content that gets processed/accepted via a different pipeline and in a different branch and needs moved into a production/release branch.

Assuming you are already sitting in the branch that you wish to merge/replace those files into, you can do a git merge with the -Xtheirs option and supply the remote/branch that the files are coming from:

1

git merge -Xtheirs contentpipeline/version123

I needed to commit a limited number of changes that were already staged.

In the early days of git, I remember having to stash all the changes and pop only the changes that I need to commit and push. I’m not sure when the ‘–only’ option was added to commit, but it sure saves a bunch of extra steps:

git commit --only configure.in

I was trying to overlay just one directory within one git branch with the files from another branch (actually a tag in my case)) and could find a way to do it with just one git command.

So using git ls-files and xargs this is my solution:

git ls-files |xargs -J %  git checkout -f mono-3.2.4 -- %

If anyone has a way to do this without using xargs I’m all ears… ;-

GCC 4.9 is out with in the wild now with a long list of ARM enhancements. I’m hoping to look at into a few of the items on their change/log list.

One of them is the “-mslow-flash-data”, I’m really interested in what they are doing when this option is used. Using QEMU and LLVM I create variable and function usage maps during the last stage of speed optimizations and tag the high use items to be moved to RX to any remaining XRW (RAM) during startup in the reset_handler (would really be nice to burn that routine in the feedback loop of the LLVM profiler, need to create perf records that could be fed to the LLVM AutoFDO Converter that Google did and have it spew out ‘linker scriptets’…. too many ideas, not enough time at get them all done ;-)

So what is listed in the man for “-mslow-flash-data” is: Assume loading data from flash is slower than fetching instruction. Therefore literal load is minimized for better performance. This option is only supported when compiling for ARMv7 M-profile and off by default.

Is ARMv6 M-profile really excluded in whatever they are doing with mslow-flash-data? Only M3 and M4x support? Need to find the commit(s) for this feature.

Also everyone always loves items like: A number of code generation improvements for Thumb2 to reduce code size when compiling for the M-profile processors. Free code size reduction is always a great thing when during with those dirt-cheap Nuvoton NuMicro M0 chips, well, assuming it comes with using “-Os” and not with a speed impact when throughput matters more… small is good, but it is not always what everyone needs.

And the “Local Register Allocator” is turned on for ARM by default: The Local Register Allocator, introduced in GCC 4.8.0 for ia32 and x86-64 targets only, is now used also on the Aarch64, ARM, S/390 and ARC targets by default..

Getting it compiled on OS-X proved to be a pain as I do not have a native build of GCC, just clang acting as gcc, and could not get a ARM-NONE-EABI 4.9.0 version built using clang. One of the issues that I could not work around was:

1

clang: error: unsupported option '-static-libgcc'

Well, duh…, clang does not support that option, but not clear on why that is showing up under the 4.9.0 build using the same configure options as 4.8.x. Manually hacking on the make files to get passed this and I ended up getting into other issues, so I give up and built an OS-X ‘native’ gcc that I then used to build the ARM-NONE-EABI cross-compiler to get around the orginal “-static-libgcc” issue. Never had any problems doing a “make all-gcc” or “make all” to build gcc 4.8.x with clang->gcc before.

So I build a native version on the master branch (4.10.x now):

1
2
3
4
5

./gcc --version
gcc (GCC) 4.10.0 20140422 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And then used that to build my arm-none-eabi cross-compiler, yep, living on the bleeding edge with gcc and LLVM ;-)

1
2
3
4
5
6
7
8
9
10
11

./arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 4.10.0 20140422 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
...
  Known ARM architectures (for use with the -march= option):
    armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6
    armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m
    armv7-r armv7e-m armv7ve armv8-a armv8-a+crc iwmmxt iwmmxt2 native
...

FYI: I’m on OS-X 10.9.2:

1
2
3
4
5
6
7
8

Software  OS X 10.9.2 (13C64)
clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

ARM enhancements from the change list include:

• ARM:
• Use of Advanced SIMD (Neon) for 64-bit scalar computations has been disabled by default. This was found to generate better code in only a small number of cases. It can be turned back on with the -mneon-for-64bits option.
• Further support for the ARMv8-A architecture, notably implementing the restriction around IT blocks in the Thumb32 instruction set has been added. The -mrestrict-it option can be used with -march=armv7-a or the -march=armv7ve options to make code generation fully compatible with the deprecated instructions in ARMv8-A.
• Support has now been added for the ARMv7ve variant of the architecture. This can be used by the -march=armv7ve option.
• The ARMv8-A crypto and CRC instructions are now supported through intrinsics and are available through the -march=armv8-a+crc and mfpu=crypto-neon-fp-armv8 options.
• LRA is now on by default for the ARM target. This can be turned off using the -mno-lra option. This option is purely transitionary command line option and will be removed in a future release. We are interested in any bug reports regarding functional and performance regressions with LRA.
• A new option -mslow-flash-data to improve performance of programs fetching data on slow flash memory has now been introduced for the ARMv7-M profile cores.
• A new option -mpic-data-is-text-relative for targets that allows data segments to be relative to text segments has been added. This is on by default for all targets except VxWorks RTP.
• A number of infrastructural changes have been made to both the ARM and AArch64 backends to facilitate improved code-generation.
• GCC now supports Cortex-A12 and the Cortex-R7 through the -mcpu=cortex-a12 and -mcpu=cortex-r7 options.
• GCC now has tuning for the Cortex-A57 and Cortex-A53 through the -mcpu=cortex-a57 and -mcpu=cortex-a53 options. Initial big.LITTLE tuning support for the combination of Cortex-A57 and Cortex-A53 was added through the -mcpu=cortex-a57.cortex-a53 option. Similar support was added for the combination of Cortex-A15 and Cortex-A7 through the -mcpu=cortex-a15.cortex-a7 option.
• Further performance optimizations for the Cortex-A15 and the Cortex-M4 have been added.

• A number of code generation improvements for Thumb2 to reduce code size when compiling for the M-profile processors.

• AArch64:

• The ARMv8-A crypto and CRC instructions are now supported through intrinsics. These are enabled when the architecture supports these and are available through the -march=armv8-a+crc and -march=armv8-a+crypto options.
• Initial support for ILP32 has now been added to the compiler. This is now available through the command line option -mabi=ilp32. + Support for ILP32 is considered experimental as the ABI specification is still beta.
• Coverage of more of the ISA including the SIMD extensions has been added. The Advanced SIMD intrinsics have also been improved.
• The new local register allocator (LRA) is now on by default for the AArch64 backend.
• The REE (Redundant extension elimination) pass has now been enabled by default for the AArch64 backend.
• Tuning for the Cortex-A53 and Cortex-A57 has been improved.
• Initial big.LITTLE tuning support for the combination of Cortex-A57 and Cortex-A53 was added through the -mcpu=cortex-a57.cortex-a53 option.
• A number of structural changes have been made to both the ARM and AArch64 backends to facilitate improved code-generation.