Hi Karlos
Especially for you I investigated few things.
1. SAS C++ (just to keep this info just in case):
A0 - 'this' for all nonstatic methods
D0 - class information (internal for compiler) for constructors/destructors
A1 - address of the place where to return value for functions that return whole complex objects
2. I know that 'register' is only a hint. However it is just a hint for local variables, but must be more strict meaning for function arguments, as every call must be made with arguments in the exact places, where the function expects them and the function can be defined in the other file than the call to it.
So the compiler can have a convention and SAS for example allocates address registers for pointers and data registers for integers, beginning with A0 and D0. Once the mechnism is checked you can assume that it must be consistent every time (at least with the same compiling options).
3. I've noticed that you omited 'register' in the example function. Mayby it is only mistype here, however if you did this in the code this may be the reason why GNU C++ complains about it. Correct syntax should be:
void func(register int i __asm("d0"), register int* j __asm("a0"));
I've checked it in my GNU documentation.
Well, installation of simple guides seems to be easier than the whole environment. Surprise, surprise... :-D
4. Problems with relocation can occur only in very specific situations, rare in real life.
Lets suppose you want your code to reside in FAST, but it was loaded to CHIP. If your code is position independed you can simply copy it from place to place byte by byte and thats it. If you use any absolute addresses you must think about all relocations afterwards.
For Amiga executables relocation is done by loader that is part of OS. Every binary, besides the code itself, has additionally so called relocation tables, that describe the places in the code that needs to be recalculated after loading (practically just by adding address of the beginning of the code to the result place) to make the code usable (famous HUNK format). Once this is done, the code must reside under this exact address.
5. Unluckilly yes. 'jsr symbolname' evaluates to jump to absolute address, as this is the syntax of this opcode. Of course it will be correctly relocated during loadtime, so do not worry about it. I'm not sure if some cleaver linker cannot change it to bsr or jsr symbol(PC), but I would worry about changing the length of the command as this could destroy all code offsets calculated and used by the compiler. I meant that if someone wanted to produce position independent code and prepared compiler options for that, but used such code, he won't get position independence, but he won't know about it.
Sorry if this was too boring. ;-)
Cheers
