Please review (XXXL) merge i486/amd64 and add 64bit client compiler

[steve goldman]

These changes have been out for review internally at Sun since Dec for 
the 1st piece and Jan. for the second piece. After a request I'm making 
them world visible. I'm not sure I expect a review but at least you'll 
see what is coming. These changes will not be committed for a while yet 
because I'm waiting for the flood of changes in the pipes to settle down 
now that the OpenJDK repositories finally opened so you have got a 
decent amount of time if you are so inclined. :-)

5108146 Merge i486 and amd64 cpu directories

http://webrev.invokedynamic.info/sgoldman/5108146/

This webrev merges the code in assembler_x86_[32|64].* into 
assembler_x86.*. The webrev shows it as assembler_x86.* as new files and 
assembler_x86_[32|64].* as unchanged. When the commit actually happens 
the 32|64 files will be deleted.

In addition to merging the assembler code the .cpp file was restructured 
so that the instructions are in alphabetical order and in 3 sections, 
generic, 32bit only, 64bit only. As a result the diffs for that file are 
incomprehensible.

As part of this there is a small step along the way to the "ptr"ization 
of the code. The next webrev to appear which contains the 64bit c1 
changes goes the rest of the way. With the changes here operations that 
only can do a full register sized operation don't have a size qualifier. 
So movl(Register, Register) or movq(Register, Register) are now 
mov(Register, Register). push/pop/bswap also don't have a qualifier either.

6459804 Want client (c1) compiler for x86_64 (amd64) for faster start-up

http://webrev.invokedynamic.info/sgoldman/6459804-1/
http://webrev.invokedynamic.info/sgoldman/6459804-2/

This webrev was so large that the infrastructure at invokedynamic.info 
wouldn't upload it as a single webrev so it is split into two pieces at 
an arbitrary point.

The changes here are layered as a patch on top of the changes for 
5108146. The changes in this request are in two flavors, "ptr-izing" the 
assembly code throughout the x86 directory and changes to c1 to produce 
a 64bit c1. The spelling changes that did the "ptr-izing" of the code 
may be controversial. I'm open to alternative spellings.

-- 
Steve