| 1 |
Shawn Haggett wrote: |
| 2 |
> |
| 3 |
> There's two points that come to mind. |
| 4 |
> |
| 5 |
> 1) mtune is a request for the compiler to make the code more suited to |
| 6 |
> the given processor, but without breaking compatibility. march is |
| 7 |
> telling the compiler, do everything you can to make this code fastest |
| 8 |
> on this processor. |
| 9 |
> |
| 10 |
> From the GCC docs for 4.2.3: |
| 11 |
> "-mtune=cpu-type: Tune to cpu-type everything applicable about the |
| 12 |
> generated code, except for the ABI and the set of available |
| 13 |
> instructions." |
| 14 |
> "-march=cpu-type: Generate instructions for the machine type cpu-type. |
| 15 |
> The choices for cpu-type are the same as for -mtune. Moreover, |
| 16 |
> specifying -march=cpu-type implies -mtune=cpu-type." |
| 17 |
> |
| 18 |
> So mtune shouldn't be using any instructions that are in K-6 that |
| 19 |
> weren't in a 386. |
| 20 |
> |
| 21 |
> 2) I believe x86 hardware never goes backwards. That is, if a new |
| 22 |
> feature is added, all future versions of the chip have that feature, |
| 23 |
> just with more added. Of course Intel and AMD both have their separate |
| 24 |
> additions, but since your staying with AMD, moving to a new processor |
| 25 |
> shouldn't break anything (even if you had used march). |
| 26 |
> |
| 27 |
> Disclaimer: I'm not an expert on hardware architectures or compilers, |
| 28 |
> so I might be wrong. |
| 29 |
> |
| 30 |
> Shawn |
| 31 |
|
| 32 |
Thanks Shawn, that's probably the best answer I'm going to get, I doubt |
| 33 |
many of the AMD chip designers hang around here... :) |
Archives