| Last updated : 17th Sep 2023 | Hardware entries : 395 | Software entries : 665 |
| Print options | |
|
Recompiling old software for AmigaOS 4If you have an old C program from years ago, it is possible to re-write it for the AmigaOne and AmigaOS 4. Most of my experience is with SAS 6.5x and Storm C (which is based on GCC). Follow some of the tips below to get your software converted:1. Header files a) Clibs, Pragmas, Proto files These header files contain mainly headers for the AmigaOS Shared Libraries etc. In some source code, you may get Clib and Pragma headers e.g. #include <clib/exec_protos.h> #include <pragmas/exec_pragmas.h> GadtoolsBox sometimes writes headers in this format. This will not fully work on GCC on AmigaOS 4. You should replace the above, with the proto headers. e.g. #include <proto/exec.h> This will include all the appropiate clib and pragma headers for you. b) Inline headers GCC uses Inline headers (included by proto headers) for access to AmigaOS share libraries. SAS C does not use them. 2. C Functions a) Function format In early days, when writing a function in C, some assumptions were made and the format was different, the arguments were defined in seperate lines. e.g. myFunction(num1, num2, string1) int num1, num2; char *string1; { } This does not conform to modern ANSI format. myFunction assumes it returns either an int or void and the definitions are seperate.Such function headers should be re-written thus, on one line: e.g. int myFunction(int num1, int num2, char *string1) { } b) Prototypes It is standard practise to prototype all functions either at the start of the C program file or in a header file. If you have multiple C program files, then add the prototypes to a header file and use #include that file in all your C files to ensure consistency throughtout the project. Use the ANSI C standard format (see previous note) e.g. /* Prototypes */ int myFunction(int num1, int num2, char *string1); c) Void If there are no parameters passed or returned, use void wherever possible. e.g. void otherFunction(void) { } d) Parameters and arguments When passing data to/from arguments, make sure you use the correct data type. For example, don`t pass a 'long' when the function expects an 'int' and so on as this can generate loads of warning messages. Either set the correct datatype at the start of the function or use casts in all other cases. void otherFunction(void) { long numa, numb; char name[30]; myFunction(numa, numb, name); /* this will generate warnings as numa,numb are longs not ints */ } should become: void otherFunction(void){ int numa, numb; char name[30]; myFunction(numa, numb, name); /* this is now correct */ } The main() function should always return an int, you may use a 'return 0' at the end to indicate a successful completion of the program. You may also use the argc, argv arguements if you need them otherwise use void. e) Compiling If the program was compiled in SAS/C, then run SCOPTS and change the message options to ANSI, STRICT. Also turn on all warnings (if any were turned off). Then recompile. Your program may be using old functions from SAS/C only libraries, these will not be transferable to Storm C or GCC compilers. In the SAS/C manual, in the User's Guide, look in the C Library Reference for calls that cannot be used in GCC. Any marked Amigaos, OLD, UNIX or SAS/C will have be changed to the ANSI equivalent or rewritten. Once the program has been recompiled copy the source to another folder, and re-compile for GCC/Storm C. This should spot any further errors or warnings that need attention. If using an Assembler, then 68K code can be recompiled using Phxass which is compatible with SAS/C assembly code, make sure you include the asm-include folder in project to pick up assembler header files. If possible assembler code should be re-written in C for portability to PPC code. When compiling, try to change the code to remove as many warnings and errors as possible. It will make it easier to update later and will remove any potential bugs from the code. Testing is also important, have a good test plan to fix any logical errors, the compiler cannot find them all. f) Makefiles Makefiles are not readily portable between compilers. In SAS/C you can create makefiles using the smake utility and the Scopts with provide options for processor type, optimization and so on. For Storm C, the project file contains the make information (readable in a text editor), for GCC, you need to write you own or use whatever utilities at hand. g) Trial updates If you want to have a go. Why not download some old amiga programs from Aminet that includes the source and have a go. Check readme and documentation, before distributing changed work. The author may not like their work updated or redisitributed without their consent. If in doubt don`t do it. h) Updating to newer GUI APIs The Amiga has the benefit of a choice of GUIs to use: Inituition, GadTools, MUI, ClassAct, Reaction and many others. If you have the skill, why not update the program to use the latest gui's such as Reaction or MUI. Both of these are supported in AmigaOS 4.For Reaction, you can use the Reactor progam provided on the Amiga Developer CD 2.1 in the NDK 3.5 section. There is the MUIBuilder program for MUI gui's. Beware that GCC optimization may generate floating point operations from non-floating point code. Use the -msoft-float option to disable the generation of floating point code on a per file basis. Example: If you're coding interrupts, check with the gcc option -S if the assembly output of your interrupt code does not contain floating point registers like lfd or lfs. Since floating point registers are not saved in an interrupt, this could lead to crashes in other tasks that also use floating point. Written by: Peter Hutchison mailto:pjhutch@pcguru.plus.com http://www.pcguru.plus.com/ Edited by: The IntuitionBase team Published 30th June 2004 Updated 21st January 2005 |
©2004-2023 IntuitionBase