The Datafile PD-CD 5

home *** CD-ROM | disk | FTP | other *** search

/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / g / gcc / !GCC / !ReadMe < prev next >

Wrap

Text File | 1993-09-26 | 11.8 KB | 330 lines

GNU C/C++ compilers =================== 0. Introduction This file (sort of) documents the Simon Callan port of the GNU C/C++ compilers to the Archimedes, running RISC-OS 2 / 3. For copyright details and sources, see !Help. This is the first beta release, and should be followed by later, improved versions. Already an early version of a new code generator has a higher Dhrystone rating than norcroft GCC requires requires around 3Meg of free RAM and a hard disc, but it will generally work with !Virtual, with a few problems (see bugs). This is a binary distribution only and consists of the following packages : !GCC - Non-specific files, documentation, etc. !Help General help and copy-right !ReadMe This file. !Boot !Run !Sprites Docs.* Various GNU documents. GCC - GNU C/C++ compiler gcc Front end to the compiler. cpp C preprocessor. cc1 C compiler. cc1plus C++ compiler. o.gcc GCC specific library routines. h.varargs GCC varargs routines. Compiler support files as Assembler. ld Front end to link UnixLib UnixLib Unix compatible run-time library (binaries only). 1. Installation The (default) installation of GCC is relatively simple : * Copy this directory, and its files, onto your hard disc. * Amend Run$Path so it includes the !Gcc.bin subdirectory. * Set Unix$Path so it points to the !Gcc.UnixLib subdirectory * Set GCC$Path so it points to the !Gcc.gcc subdirectory * Set GPP$path so it points to the!Gcc.gpp subdirectory (Note this is deliberately empty at the moment) * Set UnixFS$/tmp so it points to the !Scrap directory (or any suitable scrap directory ). If you uncomment the lines in !GCC.!Boot and ensure that this is run during your boot up procedure, everything will be set-up as required. Note, there is no linker supplied, but DRLink, available at various servers (HENSA, newcastle etc) will succesfully link the supplied version of UnixLib. This completes installation, and GCC may be used simply by running 'gcc'. 2. Using GCC GCC uses the same assumptions as norcroft CC, with C sources held in the '.c' subdirectory and header files held in the '.h' subdirectory, with C++ sources held in the '.cc' subdirectoy. By default, GCC will compile, assemble and link the supplied sources. For most of the details for using GCC see the file invoke_texi. 2.1 RISC-OS specific features. * AMU This version of GCC supports the dynamic dependencies feature in the version of AMU supplied with desktop C. To automatically update the dependencies during compilation, include the '-acorn-make' flag in the command line. This will generate the !Depend file that AMU uses. * Norcroft Stubs / ANSILib By default, GCC uses the the UnixLib header and library files supplied, though the norcroft files can be used. To do this you need the following command lines options : -nostdinc Do not use the UnixLib headers. -nostdlib Do not link again Unixlib / gcc -IGCC: Get GCC specific include files. -IC: Get header files from the C: path -lC:o.stubs Link against Stubs - you can also use AnsiLib -lGCC:o.gcc Link against gcc If you are compiling C++ programs, and linking them against the norcroft libraries, rather than UnixLib, the source file that contains the main() function must be compiled by the GNU compiler, rather than Norcroft CC. * LD LD is a front end to Link, which converts the LD as generated by gcc to the Acorn Link format. LD only recognises a few options, the rest are passed directly through to Link. LD also attempts to convert Unix format names to RISC-OS format. The options that LD recognises are : ¤ -L <dir> This specifies a directory / path that LD is to use when searching for libraries. <dir> must be either a path (i.e gcc:, etc), or it must be a valid Unix / RISC OS directory name, ending in either '/' or '.'. Directories are searched in the order that they are specified. ¤ -l <file> This specifies the name of a library file which LD will search the library directories for. This may either be a complete filename (i.e C:o.stubs) or just the leaf name, in which case, LD will search though the specified library directories for the file o.<file>. The sequence '-Lgcc: -LC: -lgcc -lstubs' will cause LD to look for the files gcc:o.gcc, c:o.gcc, gcc:o.stubs and c:o.stubs, taking the first gcc and stubs files that it finds. LD does not recognise any other unix commands, therefore the other LD options documented in invoke_tex should not be used. Acorn link options can be passed from GCC to link using -Wl and -XLinker options. LD requires that the linker be named 'link', even if you are using DRLink. The linker must be in the default run-path, as LD does not handle the -B command. * Interworking with Norcroft cc Code compiled with GCC can be linked with code produced by the Norcroft CC compiler, with no problems. Note, if you are inter-mixing C and C++ code and linking against the supplied UnixLib library, there is no need for the main() function to be compiled by gcc - the UnixLib / gcc runtime libraries automatically handle the calling of global constructors. See Norcroft Stubs / ANSILib for details of using the norcroft libraries with C++. * Predefines The following preprocessor constants are defined for GCC: arm, __arm, __arm__ riscos, __riscos, __riscos__ __GNUC__ However, the predefined 'riscos' clashes with a variable used in UnixLib, and therefore this will automatically be undefined again, unless you disable the standard set of include files by using the switch '-nostdinc'. * RISC OS specific switches The following RISC OS specific switches are recognised -acorn-make The compiler is being run under AMU, and therefore should generate the !Depend file for AMU's dynamic dependencies. -mno-apcs Do not use APCS-R calling specification -nno-function-name Do not embed function names in object code. -mfpa Object code is intended to run using the floating point accelerator, rather than fpe, therefore pay attention to scheduling of instructions. [NYI] -mno-stack-check Do not use CLIB stack checking. * Search paths The search paths for GCC are as follows and searched in the specified order. GPP$Path for C++ only GCC$Path GCC specific include files. Unix$Path * <varargs.h> The versions of <varargs.h> supplied with Norcroft and UnixLib are not compatible with GCC, you will have to use the GNU version. For the supplied UnixLib, this is done automatically, but if you are using other libraries, you need to include the GCC include directory in the search path, BEFORE the library include path. i.e. -IGCC: -IC:. This does not apply to <stdargs.h>. * Wimpslot Due to the structure of the stack under UnixLib, GCC is not able to extend its wimpslot, and therefore you will have to set it to the required size from the start (around 2.5 - 3 meg is usualy enough). 2.2 Feature not yet implemented * debugging data There is as yet, no debugging data generated by gcc. Therefore, DDT can only be used for object level debugging, not source level. Actualy, gcc does generate the debugging data, but !as cannot do anything with it, therefore the data is commented out. * Throwback Errors are currently output only to the screen. Later versions will support Throwback 3 Implementation details * compilers The supplied C/C++ compilers are the stage 1 compilers, produced by norcroft CC, as these are significantly smaller and faster than those produced by the current version of GCC. * C++ global constructors / destructors For most Unix based C++ compilers, there is a separate stage to the linking process called collect2, which separates out the global constructors and destructors for C++. The RISC-OS C++ compiler uses the named area feature so that the linker groups all the function addresses together, and brackets them with the required data. The function addresses are placed into the areas 'C++$$constructor2' and 'C++$$destructor2'. If there are functions that must be called before / after the function calls, their addresses should be put into the areas 'C++$$constructor1' / 'C++$$destructor1' and 'C++$$constructor3' / 'C++$$destructor3' respectively. * Stack checking This version of GCC fully supports APCS-R stack checking, therefore there is no need to set the size of the stack chunk when using Stubs / ANSILib. * Libraries When separately linking C++ executables with global constructors, the gcc library requires some routines from the main run-time library. Therefore, the gcc library must be placed before the main run-time library in the command line or, if using DRLink, the -rescan command should be given.. * UnixLib The version of UnixLib that is shipped with GCC is based on version 3.6c, with minor bug fixes and C++ specific features. It has also been re-worked, so that DRLink version 0.24 can be used with this version of Unixlib. Note, there is a bug in DRLink which will generally prevent it working with other versions of UnixLib. 4. Known Bugs / Problems There is a problem with UnixLib, which affects the running of AMU - if one compilation fails, with a non-zero return code, subsequent compilations during the same AMU run also fail. I believe this to be due to UnixLib not correctly setting / resetting some data. Occasionaly, GCC gets stuck with cc1 (I think) always returning an exit code of 1, and causing all subsequent compilations to fail. Pressing f12, followed by return appears to clear this problem. This is just another aspect of the AMU problem, but it tends to be more annoying, as it extend past the end of one AMU run to th next. Unixlib also has a problem dealing with includes of filenames of the form "sys.fcntl.h" - Use "sys/fcntl.h" instead. This is more portable, anyway, and should not cause major problems. When used with !Virtual (version 0.37), gcc occasionally freezes the computer with the interrupts working (ie. the mouse moves and caps lock changes), but nothing else works. The computer has to be reset using the reset button, and it has twice damaged the frespace map on my hard disc. I think this is a bug in GCC/ UnixLib, but again I'm not sure. 5. Acknowledgements, sources and other bits * Acknowledgements As with all large programs, thanks go to various people for the help and assistance that they have given me. These are : Michael Ben-Gershon, for most (if not all) of the hard work involved in the ARM backend. Niklas Röjemo, for the assembler. Huw Rogers, for Unixlib. * Sources The standard sources for !as (version 1.21) and UnixLib (3.6c) are freely available from various FTP servers (HENSA, newcastle, Stuttgart etc.), though some changes have been made to both of these. Those made to UnixLib have been passed on to Huw Rogers, and may be released in the future. The !as changes are only needed for certain esoteric checks when making GCC, and I doubt that anyone would notice the difference. If you want the complete sources, your best action is to obtain the standard sources to Gcc / UnixLib / !as, and send me a floppy for the diffs that I have made - otherwise you will have to send me a LOT of floppies. 5. Undocumented Features (sic) Probably hundreds of the little swines ! Come on, you can not honestly expect me to document undocumented features, can you? Anyway, wouldn't a documented, undocumented feature be an oxymoron?