Quote:itix wrote:
Quote:
Are you talking about __libcall__? The funny thing is that this extension causes no problems with new GCC versions. Th old GCC2 modifications apply to ALL later versions. Go figure..
Does it support 68k vararg hack too?
Of course, since __libcall__ does force __linearvarargs. I was only talking about
core __libcall__ support. The core patch to the compiler for that hasn't changed since GCC2. The backend has changed and there the patches were adapted.
Quote:
According to amiga_compiler.h GCC uses
#define APICALL __attribute__((libcall))
when VBCC uses
#define APICALL __aos4libcall __linearvarargs
So that every vararg library call in OS4 uses 68k varargs instead of native SysV varargs (newlib.library being an exception).
Thats correct, but then I don't know if thats a major issue. Note: I am not associated with AOS4 in anyway. But I looked at their GCC patches. I never understood why neither MOS nor AOS4 did use the present toc-saving bits. That would have saved a lot of code addition.
Quote:
One would also ask who had this idea using (the system private) r2 as a base pointer for baserel libraries... maybe r13 was too obvious...
Please define "system" ;-) Again I don't know the reason for this decision. Not that I really care.
Quote:
Luckily you can always extend struct Process when you need new base pointer (though it makes it tricky when your code is called from other context but not impossible).
You lost me ;-) But then I don't understand where "__restore_r13" comes from - in libnix its a no-op..
Quote:
Lack of __vararg68k is not problem. You can always work around this by piece of code.
You mean a varargs macro?
Quote:
However without baserel support SDL libraries cant be compiled on anything else than GCC2. But GCC4 is not secret overclocking utility so...
Well, I didn't look into this issue (yet). I now that __varargs68k is "easy". __saveds is harder since it requires a call and with GCC3+ epilogue/prologue is now RTL code.
