From: Kai R. <kai...@lu...> - 2002-05-24 14:15:38
|
Matthew Miller wrote: > > On Thu, May 23, 2002 at 09:35:15AM -0400, Earnie Boyd wrote: > > I used i786 for purpose of example only, not stating that it's > > available. The 7 follows the 6 sequentially for the purpose of example > > only. I have no idea if it's a real architecture or not. > > Ah, okay. My only point was "it's not". :) The GNU docs don't know this, for instance the GCC 3.1 'Using'-manual: --------------------- clip -------------------------------------------- 3.17.15 Intel 386 and AMD x86-64 Options These `-m' options are defined for the i386 and x86-64 family of computers: -mcpu=cpu-type Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are `i386', `i486', `i586', `i686', `pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3', `pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird', `athlon-4', `athlon-xp' and `athlon-mp'. While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. `i586' is equivalent to `pentium' and `i686' is equivalent to `pentiumpro'. `k6' and `athlon' are the AMD chips as opposed to the Intel ones. --------------------- clip -------------------------------------------- The 'k6*' and 'athlon*' perhaps could be added as known cpu-types in the target name, if wanting the (self-built) toolchain be optimized for these. It isn't hard to add new target templates which are only variations of the existing ones. So targets like 'k6-mingw32' and 'athlon-mingw32' could be very easy to implement... This is quite the same as using the cpu-name 'xscale' instead of the generic 'arm' in the ARM-world, or using 'cpu32' or 'coldfire' in the 'm68k'-world... Just wondering why people mention 'ia64' when talking about 'Mingw64', not 'x86_64', the 'natural upgrade route', a'la MIPS, Sparc, PPC... Ok, for the former VAX/VMS- people the Alpha/VMS can be the 'natural' upgrade and x86/WinXP-to-ia64/WinXP too, but at least one Linux/ia64 user asked how on earth to produce Linux/x86 executables with the native GCC... The current 'x86_64-linux-gnu' targeted GCC seems to be ready to produce 32-bit x86-binaries too... BTW, I recently found out that writing "pdftex gcc.texi", plus sorting the generated indeces and then repeating the command, is the easy way to get a PDF-format GNU-manual. So which GNU-docs/manuals are now included with the 'official' Mingw-GCC in the expected WinHelp ('makertf' + MS-Help-Toolkit) and PDF (pdftex) formats (for Windows-use) ? If there aren't any, what possibilities there are for people to contribute these ? Not everybody has Linux where the 'pdftex' nowadays is as default, or the 'makertf + hc31' or the Help-Toolkit in Windoze, and not everybody wants to build their own GCC, probably neither the manuals... Unfortunately I cannot help, my docs are modified for my own GCCs having changes in the search paths, with additional targets documented etc., not the 'official' FSF- sources... For instance: --------------------- clip -------------------------------------------- 3.17.38 Microsoft Win32(s) Options These `-m' options are defined for the `Mingw' target when producing code for the `Microsoft Windows' family of 32-bit operating systems (`Win3.1x/Win32s, Win9x, WinNT, Win2k, WinME' and `WinXP'): -mwin32 Generate code for the `Win32' family of 32-bit operating systems (`Win9x,..., WinXP'). This is the default target platform. -mwin32s Generate code for the `Win3.1x' operating system with the 32-bit `Win32s' extension (Installation of `Win32s Ver.1.30c' is required). -mconsole Create a console application for the `Win32' family of operating systems. This is the default, but please note that a console application doesn't work on the `Win3.1x/Win32s' operating system because it hasn't a console. -mwindows Create a GUI application for Windows. This is the only possible application type for Win32s. -mdll Generate code for a 32-bit `Windows Dynamically Linked Library', `DLL'. -mcrtdll Generate code for the `Microsoft C Run-Time', CRTDLL.DLL, runtime C-library. This is the default with the -mwin32s option. -msvcrt Generate code for the `Visual C Run-Time', MSVCRT.DLL, runtime C-library. This is the default with the -mwin32 (or nothing given to define the `Win32' or `Win32s' variation). With Win32s the executables use the special Win32s- version of MSVCRT20.DLL --------------------- clip -------------------------------------------- As seen, these options clash even with the official 'Mingw' :-( Everybody has the freedom to produce modified stuff, for me the added 'features' were useful and needed. But the 'pdftex', 'makertf' etc. should be clues for those haven't built the GNU docs yet, although having succeeded with the GCC itself. Producing the docs seems always be expected to be 'rocket science', what it really isn't... Anyway if I put a DOS/DJGPP2, a Mingw and a Linux-libc6 hosted, and 'Mingw'-targeted toolchain with these features and with these docs for download, it would clash with something... Perhaps these 'mutants' should use the name 'Maxgw', ie. borrowing the name 'Max' from the 'Dark Angel'... As told, the target name is not hard to change (in one's own sources, but trying to force these to the FSF-sources or to the Mingw-releases seems to be vain...) Somehow I managed to return to the subject again... Ok, for me the result from 'pdftex' was a big surprise, I tried 'ps2pdf' from Ghostscript earlier (after 'tex + dvips') and was very disappointed then... Cheers, Kai |